- From: James Clark <jjc@jclark.com>
- Date: Thu, 6 Sep 2012 15:16:59 +0700
- To: John Cowan <cowan@mercury.ccil.org>
- Cc: Uche Ogbuji <uche@ogbuji.net>, public-microxml@w3.org
- Message-ID: <CANz3_EZqZqGAMvVSw4sWzppF899gjMdSoPmKTGCHufMpGnWSqg@mail.gmail.com>
On Tue, Sep 4, 2012 at 10:30 PM, John Cowan <cowan@mercury.ccil.org> wrote: > One of the nice things about MicroXML documents, indeed > James's original motivation for them, is that they are a good format > for human readable documents. You can keep them around for processing > with XML or MicroXML toolchains, but if they use the right elements > and attributes, you can also view them casually in any web browser. > The only price of that is a fifteen-character signal (sixteen if you > have a trailing newline) that forces the web browser to DTRT rather than > enabling some unpredictable quirks mode. > I think we badly need to get some precision about our design goals are with respect to HTML5. My original goal was that you could author valid HTML5 documents by - following the syntactic rules of MicroXML, and - following the constraints of the HTML vocabulary, where these constraints were expressed in terms of the MicroXML data model. MicroXML would thereby provide a way to avoid the syntactic complexity of the HTML syntax of HTML5. However, there are a number of things that stop this working: a) information about the DOCTYPE declaration is not in the MicroXML data model b) HTML5 doesn't treat <X/> and <X></X> as equivalent c) MicroXML doesn't allow prefixed attribute names, but some attributes in HTML (notably xlink:href in SVG) require prefixes In addition, I'm not sure that many people found my original goal particularly useful. Point (c) is also a problem for out current design goal: 8. MicroXML shall be able to straightforwardly represent HTML So at this point I'm not at all clear what we should be trying to achieve vis-a-vis HTML5. If the goal is to be able view MicroXML documents that happen to use the right element/attribute names "casually in a browser", then does it matter that the browser will use quirks mode (if we don't allow DOCTYPE)? For robust, standards-compliant delivery of HTML5, my current inclination is to use an MicroXML->HTML5 serializer that does the right thing with empty elements, and adds a DOCTYPE declaration. We should at least have a standard way of representing an HTML5 DOM (at least any HTML5 DOM representable in the HTML syntax) in MicroXML, which means we need some convention for dealing with xlink:href. So my current position is: - no bare DOCTYPE - no to the additional HTML5 restriction on XML comments James
Received on Thursday, 6 September 2012 08:17:47 UTC