Re: Point of Extensibility

On Apr 3, 2008, at 19:06, Doug Schepers wrote:
> Henri Sivonen wrote (on 4/3/08 11:03 AM):
>> Once you allow this, the whole <ext> element becomes pointless.
> ...
>> That violates one of our design principles:
>> http://www.w3.org/TR/html-design-principles/#dom-consistency
>> And not even for a good reason once you allow the omission of the  
>> <ext> tag in source.
>
> Like I said, I'm not advocating it, and I don't even like the idea.

I don't like <ext>, either. :-)

>> Without <ext>, SVG <desc> could be appropriated for fallback. If  
>> that's objectionable,
>
> It is objectionable. :)  That's not what <desc> is meant for.

Presumably, a suitable description could serve as a fallback, although  
it is more likely that authors who bother with any fallback at all go  
with bitmaps (both with SVG and MathML).

> It's not clear how non-HTML UAs should interpret or display that  
> content.

The same way they should now if you feed them SVG with XHTML children  
in <desc>.

> Non-namespaced content (besides simple text) would break SVG UAs  
> (authoring tools included) in copy-paste scenarios; simple text is  
> not a sufficient fallback for SVG or MathML.

HTML elements in <desc> could be put in the http://www.w3.org/1999/ 
xhtml namespace.

>> a <fallback> element could be allowed where SVG now allows <desc>.
>
> That would require a change to SVG

The change would be trivial, though, since the whole point of the  
element would be that SVG UAs hide the element and its descendants.

> (and to SVG UAs,

You mean if <fallback> got extracted and reserialized to XML? Would  
non-browser SVG UAs really be so brittle as to require changes?

Demo: http://hsivonen.iki.fi/test/moz/svg-fallback.svg
I don't see any <fallback> leakage in Firefox 3b5, Safari 3.1 or Opera  
9.5 beta.

> and to the XHTML parser).

No, the XML parser is the only part of the system that is assumed to  
be sacred and invariant. :-)

> The semantics of it don't seem to make sense... <desc> is allowed as  
> a child of any SVG element, and we don't need a fallback for each  
> element, just for the content as a whole.

Yeah, <fallback> would only make sense as a child of <svg>.

>>> * Incredibly unlikely to break any content... there may be content  
>>> out there like #2, but unlikely to be any like #1; you could think  
>>> of the <ext> as a sort of "early warning" to browsers that a known  
>>> "insertion mode" is about to follow.
>> I'm not at all convinced that a wrapper named <ext> would solve  
>> problems that a wrapper named <svg> wouldn't.
>
> * It decreases the risk of acting funny with legacy content.

Hopefully we can drive this risk to negligible by examining the  
immediate children of the 'math' element instead of just the <math>  
tag. <svg> is less likely to be unrelated to SVG.

> * It makes a consistent and easily understood point of extensibility  
> for HTML, so that authors always know what to do with SVG, MathML,  
> or some future endorsed syntax.

The Web platform already has Conway's Law written all over it, but we  
shouldn't make the situation worse by adding more syntactic sign  
posting between the parts created by different Working Groups. It's  
bad enough that to script the DOM you need to know which element (or,  
in the case of XLink, attribute!) came from which committee and use a  
different namespace URI accordingly.

I think it is a mistake to treat SVG and MathML as extensions to HTML.  
Instead, we should consider HTML, SVG and MathML parts of a unified  
Web platform (even though we cannot unify everything due to legacy).

> * It provides a consistent way to allow for a rich fallback for SVG  
> or MathML without creating incompatible content for those languages  
> (or requiring an extension to them)

Do we really want the <ext> cruft in the DOM when fallback is no  
longer needed a decade from now (if all goes well and SVG has de facto  
become part of the feature set of a text/html browser)? Or would it be  
better to use something that can be fade away with time without  
leaving traces in new content?

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Thursday, 3 April 2008 20:31:27 UTC