On Mon, Jun 29, 2009 at 9:37 PM, Gregory Maxwellgmaxwell@gmail.com wrote:
When to do it is a philosophical issue:
Arguably it should be turned on early so that the early adopters of the technology (i.e. firefox devs!) will be test subjects. Support for audio/video tag in Wikipedia has been helpful in the development of firefox audio and video tag support. If the feature is turned on only once these clients are widely deployed then we'll have a situation where things may be broken for many users.
I was thinking we should wait until we have at least a few devs/sysadmins using a browser that supports it. I've had bad personal experience with trying to write to standards without being able to test the effects. I tried adding handheld stylesheet support to MediaWiki without actually using mobile devices much myself -- and someone from Opera ended up posting to wikitech-l politely suggesting that we should scrap the stylesheet because it was trash and their automatic adaptation of the screen stylesheet worked better. Similarly, I've been reluctant to do any work on RTL, although I can read Hebrew, because I use RTL wikis rarely and wouldn't be sure I'd be improving things for the actual users.
The people writing the code need to be able to see firsthand how it's working as they develop it, and preferably be noticeably affected by any errors they make. So when Firefox alphas support this and some devs actually start using them, that's when I'd say we should start actually writing the support. The syntax might even still change at this point, for all I know.
Right, though with all the minification interest I've seen here lately it sounds like a great time to hoist all that stuff out of the pages.
Some of it will be fairly hard, though. How are we going to set all the page-specific variables, with an extra request? Also, while replacing inline scripts and on* attributes with event handlers is fine in theory, practically speaking it's not always as good (at least, to the limits of my meager JavaScript knowledge).
For instance, notice how some infoboxes sometimes load and then suddenly collapse after a second, when they're meant to be collapsed by default for JS-enabled clients but expanded by default for non-script clients. I don't know if this is happening right now, but I've seen it before. The cause is that the script is run at the top of the page. At that point it can't collapse the infobox, because the infobox hasn't been added to the DOM yet. So it adds an onload event handler -- but that only fires after the page has fully loaded, a noticeable period after the fully-expanded infobox has been rendered. With inline style you could just do:
<div class="infobox"><script>// Set display: none on the div after that has been added to the DOM, but before its contents</script>...
. . . I guess in this case you could set a CSS rule from the JavaScript before the div is actually created. But not all "immediately after parsing" DOM manipulation is CSS-based. Say you wanted to add some buttons on page load that only have an effect when JS is enabled, like collapse/expand links. This is what we do now for TOCs:
<script type="text/javascript"> //<![CDATA[ if (window.showTocToggle) { var tocShowText = "show"; var tocHideText = "hide"; showTocToggle(); } //]]> </script>
Is that possible to do without inline script, without causing jumping or other undesirable effects (e.g., useless links being shown to some users)?
I think one really compelling thing about it is that supporting clients can provide feedback to the webserver. This means that every supporting user will be an XSS test probe, a canary in the page-mine. So even if this doesn't become standardized and widely adopted by clients other than firefox it would reduce the damage of unintentional but well meaning privacy leaks since we'd get notice of them very quickly rather than months later.
I didn't notice that feature on my first pass through the spec. That is really neat, since you point it out. It would also help for figuring out when content is inadvertently breaking. It mitigates my objections above to speedy implementation, although I still think waiting until we have an actual preliminary implementation is a good idea. Specs tend to change based on implementation experience.
I don't know enough to comment on the W3C path— but I have no particular reason to think it wouldn't happen: W3C activity is almost universally lagging rather than leading. Things like this aren't generally matters for discussion unless someone is thinking of implementing them.
Yes, but Mozilla can create a new working group to develop the spec in if they want to make the functionality standard, like they did with CORS. They don't seem to be doing that (yet?). It's still early, though, and maybe they plan to.