Re: handling fallback content for still images

2007/7/9, Robert Burns:
> I sense that some of the confusion (mine and others)  in this thread
> may be over what an HTML5 parser is. As we're defining HTML5 to
> accept two different serializations, I thought an HTML5 parser would
> be an parser capable of parsing HTML5 whether it was from the xml
> serialization and delivered as application/xml, text/xml, application/
> xhtml+xml (and several other MIME types) or the classic serialization
> and delivered as text/html.  However, this comment seems to indicate
> that an HTML5 parser only parses the classic serialization. Is that
> how you understand it?


"When a document is transmitted with an XML MIME type, such as
application/xhtml+xml, then it is processed by an XML processor by Web
browsers, and treated as an "XHTML5" document."

> So there won't be an HTML5 parser that's capable of parsing the xml
> serialization. Is that right?


But XML-like constructs have been inserted in the HTML serialization
(e.g. you're allowed to use a "trailing solidus" in "void elements",
just as if you were serializing an empty element with the minimized
XML syntax, e.g. <meta name="foo" content="bar" /> )

> Even if that is correct, I think it just moves our problem to other than
> the parser (which I'm not sure anyone was even saying it had to be
> about the parser). We will still have HTML5 UAs that will build a tree
> with a <tr> as a child of a <table>. We still may need to deal with
> conversions between HTML5 serializations.
> Even, if we go this Safari/Opera route and recommend an anonymous
> tbody element for CSS purposes, there will still be a difference for
> DOM purposes. That is we still need to think about how we move
> between and among HTML5 xml, HTML5 texts/html and HTML5 DOM (relating
> to tbody, col / colgroup, body and head).

I don't understand what you're talking about.

I suspect your tests are wrong due to the "IE XSLT hack", which has an
<xsl:output method="html">, and is applied by some browsers.
IMO, if you want IE to display XHTML, you'd better serve it as
application/xml and use a complete CSS stylesheet (containing –at
least– "head { display: none } p { display: block }" for instance)

> > The part of the spec that defines elements generally gives the
> > content model that is permissible with the XML serialization and
> > doesn't tell you that parts of the content models are impossible in
> > the text/html serialization.
> Well if someone:
> 1)  begins to build a table in the DOM and builds one without an
> explicit tbody,
> 2) then serializes to text/html
> 3) then the table will have no tbody in the text/html serialization,
> right?

You can't speak that way. Yes, there won't be any <tbody> or </tbody>
in the character stream. But as soon as you parse the document (which
is what tells you what's really in there), then yes:
> Upon de-serialization, the DOM will have a tbody though.

> Or do we want something different?

I don't think so.

It's been like this for ages now: in HTML 4.01, tables don't have tr
has children without a tbody (or thead or tfoot) in between, while in
XHTML 1.0 you can have a tr as a direct child of a table, without any
tbody at all.

Thomas Broyer

Received on Monday, 9 July 2007 07:35:31 UTC