- From: Roger B. Sidje <rbs@maths.uq.edu.au>
- Date: Thu, 05 Oct 2006 11:04:16 +1000
- To: Paul Topping <pault@dessci.com>
- CC: Ian Hickson <ian@hixie.ch>, www-math@w3.org, dev-tech-mathml@lists.mozilla.org
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. --- RBS > > Paul > > >>-----Original Message----- >>From: Ian Hickson [mailto:ian@hixie.ch] >>Sent: Wednesday, October 04, 2006 4:03 PM >>To: Paul Topping >>Cc: www-math@w3.org; dev-tech-mathml@lists.mozilla.org >>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 >>sense? >> >> >> >>>as you were worried about what MathPlayer might do with bad >> >>markup and >> >>>suggested that refusing to render the document might be the right >>>response. >> >>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 (http://whatwg.org/specs/web-apps/current-work/) 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). >> >>HTH, >>-- >>Ian Hickson U+1047E >>)\._.,--....,'``. fL >>http://ln.hixie.ch/ U+263A /, _.. \ >>_\ ;`._ ,. >>Things that are impossible just take longer. >>`._.-(,_..'--(,_..'`-.;.' >> > > >
Received on Thursday, 5 October 2006 01:06:28 UTC