Re: Supporting MathML and SVG in text/html, and related topics

On Wed, 16 Apr 2008 14:05:34 +0200, Paul Libbrecht <paul@activemath.org>  
wrote:
> Le 16 avr. 08 à 12:46, Anne van Kesteren a écrit :
>> The HTML DOM and XML DOM have a small number of differences
>> described in http://www.whatwg.org/specs/web-apps/current-work/
>> multipage/section-apis-in.html#apis-in that have been created at
>> the time the initial set of DOM specifications came to be. Web
>> pages rely on those differences and there's not much we can do
>> about that.
>>
>> Essentially the DOM is the same. It's just that some getters and
>> setters have slight variations in code paths based on whether it's
>> an HTML or XML document.
>
> That really doesn't seem to justify to mix HTML5 model and parsing!

Indeed, it justifies the DOM differences for HTML and XML...


> Especially if you consider the amount of pages that expect the case
> corrections to be not made (considerably more neglectable than the
> amount of XHTML URLs out there!).
>
> I guess it would be acceptable to say that a DOM revision for this
> accepts case-insensitivity.

I don't understand these statements.


>> (XHTML5 is the XML serialization of the HTML 5 language. HTML5 is
>> the HTML serialization of HTML 5.)
>
> That's all there should be about it: converting HTML5 to XHTML5.

I'm not sure what you're suggesting here, but just "converting" doesn't  
work, that would break document.write(), etc.


>> The HTML5 DOM is compatible with existing implementations and more
>> or less identical to the HTML4 DOM for what's being considered here.
>
>>> The question remains: can't all the enhancements to HTML model done
>>> by HTML5 be done within an XML model decoupled from parsing?
>>
>> This is already done,
>
> That tastes like good news.
> I really insist it would be nice to separate the specs!
>
>> but to get MathML or SVG into the HTML serialization of HTML 5 you
>> need to change the parser. Otherwise you can't utilize the deployed
>> HTML infrastructure that most of the Web is based on.
>
> yes, I understand that for sure, and I also understand that this
> involves refining the parser by appropriate heuristics.

I'm frankly a bit confused by what you want. The reason the HTML parser is  
as it is, is because of compatibility with deployed content. We can't  
change much about that. We can make extensions to the current parser if  
we're careful, but we can't just change how it works.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Received on Wednesday, 16 April 2008 15:20:35 UTC