On Mon, Jun 29, 2009 at 9:37 PM, Gregory Maxwell<gmaxwell(a)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.