Re: MathML-in-HTML5

On 5/10/2006 10:31 AM, Paul Topping wrote:

> So do you expect browsers like Mozilla and IE to accept HTML5 and handle
> it as defined by your spec? I'm going to guess that your answer is yes
> for Mozilla but no or "not my problem" for IE. If so, won't Mozilla have
> to have 3 parsers and renderers, one for tag-soup HTML, one for XHTML,
> and one for HTML5? Perhaps XHTML and HTML5 can share parsers and perhaps
> HTML5 can be rendered by Gecko as is, thereby reducing the number of
> pieces somewhat.
> Regardless of whether the above is right or wrong, it sounds like you
> are saying that adding MathML or <math> to HTML5 is not going to give us
> MathML support in everyday tag soup HTML. At the same time, I hear that
> Roger Sidje is talking about enhancing Mozilla so that his MathML
> renderer will work in everyday tag soup HTML. So perhaps you guys are
> talking about two completely separate things in this thread. Do I have
> it right?

To sum up, we are all discussing on what to agree upon. (Otherwise it 
wouldn't be that much a discussion.)

I could make the renderer to work in either/all the three cases. But 
what is practically of interest is that HTML5 gives us MathML support 
everywhere (with today's browers), and this is where what IE+MathPlayer 
comes in the picture. I could then focus on what has been agreed.

> Paul
>>-----Original Message-----
>>From: Ian Hickson [] 
>>Sent: Wednesday, October 04, 2006 4:03 PM
>>To: Paul Topping
>>Subject: RE: MathML-in-HTML5
>>On Wed, 4 Oct 2006, Paul Topping wrote:
>>>I sense some sort of conflicting themes here or perhaps I'm just 
>>>confused. Your earlier comments made me think that HTML 5 
>>might be about 
>>>stronger validation
>>I don't really understand what this means. Stronger than 
>>what? In what 
>>>as you were worried about what MathPlayer might do with bad 
>>markup and 
>>>suggested that refusing to render the document might be the right 
>>I was merely pointing out that the term "XML islands" 
>>suggests XML-like 
>>processing, which would imply draconian error handling. I 
>>wasn't trying to 
>>imply that this was the better solution.
>>>So, this made me wonder what HTML 5 really was supposed to 
>>be. The name 
>>>would imply that it is HTML's tag soup extended with some 
>>new stuff like 
>>>MathML and, perhaps, with some of the worst soup removed if it was 
>>>deemed unnecessary to compatibility with all the HTML out 
>>in the world 
>>>and the tools that make it. I would also assume that since 
>>your WHATWG 
>>>document ( seems to 
>>>distinguish between XHTML5 and HTML5 that they are versions 
>>of XHTML and 
>>>HTML enhanced in parallel ways. Am I wrong?
>>The WHATWG Web Apps 1.0 specification defines a set of 
>>features for Web 
>>browsers (mostly existing features previously defined in 
>>HTML4 and DOM2 
>>HTML, or implemented as proprietary extensions, though there 
>>are some new 
>>features as well). Most features are described in terms of 
>>DOM processing 
>>rules, e.g. new DOM interfaces or new rules for handling 
>>certain elements 
>>in DOM trees. In addition, it defines two serialisation syntaxes for 
>>representing documents/applications that use these features. 
>>One of these 
>>serialisations is just XML (with namespaces); some components 
>>of which are 
>>to be in the XHTML namespace and are therefore known as 
>>XHTML5. The other 
>>serialisation is a custom language known as HTML5; the specification 
>>defines very specific parsing rules (including error handling 
>>rules) for 
>>how to obtain a DOM tree from an HTML5 file.
>>In the context of HTML5 the term "tag soup" is meaningless, 
>>since there 
>>is no UA-defined handling anymore, the spec defines all 
>>handling (in an 
>>attempt to foster increased interoperability).
>>Ian Hickson               U+1047E                
>>)\._.,--....,'``.    fL
>>       U+263A                /,   _.. \   
>>_\  ;`._ ,.
>>Things that are impossible just take longer.   

Received on Thursday, 5 October 2006 01:06:28 UTC