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

Re: handling fallback content for still images

From: Jon Barnett <jonbarnett@gmail.com>
Date: Fri, 6 Jul 2007 19:34:16 -0500
Message-ID: <bde87dd20707061734r1be04592na3902ffbce00ce4e@mail.gmail.com>
To: "scott lewis" <sfl@scotfl.ca>
Cc: "Robert Burns" <rob@robburns.com>, "HTML Working Group" <public-html@w3.org>
On 7/6/07, scott lewis <sfl@scotfl.ca> wrote:

> > I'm not sure if Thomas is confused. There is certainly an issue
> > that our recommendations should deal with. In other words when
> > serializing as XML, should a translating UA include explicit
> > <tbody> elements when serializing to XMl? There may problems with
> > doing so, but there will also be problems with not doing so. For
> > example, a user may wonder why the CSS stopped working simply from
> > saving to a different serialization.
> How would the CSS break? CSS rules are applied against the DOM and
> the <tbody> will always be represented in the DOM. (If the element is
> not present in a serialized document it is inserted into the DOM by
> the UA.)
> scott.

I created two test pages:

In Firefox, Opera, and Konqueror, in the HTML document, the <tbody> element
is generated as it should be: its start tag is optional, and this affects
both the DOM and CSS selectors.  In Konqueror, the Javascript fails, but the
point is still valid.

In the XML document, the <tbody> is not generated.  <tr> is a child of
<table> - this is expected, since you don't expect the UA to insert things
into an XML document.

IE7: In both documents, the <tbody> element is generated.  Even though I'm
using my XSL hack to make IE render the XML document, I suspect that IE's
XSL parser transforms the XML into plain HTML text that is then parsed by
IE's HTML parser (this explains my last example that used it as well)

If my HTML document were parsed, reserialized as XHTML, parsed, and
reserialized as HTML, and parsed, the new HTML DOM would be the same as the
original HTML DOM.

If my XML document were parsed, reserialized as HTML, parsed, and
reserialized as XML, and parsed, the new XML DOM would be different from the
original XML DOM because a new <tbody> element would be present in the
document, and the table > tr > td selector would no longer work (among other

This issue doesn't apply to any other elements that have optional start tags
in HTML - since <html>, <head>, <body> are required, it would be
non-conforming for an XHTML document not to have them to begin with.

Therefore, I propose that the content model section here be changed:
from "followed by either zero or more
*or* one or more tr
to "followed by either zero or more

That would make it non-conforming for a <tr> element to be a child of
<table> in XHTML (it would be automatically inserted in HTML syntax.

(The same issue would apply to <col>, and the specification already
disallows <col> as a child of table in the same manner I'm proposing)

Making <table><tr>... non-conforming in XHTML would not break existing web
pages - just their validation.

Jon Barnett
Received on Saturday, 7 July 2007 00:34:22 UTC

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