Extensibility vs. supporting SVG and MathML

On Apr 4, 2008, at 06:32, Sam Ruby wrote:
> As such, I don't believe that this meets the stated requirement of  
> "Ability for an author to unilaterally extend the language to  
> address problems we are currently unaware of and that therefore are  
> not covered by existing functionality".

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.

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

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.

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.

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

Received on Friday, 4 April 2008 06:54:30 UTC