OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] SVG and MathML in HTML5

rjelliffe  wrote:
> As soon as they are nested in some other format, they *cannot* be
> well-formed XML anyway. XML starts at the entity level: the physical
> structure: bits at the start of a representation.

This is probably true when you say so but not relevant. We are not
talking about SVG and MathML inside HTML5 being well-formed in some
final analysis. But it is sad that we can no longer copy and paste
such SVG and MathML from an HTML5 document and into let us say an SVG
or an MathML document and expect it to well-formed or valid for that
matter. All element and attribute names could be a mixture of
upper-case and lower-case, the attributes quoted and not quoted, etc.
That is a little sad but probably unavoidable.

> the intersection of them (trying to be XML and HTML at the same time, or having islands of
> XML) may be more trouble than it is worth.

I have not made up my mind yet about this polyglot XHTML5,
but I find it interesting for the following reasons:

1. Very many developers would like to restrict HTML5 to a subset that
is at least XML so we can use our XML tools, we have been used to use
when developing XHTML 1.0/1.1.

2. We would not only like our HTML5 to be well-formed, we would also
like it to use lower-case for HTML elements and attributes.

3. "HTML5 + 1 + 2" you can develop, reuse and maintain with XML tools
and still serve it to browsers with "text/html". And it will validate
as HTML5.

4. But somehow it is tempting to add a few more restrictions, so you
could also serve the document with "application/xhtml+xml" without
having to change anything except the mimetype.

5. Polyglot XHTML5 could be a nice option even if you decide always to
use "text/html" for browsers. Why? Because it is a sensible set of
restrictions. All other sets of HTML5 restrictions will have a
tendency to be much more arbitrary, to be a little bit of this and a
little bit of that in a much less clear cut way.

6. Somehow I liked the polyglot spec. It made me think about a lot of
markup and browser related DOM issues I have never been thinking about
before. Almost any other more or less arbitrary restriction of HTML5
doesn't teach most of us anything.

Jesper Tverskov

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS