I am writing a book in epub and the problem is that I want the text to be in the middle of the page. I tried style="top:50%", it works in Sigil, but not in the sony my reader app. I heard that sony uses a special type of epub, so if you know something about it please tell me.
I have no knowledge of Sony specifics, but in general you can't expect this kind of positioning logic to work well across all ebook readers. Anything involving the CSS 'position" property with a value other than static (the default) is likely to be problematic, especially with EPUB2 readers. I'm guessing this would work fine in iBooks, or Readium, did you try that?
The safest alternative is an image.
If you wait 3-18 months, most ebook readers will have been upgraded and you can expect the great majority of them to support what you are trying to do.
Related
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 12 years ago.
Improve this question
How, many PSD 2 HTML companies claim to provide Templates in 8 Hours?
How they make it possible?
Do they use special software or techniques?
Is it really a possible to provide XHTML Strict, Semantically correct, Cross Browser compatible (even in IE6 and Opera, as some claims), W3C valid XHTML and CSS, properly commented, well optimized HTML and CSS Markup in 8 hours. even for not much complicated design.?
For about half of the last 10 years, I worked for a design company. Among other things, I probably did upwards of 400 projects like this. Totally custom designs drawn up in Illustrator, they'd hand the file off to me and expect a template back in no more than five business days.
When I first started, I was probably spending as much as a work week getting everything sliced up, doing all the markup, and chasing down CSS bugs (not only was I inexperienced, we still had IE 5 Win AND Mac to deal with, and even Netscape now and again). But after a dozen or two projects, I was doing most templates inside of two days.
After a hundred projects, most templates were done inside of an eight hour workday. Some easy ones under four. Usually pretty much hand coded from scratch, outside of a very small bit of boilerplate CSS & HTML.
Periodically, no matter how good I got, I'd get a pretty unusual design, or hit an unanticipated problem with the layout (usually in IE 6) and have to spend hours figuring it out, occasionally even totally recoding, so unless I were offering something with constraints on design, I'd be hesitant to guarantee that kind of turnaround. But the idea that skilled labor can generally pull this off (certainly on average) into the business model is something I wouldn't hesitate to bet on.
With enhanced tools (which others have speculated these shops have), it might even be faster.
How they make it possible?
Do they use special software or techniques?
I don't know how everybody is doing it, but from my experience, they use both software that reads the PSD format and both a "correct" formatting of the PSD file (i.e. the right technique).
So basically that software expects a "valid" PSD and produces the required templates without further manual tweaking.
The whole idea is to enhance the PSD with metadata: - proper naming, proper cutting, proper properties (based on the conventions required by the specific software). After these are done manually, it's quite easy for a software to use that metadata and generate the required templates.
Is it really a possible to provide XHTML Strict, Semantically correct, Cross Browser compatible
Yes. The generation step of the software(that is using itself templates for generation), can output correct results.
even in IE6 and Opera, as some claims
No. It can include some known hacks but not 100 correct for IE.
W3C valid XHTML and CSS,
Yes. Remember - this is generated code, so it can respect to standards much easier since there's not manual intervention.
properly commented
Nope. It has only automatically generated comments - they are not very useful.
well optimized HTML and CSS Markup in 8 hours
As good as it can be automatically optimized.
It doesn't take 8 hours:
if the PSD is produced by the same company that will generate those templates, than it will be already annotated with the required metadata.
if the PSD is a well known stock PSD, than there might be already metadata at hand for it, so it's just a matter of quick copy and paste.
if the PSD is a customer PSD, than there's a little more work (~30 min) for a skilled developer to add the required metadata to the layers.
with the annotated PSD, it's just a matter of seconds to feed the software with it, and have the output.
usually the software has a few parameters, so a few template variants are generated, than fed to a software to compare how it looks on various browsers. This step also takes a few minutes.
So all in one, for worst case scenarios it takes ~40 minutes per template, but usually it's much much faster. Companies take the 8 hour margin to be sure that they can deliver even under heavy load.
i'd say they have a really good snippet library and they use a 'template + plugin' approach.
for example, you'd have snippets/plugins for a drop-down menu, contact form, image slider, pagination controls, image replacement etc that worked perfectly well in all major browsers and even IE6.
So if the design is not complex, all you need to do is plug in the various elements into your template and alter some CSS, which should not take more than 8 hours.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Which screen reader would be best to test site accessibility and how to configure that screen reader to test website (or default screen-reader setting would be ok) and which browser should be used to test accessibility with screen-readers?
Free or commercial it doesn't matter . Which can give best testing then site should be accessible in whole world as much as possible with all other screen readers?
my purpose is to make site as much as possible.
I will preface this answer by stating I’m a totally blind individual who uses Jaws as there only screen reader. I've played around with NVDA as well but have l9imited experience with it. Jaws is the most widely used screen reader at least in the US. If you can only use one screen reader I would pick it with the default settings. Both Internet Explorer and Firefox work with Jaws and both are widely used. Another screen reader you could use to test accessibility is NVDA this is an open source screen reader that works well with Firefox but not internet explorer. I would say if cost is an issue use NVDA with the latest version of Firefox, and if your site is accessible using that setup it will most likely work with Jaws. For a complete list of screen reading software see this
Installing and starting a screen reader isn't enough to do good accessibility testing. You won't know how accessible your site is until you turn off your monitor and unplug your mouse. Getting good enough at using any screen reader to do that will take time. The only sighted people I know that are efficient screen reader users either work for the screen reader companies, or do assistive technology training as their job. So while you can use a screen reader to test your site's accessibility the learning curve for a realistic test is quite high.
To answer your question directly, I would use JAWS with default settings in your target browser. If you can only afford one license, then use NVDA or Chromevox for your developers and give your Accessibility expert the copy of JAWS.
Keep in mind that while making sure your site works perfectly with a screenreader is very important, this only helps the blind. There are many other types of disabilities (e.g., hearing, motor, and cognitive disabilities) and to truly be accessible, your site needs to support those users too.
WCAG 2.0 is the best standard for making your site accessible to as many people as possible. There is A LOT of WCAG 2.0 documentation though, so I would start at webaim.org, http://webaim.org/standards/wcag/checklist if you are new to it, but do use the real thing http://www.w3.org/TR/WCAG20/ when you are ready.
Also, keep in mind that even if it "works" with a screenreader, it may be annoying (blind users rarely read top-to bottom, make sure you put in solid structure with headings and ARIA lankmarks) or it may not be giving a blind user the same amount of information that a sighted user might get. For example, helper text next to text inputs will be missed by a user tabbing through a form (fixes: hide a copy in the label with CSS, make the helper text the actual label, or use ARIA-describedby) - a good way to make sure it more than just "works" is to have your JAWS tester not be familiar with the site.
This is a best-practice topic.
I saw it as a prefer method for some web developers. Instead of doing the CSS layout from scratch, they start a photoshop mockup first and then decode it into CSS.
What do you think about this approach?
Best to all,
Mockups are great, but I don't know if photoshop is the very first thing you'd want to try for the purpose -- at the very start, when you're just trying to get a logical layout for the various pages of the site (before refining it in terms of looks &c), a whiteboard with dry-erase markers and post-it notes affords for very fast, repeated mock-up rearrangements for the early brainstorming. Once there is some reasonable agreement on one (or a very few) possible arrangements of information, then visually more accurate tools enter into play.
BTW, just don't forget to photograph the whiteboard before changing it (any decent cellphone will do, you're not trying for high quality here;-) any time there are ideas or suggestions you may want to revisit or ponder in the future!
It is fast. This is why i always use this method. You don't want to spend the time building cross-browser CSS until you are actually set on a layout.
Most webdesign graphic artists work this way.
Many programmers simply find it a waste of time.
It has advantages, and disadvantages.
Advantages:
Many graphic artists grok photoshop/illustrator more than they do dreamweaver.
Customer gets a preview of the final product that works everywhere: mac, pc, firefox, ie, safari, whatever. Sending an html preview in early stages of production with developers using firefox and customer using MSIE always stirs up trouble.
And don't think to be on the smart side, scribbling MSIE driven html. Starting with non-standard html and converting to standard is more painful than doing it the other way.
There's one more catch: many web site customers tend to have a Mac and use Safari. Web committents tend to have a stronger taste for graphics than the average, so the chance to bump into Mac maniacs is higher in this sector than in others.
More design alternatives can be prepared spending less time on each one. This could be a dramatic advantage while dealing with murky clouds of executives with no designated decision-makers on the customer side. Alternative mockups will be passing hand-to-hand until general consensus is reached on one design or the other.
Disadvantages:
"Cutting" the graphic design into html becomes an additional work and it's not clear who's gonna pay for that extra time.
It favours graphic-centric, and rigid, design workflows. Customers agree pre-emptively on a given preview and that's what they get by contract. Every graphic modification means money, behaviour and programming instead tend not to be well defined, or worst, ill defined by the mockup.
The quest for pixel perfect cross-browser adherence to the mockup may drive you insane. If you agreed on a given rigid design with the customer, that could become a dire issue to pursue.
Dirty CSS tricks shoe in into your design. Using an HTML mockup, the customer would have approved a design driven by code with less tricks in place.
Anyway, I wouldn't suggest photoshop for a mockup, but inkscape. (or illustrator, if you worship adobe by burning piles of money into magic circles at midnight)
A scribbling stage is good too, while discussing the contract live with the customer.
I prefer pencil and paper to felt-tips, and I webcam shoot ideas for archiving and email forwarding. When it comes to scribbling, anyone does what feels more natural.
Not doing any and rely onto sample site examples and screenshots for graphical reference is always an option.
If you're productive that way, why not? Not everybody manages to envision their Web site perfectly as they're typing in a bunch of angle brackets.
More seriously put: It's your job, so it's your responsibility to do it in a way that allows you to do it effectively.
When prototyping, it's important to choose the right fidelity. This article from BoxesAndArrows provides a nice introduction to the various options and their uses.
I particularly like this line by Bill Buxton which the article quotes:
There is no such thing as high or low fidelity, only appropriate fidelity.
In this TechTalk by the Facebook Design Team, they mention how they use Photoshop in their design process (IIRC it's somewhere midway through, but I can't seem to forward through the video).
I am a web programmer who knows html and css fairly well. I can use a graphic program for it's basic functionality, but desinging a complete graphical web site is not my thing.
I let a graphic designer use his or hers graphic program to create a nice looking layout, and than code the website by hand in html and css.
It works for me, and gives my customers a design they like (cause a graphical designer will always make a much more nice looking design than most web programmers).
Agile methodology would suggest something easily modified in consultation with the customer. Dave Thomas in Agile Web Development with Rails suggests scribbling on paper. But anything has got to be better than chipping away directly at handmade CSS unless you really know what you want.
I was thinking about saying "scribbling might not cut it for a formal presentation" but the awesome SO crowd beat me to it in the comments...
Personally, and at every webdev firm I've worked at, I've always mocked-up in photoshop first. Jumping straight into CSS and markup is more of a bottom-up approach and makes sense to a lot of programmers but in web development you have to keep in mind that there are aesthetics to consider and a creative direction to follow. It's not enough that your product is functional, it needs the input of a professional creative-director/graphic-designer in order to make the product pleasant to look at and use.
In my experience, the problem has always been wrestling with inflexibility of team-members. Graphic designers who are aesthetics focussed and refuse to compromise their design integrity; which sometimes results in impossible or extremely difficult and un-semantic layouts. Developers who flatly refuse to compromise the integrity of their code where there is a workable solution - which might be a little less elegant. The key is to have a creative team who is intimately familiar with CSS and what is and isn't possible and an engineering team who have an appreciation of the importance of design and aesthetics.
In my freelance life (having had the benefit of working in both camps) I find it much easier to mock-up in photoshop first because I know what I can and can't do. And photoshop mockups are a lot easier to change on client feedback than are CSS and markup. Also, if you can show your client a mock-up, they feel more secure because they know that their money is going into a well planned project with a definate direction.
Hope this helps!
My website is designed to meet the accessibility guidelines.
I'm HOPING that this means screen readers should work well with them... But I have two questions:
Is this a fair assumption to make?
Are there any free/cheap screen
readers clients I can use to test or
online emulators?
Just because something meets the guideline doesn't mean it's guaranteed to be accessible, all screen readers have there different quirks. I'm a totally blind individual so comments on screen readers are below.
Note this is a rather long post so I’ve summarized it at the top. In summary if you want to make sure your site is mostly accessible use NVDA, if you want to make sure that blind individuals working in the government will be able to use your site use Jaws to test, if you want to be extra safe use Window-Eyes and Orca to test as well.
NVDA is an open source screen reader that is rather new. It isn't quite as good as some of the commercial screen readers out there but it gets the job done. I'd say if a site works with NVDA it's likely to work with most other screen readers. One issue with NVDA is the fact that its accessibility is only really good in Firefox so you'll have to use that to test.
Jaws is the most widely used screen reader out there. You can download a demo of it that will run for 40 minutes at a time then require you to reboot if you want to run it again. If you’re trying to insure 508 compliance this is probably the way to go since Jaws is the screen reader used by the US government.
Window-Eyes is the second most used screen reader. I don’t have any experience with it but I’ve been told it’s quite good as far as internet accessibility goes. Orca is a screen reader built into gnome that works with Firefox and Linux. It’s built into Ubuntu. I tried it about a year and a half ago and it was absolutely horrible but I’ve been told it’s gotten better.
NVDA is a free option:
NonVisual Desktop Access (NVDA) is a free and open source screen reader for the Microsoft Windows operating system. Providing feedback via synthetic speech and Braille, it enables blind or vision impaired people to access computers running Windows for no more cost than a sighted person. Major features include support for over 20 languages and the ability to run entirely from a USB drive with no installation.
Is this a fair assumption to make?
No, even if you think you know the ins and outs of accessibility well, only testing can really tell you this.
Are there any free/cheap screen
readers clients I can use to test or
online emulators?
The already mentioned NVDA looks like a viable option, or you can download a trial of JAWS which I believe is the most widely used screen reader on Windows. If you're really serious about accessibility and you have a requirement for ongoing testing, you might want to think about just buying a copy.
On a final note, it sounds like you already know this but no amount of automated accessibility testing can really tell you if your site is accessible, only real-world testing can do that! Which is what you're doing, so well done.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
As a side project, for "fun," I'm rewriting my blog and CMS in Flex and AIR respectively, and while I'm pretty well satisfied with the design thus far, the one major pain point remains working with (which is to say performing CRUD operations on) legacy HTML content, and rendering that HTML content decently in both the browser and the Flash player. Sure, I can use the out-of-the-box RichTextEditor and TextArea controls, but both tend to choke on displaying and manipulating simple markup (e.g., single or absent quotes on attributes, image alignment, etc.), and the content it generates by default, while beautifully rendered in the Flash player, usually looks ridiculous in the browser -- an important factor to me, since I'd like to continue publishing RSS.
I know there are a couple of RichTextEditor derivatives out there, but before heading down the road with any of them, or down the alternative road of manipulating the content manually, I figured I'd poll the group here first, to see whether anyone's tackled this problem before; it seems like it has to be a fairly common use case.
Thanks in advance for your insights!
The problem you've hit is Flash natively supports a very small subset of HTML. So any editing you do to fit the Flash player will make it render much more primitively in HTML. Personally I think the conflicting aims of editing legacy content in Flash and displaying cleanly in both Browser and Flash are going to be too difficult to resolve.
One alternative would be to write your own text layout engine, much like the team working on Buzzword did. Given it took them many months to produce their application, I suspect this is massively out of scope for your plans :)
Another, simpler alternative would be to apply a server side transformer over the HTML content to simplify it down to Flash level. This would enable you to have a richly layed out HTML document, and a simpler Flash document. However it won't help you edit it in the Flash player.
If you wanted to edit your HTML in Flash, you might be able to use the wmode + iFrame trick first mentioned by Christophe Coenraets and updated by Renaun Erickson to give yourself a dual-live preview but you are still going to have the problems with different levels of HTML support by Flash and Browser. And editing a textfield to manually edit-then-preview your content really isn't what you want to be doing.
A final option would be to investigate the newly-in-beta
Text Layout Framework which would help give you some of the more extensive WYSIWYG parts of HTML. This looks a complicated but fairly feature rich. It works with Flex 3.2 / Flex 4 / Flash CS4. Of course this in beta, so may change at some point in the future.
As an aside, if you are building an AIR application, perhaps building a HTML+JS AIR application using existing JS+HTML editors such as FCKEditor would be a viable solution? Then you would just have to render for the Flash player (perhaps using a transformer approach as detailed above).
Take a read of Display HTML in an Actionscript 3 project
It doesn't fully answer your question (as it only addresses rendering HTML in Flash), but it may prove a useful starting point.
Have you considered using one of the existing JavaScript-based rich text editors and embedding it within HTML that is hosted within your flash-based app for example?
I myself am currently investigating use of FCKeditor as a popup on pages to edit content that can be displayed in Flex component htmlwrapper .. no idea how far i will get, but that's my insight!
Have you tried html tidy? It has a standalone version and php has tidy module too.