Re: Element Whitelisting (was: SVG Feedback on HTML5 SVG Proposal)

Hi Ian, Doug.

Doug Schepers:
> > It seems riskier to bottleneck element parsing to one time-frozen 
> > specification.  I agree that implementations will update their internal 
> > list of supported non-HTML elements and attributes regardless of what 
> > HTML5 says, so it doesn't seem practical to include any such list in the 
> > HTML5 spec.
> > 
> > Let's say that 2 months after HTML5 becomes a Rec, SVG comes out with the
> > <pony> element, which has a the @hands attribute.

Ian Hickson:
> I assume you mean more something like fePony with a jazzHands attribute, 
> since all-lowercase names would work fine.

Yes, I think that is what Doug meant.

> > Obviously, all browser vendors would implement this element and its 
> > attribute, post-haste.  Now, either HTML5 is out of date, or it needs to 
> > have an errata issued and ultimately a second edition.
> 
> By the time HTML5 becomes a REC, it will have been out of date for a long 
> time. I would fully expect work on HTML6 to be in full swing by then, and 
> HTML6 would be able to track the new features easily.

There’s no guarantee that an HTML spec will be being worked on at a
maturity that would allow us to add new entries to the case fixup table
at a given time when the SVG WG would like a new element/attribute to be
supported.

> Adding a new attribute or element name requires a careful study of 
> existing content, which is far more work than any sort of editing of a 
> spec. I think worrying about which spec the list is in is optimising the 
> easy part while ignoring the real bottlenecks.

You are right that introducing new attribute/element names to the HTML
parser does require careful consideration.  However, the overhead in
beginning work on a new version of HTML wouldn’t be trivial.  True, at
the moment, while HTML 5 is a Working Draft, it is quite easy for the
editor to add a new entry to the table.

> Note that nothing stops a future version of SVG adding names and 
> attributes to the list anyway, acting as a kind of errata to HTML itself, 
> should it be found that the HTML working group at the time is no longer 
> responsive to feedback of this nature.

Really?  This seems strange.  If HTML 5 makes various conformance
requirements, and another spec (perhaps SVG itself, or a small SVG-in-
text/html spec) makes some contradictory requirements, it wouldn’t be
possible to have a conforming implementation of both.  HTML 5 goes to
great lengths to define “sensible” conformant behaviour, that browser
vendors will want to implement.  Why would you then want them, later on,
to violate this?

> > In the worst-case scenario, some implementers (or authors) might feel 
> > gated by the whitelist of elements in HTML5, and might not implement (or 
> > use) <pony hands="13.7"/>.  That would be a real shame.
> 
> The odds of an implementor feeling like they shouldn't do something 
> because the spec doesn't justify it are spectacularily remote.

It seems a shame to set up the HTML 5 spec to deliberately require
implementors to violate it down the track when future SVG features are
developed and implementors want to make them available in text/html.


Is the concern that if the SVG WG is the group publishing the table of
SVG case folding names that we might make poor decisions, which HTML
then would normatively require?  I would rather the table ends up in a
separate, small specification, which would be more easily updatable than
one as large as HTML (or SVG, for that matter).  This could of course be
on the Recommendation track, and would thus be afforded with all the
usual chances for review.

I am concerned that this is seen as a “turf war” of some sort, which I
obviously don’t want it to be.  If the table is in the HTML 5 spec, then
the HTML WG is effectively the gatekeeper to any new SVG features
(assuming they used mixed case names[1]) being usable in text/html
(which, IMO, will likely end up seeing more SVG content than SVG/XML).
If the table is in a document produced by the SVG WG, then the HTML WG
could say that that gives the SVG WG the ability to change how text/html
is parsed without the direct involvement of the HTML WG.  Would having
a separate document with the case fixup table being produced by both WGs
be a way to avoid these issues?

Thanks,

Cameron
(not speaking as co-chair)

[1] An argument for continuing to do so being consistency with existing
SVG names.  If the HTML parser is being modified to handled case fixups
already, then there’s less of an argument to avoid minting such names in
the future.  For cases where consistency with existing SVG names isn’t
an issue, we would prefer lowercase names, though, since it wouldn’t
require updating the case fixup tables.

-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Tuesday, 24 March 2009 02:49:42 UTC