Re: edge issues with DOM, text/html, and xml serializations [was Re: handling fallback content for still images]

On 7/9/07, Robert Burns <rob@robburns.com> wrote:

>
> It then turned toward non-errant edge-case issues of implied <tbody>,
> and implied <colgroup>. (and perhaps even implied <body> and <head>,
> but perhaps not of practical concern). Overall, I'd say the thread
> has turned toward discussing what (if anything) the draft should say
> (or does say) about these issues. It isn't about hat we need a magic
> bullet that solves these issues. Rather about how we should deal with
> them (if we should deal with them at all).
>
> In the course of the conversation it was raised that Opera and soon
> Safari would add anonymous tbody to their XML processing (though I
> think a more accurate term would be that they will be treating the
> tbody as implied for CSS purposes since my understanding of an
> anonymous element is that it has no name/type).



Thankfully he answered this

Maciej Stachowiak wrote:

> It's not an actually element in the DOM, so it's not really accurate
> to say element. They are anonymous boxes in the CSS visual formatting
> model. See here for more detail than you ever wanted:
>
> http://www.w3.org/TR/CSS21/tables.html#anonymous-boxes
>
> These anonymous boxes let the table render, but they do not affect CSS
> selectors or DOM scripting.


And yes, my Opera does NOT add a <tbody> element to the DOM when parsing as
CSS.  I don't have access to Safari, so I can't test with it, but I'd be
interested in actual confirmation that Safari today actually adds a <tbody>
to the DOM.  It was ambiguously implied.  Konqueror behaves as expected like
Firefox and Opera when parsing XML.

I think he originally poorly chose the word "tbody" when he really meant
"anonymous table-row-group element"

Again, I don't think the spec has anything to say on this (though
> perhaps I missed it). So we've been discussing it to figure out if it
> should say something  about this.


Section 8.1.2.5 currently says a lot.
http://www.whatwg.org/specs/web-apps/current-work/#element-restrictions

In the case of <col>, though, HTML 5 is disallowing something HTML 4.01 (and
the XHTML 1 DTDs) allowed, and the justification of this seems solely based
on IE's behavior.  This is the only case like this I'm still uncomfortable
with, but it may be fine.

The more we discuss this, the more I'm convinced that there's not really
anything that needs to change.

§1.4.1 says:

> The "DOM5 HTML", "HTML5", and "XHTML5" representations cannot all
> represent the same content. For example, namespaces cannot be represented
> using "HTML5", but they are supported in "DOM5 HTML" and "XHTML5".
> Similarly, documents that use the noscript<http://www.whatwg.org/specs/web-apps/current-work/#noscript>feature can be represented using "HTML5", but cannot be represented with
> "XHTML5" and "DOM5 HTML". Comments that contain the string "-->" can be
> represented in "DOM5 HTML" but not in "HTML5" and "XHTML5". And so forth.


I guess this basically says what we're describing, but it could be worded
differently.

It should note, in some verbiage, that some valid (conforming) XHTML5
documents cannot be converted to valid HTML 5 without changing their DOM,
and vice versa.

Received on Monday, 9 July 2007 13:30:17 UTC