Re: Extensibility vs. supporting SVG and MathML

Henri Sivonen wrote:
> It doesn't. It enables SVG and MathML in text/html in a way that 
> shouldn't Break the Web. I think these should be considered parts of the 
> Web platform as they, like HTML, are vocabularies for which the browser 
> has to embody non-trivial processing code in order for the vocabulary to 
> be of any use. Since SVG and MathML are part of the platform, I think it 
> is reasonable to optimize their syntax not to have extension cruft 
> (xmlns) is sight.

For some it is "cruft", for others it's a solid way to embed extensions 
that works well.

> Your distributed extensibility blog post gave FBML as an example. While 
> SVG and MathML in text/html are foremost meant for browsers, FBML is 
> meant for the consumption of one proprietary service. As such, a 
> language like FBML doesn't need to be text/html and doesn't have to 
> allow itself to be constrained by the text/html parsing legacy. 

Absolutely. Extensions should be defined in a way that the bizarre HTML 
parsing rules do not need to be invoked. That could be XML, or something 
that is at least "like" XML in that no out-of-band knowledge of the 
vocabulary is needed.

> Moreover, I think we shouldn't risk legacy content compatibility by 
> making the HTML5 parser more suitable for reuse in the implementation of 
> proprietary templating languages. Creating such languages in XML by 
> mixing XHTML5 and other elements would make sense. If the Draconianness 
> of XML is the blocker, I think XML5 would be a better choice than HTML5 
> parsing.
> 
> Then there are newly-introduced vendor features like <canvas> was. I 
> think the best course of action here would be to announce intent on the 
> right mailing list (here), solicit feedback and syntactically make the 
> feature part of the core language--not an extension. Fortunately, we 
> don't need to use <apple:canvas>. I think extensions minted by browser 
> vendors are different by nature than extension minted by anyone else.

Really? I don't think so.

> Microformats and ARIA extend HTML as overlays in order to create 
> something that can be supported on some browsers but not in others an 
> still not disrupt the others.

Microformats suffer from the central registry.

> That leaves extensibility for 'extensions' that are meant to be used on 
> pages served to browsers but that browsers are expected not to build 
> native support for. Most usage patterns I can come up with for these are 
> anti-patterns, except for loading script initialization data. Anyway, if 
> we do address this case and even if the result seems like a 
> generalization of any of the other cases above, I think we shouldn't 
> then go back and make any of the above cases cruftier than they need to 
> be in the name of applying a general solution. That would be astronautics.
> 
> So yes, I want SVG and MathML to be supported without xmlns if at all 
> feasible, since they aren't unilateral extensions by the author to 
> address problems we are currently unaware of.

This argument seems to depend on what you understand as "cruft". I would 
consider it "crufty" to define two mechanisms when on generic is sufficient.

YMMV.

BR, Julian

Received on Friday, 4 April 2008 08:13:34 UTC