Brad Knowles wrote:
I would much prefer to do this without JavaScript. Because you can't guarantee that you know the way that page would be rendered
Can you help me understand the basis for this claim? I have looked into the matter somewhat deeply and this works in every browser I have come across that supports JavaScript:
document.getElementById('foo').style.display = 'none';
An intelligent layout allows you to minimize the amount of page rejiggering that goes on when you display text.
Visual tests using Greasemonkey allow you to see all the visual states a page can get in (including different sized displays) to ensure you don't get into an unpleasant corner.
Perhaps you mean to say that the variety of CSS implementations prevents me from knowing how a UA will render the page. Strictly speaking, this is true; pragmatically speaking, there exists suitable CSS that works in all current browsers that I know of.
if you send all sorts of "hidden" text that isn't shown until such time as someone does something to make it appear,
The document with all the hidden text shown will be something like a "full detail" view; after all, I've promised the page will work fine with JavaScript off.
and you can't control what kinds of mailicious cross-scripting attacks people may throw at you,
I am unaware of any cross site scripting (XSS) attacks that can occur when a linked-in stylesheet uses the event model to alter the style of a element.
Perhaps you are referring to the approach of using some mechanism (XMLHttpRequest or naive furl() type stuff) to fetch new bits to go into a page. This definitely a risk, and one I'm disinterested in playing with.
I intend to use XMLHttpRequest to fetch JSON messages like "preferences saved" from the server. These messages will be carefully scrubbed and come only from server-generated translations, rendering them an improbable source of XSS.
I also intend to use it for one-way communication where the client informs the server that something has changed via JSON. As with all form submissions, each JSON submission will have to come with the appropriate hashcash-esque validation element to be considered to come from the user.
The UI benefit that drives the above choice is that I can provide the user with the UI state of the web app at the last time they used it, no matter what machine they come from.
it's best to simply not send anything that the user cannot currently see.
I'm not sure I understand this principle.
Most people have internet bandwidth that is inferior to the rendering speed of their browser, and a monitor that is smaller than most page content; some people (like those using screen readers) have essentially a 2d/linear monitor.
This suggests that sending fewer, "larger" chunks is preferable to sending many smaller chunks when the user will be aware of the load time. The way modern rendering engines work makes 'hidden' text *much* faster to load during initial page rendering than it would if it were all displayed.
One use case is where the new user clicks on all the help buttons to learn what's going on; a delay rendering help increases exploration cost.
Another one is the way people read on the web. Nielsen [1] and many others in the usability field have shown that people scan, looking for key words, rather than reading. The fewer words the shorter the seek time and the more likely the user will do an exhaustive search of the page for what they're looking for.
[1] http://www.useit.com/alertbox/9710a.html
When it comes to screen readers, text *is* space; sighted individuals can skip big swaths of text with a single saccade, but a blind user must give voice to enough of the text to hear where they're going.
This makes scanning text both temporally and cognitively more expensive than it is for sighted users.
As screen readers *do* respect hidden/shown elements, I can significantly improve the user experience for them, while making life easier for visual uses as well.
On somewhat of a side note, I have heard a certain amount of antipathy towards JavaScript in this forum. I know it was unpleasant in the late '90s, but it is much better and more cross-browser these days.
I'm fairly certain that *some* author-initiated manipulation of a user's experience of a node set is obligatory in any conceivable Web; the only alternative I can see to using JavaScript or another interpreted language would be using something like XSLT, a horror that I shrink from even contemplating.
~ethan fremen