W3C home > Mailing lists > Public > public-html@w3.org > July 2007

Re: handling fallback content for still images

From: Robert Burns <rob@robburns.com>
Date: Mon, 9 Jul 2007 02:52:10 -0500
Message-Id: <FE32B324-1C95-4BB3-A944-419E8A36F647@robburns.com>
Cc: public-html@w3.org
To: Thomas Broyer <t.broyer@gmail.com>

On Jul 9, 2007, at 2:35 AM, Thomas Broyer wrote:

> 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?
> Yes.
> "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."
>   — http://www.whatwg.org/specs/web-apps/current-work/#html-vs
>> So there won't be an HTML5 parser that's capable of parsing the xml
>> serialization. Is that right?
> 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.

Earlier in this thread Mcaiej indicated that Opera and Safari (now  
anyway with an XML de-serialization) are adding an anonymous tbody  
element for CSS purposes. This thread has evolved into basically  
discussing how to deal with subtle differences in the three forms of  
HTML5: DOM, XML and text/html. I think wit the CSS handled the way  
Opera and Safari are heading (with XML de-serialization) that takes  
care of many of the concerns I had. However, there still may be a  
need to address some subtleties in those particular elements.

> 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)

No, we're not discussing those tests anymore. These are new tests  
that are pure XML. The IE tests were incorrect, because IE wasn't  
consuming them as XML at all. We straightened that out already.

>>>  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:

Yes, I understand. The point here was that Henri said that tr cannot  
be a child of table in the text/html serialization. However, it can.  
 From an author's perspective, they want to know if they can start a  
table element and then insert a table row like:


And they can. This same fragment of text could could be authored for  
either text/html or xml. Depending on how its delivered to the HTML5  
UA, there will or will not be a tbody element in the DOM. That's  
where this thread has evolved. We're simply discussing how to deal  
with those subtle differences.

>> 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.

Yes, I know its been like that. However, the XML anonymous tbody  
element is a new approach that I think will help wither  
interoperability tremendously. The question being posed if there's  
anything the draft should say about things like that (or anything  
else) for author or UA guidance on conversions between serializations  
and DOM and treatment of especially XML de-serialized DOMs.

Take care,
Received on Monday, 9 July 2007 07:52:21 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:24 UTC