Re: Point of Extensibility

Hi, Henri-

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 
was just playing around with details.  I'm quite happy to reject this 
idea, but the question remains as to what to do when such content is 
encountered.  Perhaps we allow both scenarios... I'm convinced that 
<ext> is better, though.


>> Two advantages to explicitly using <ext>, however:
>>
>> * Compatible with Henri's general solution, but with the added benefit 
>> of the ability to supply a rich fallback.
> 
> Without <ext>, SVG <desc> could be appropriated for fallback. If that's 
> objectionable, 

It is objectionable. :)  That's not what <desc> is meant for.  It's not 
clear how non-HTML UAs should interpret or display that content. 
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.


> a <fallback> element could be allowed where SVG now allows <desc>.

That would require a change to SVG (and to SVG UAs, and to the XHTML 
parser).  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.



>> * 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.

* 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.

* 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)


Regards-
-Doug Schepers
W3C Team Contact, SVG, CDF, and WebAPI

Received on Thursday, 3 April 2008 16:06:46 UTC