Can TR element be direct child node of TABLE element?

[Patient Guy]

In my reading of the Strict and Transitional DTD for HTML 4.0, the table
row (TR) elements are contained within table section elements: THEAD,
TFOOT, and TBODY.

The table section elements are the defined contents of the TABLE element.
The TR element is not defined as an "immediate" or "direct" contained
element of TABLE.

Given that

i. the use of the table section elements is optional, but that
ii. TBODY is implicit when no table section elements are specified with an
HTML table,

what does an HTML parsing agent (browser) do when tree-building from a
TABLE node and it encounters a TR element without having encountered any
table section element?

Does it:

1. append the TR element node to the TABLE node?

OR

2. examine for the presence of a table section node, and failing to find
one instantiated, perform the following steps in this order:
a. instantiate a TBODY element node
b. append it to the TABLE node
c. create the TR element node
d. append the TR node to the TBODY node
e. continue reading the HTML and develop the table according the
specification?
Corrections to my reading of the HTML DTD are warmly appreciated.

[Roy Schestowitz]

Patient Guy wrote:

In my reading of the Strict and Transitional DTD for HTML 4.0, the table
row (TR) elements are contained within table section elements: THEAD,
TFOOT, and TBODY.

The table section elements are the defined contents of the TABLE element.
The TR element is not defined as an "immediate" or "direct" contained
element of TABLE.

Given that

i. the use of the table section elements is optional, but that
ii. TBODY is implicit when no table section elements are specified with an
HTML table,

what does an HTML parsing agent (browser) do when tree-building from a
TABLE node and it encounters a TR element without having encountered any
table section element?

Does it:

1. append the TR element node to the TABLE node?

OR

2. examine for the presence of a table section node, and failing to find
one instantiated, perform the following steps in this order:
a. instantiate a TBODY element node
b. append it to the TABLE node
c. create the TR element node
d. append the TR node to the TBODY node
e. continue reading the HTML and develop the table according the
specification?
Corrections to my reading of the HTML DTD are warmly appreciated.

Sources I read say that <tbody> and the like are mandatory. The indentation
and purification tool called 'tidy' insists on it too.

However, W3C validators do not insist on it (at least XHTML, but I think
others too from what I can recall). The question is then whether you want
your page to validate safely or also remain a stickler. Then again,
validators evolve... just make sure you specify a version number which
works.

Roy
--
Roy Schestowitz
http://schestowitz.com

[Jan Roland Eriksson]

On Sun, 13 Feb 2005 11:17:00 GMT, Patient Guy
<Pa*********@nowhere.to.be.found.com> wrote:

[..fup's reduced since this is not about scripting..]

In my reading of the Strict and Transitional DTD for HTML 4.0, the table
row (TR) elements are contained within table section elements: THEAD,
TFOOT, and TBODY.

The table section elements are the defined contents of the TABLE element.
The TR element is not defined as an "immediate" or "direct" contained
element of TABLE.
[...]
what does an HTML parsing agent (browser) do when tree-building from..

The easiest way to find out what is supposed to happen from an SGML
(HTML) standpoint is to make use of SGMLNORM and let it generate
normalized markup from a few examples you set up for test.

http://valet.webthing.com/code/

Well, so much for the theory; what a www browser might be programmed to
do will be something different and can not be precisely understood
without a study of the browsers source code.

--
Rex

[Jukka K. Korpela]

Patient Guy <Pa*********@nowhere.to.be.found.com> wrote:

In my reading of the Strict and Transitional DTD for HTML 4.0, the
table row (TR) elements are contained within table section elements:
THEAD, TFOOT, and TBODY.
That is correct. The same is true for HTML 4.01, which is better reading
these days than HTML 4.0 (though the differences are small and don't matter
here).
The table section elements are the defined contents of the TABLE
element. The TR element is not defined as an "immediate" or "direct"
contained element of TABLE.
Correct. Things may _look_ different when you look at the source code of a
valid HTML 4.01 document, but that's because you don't see the omissable
start and end tags if they have been omitted.

In XHTML things change, since it does not allow any start or end tag
omission. Authors of XHTML 1.0 did not want to disallow the old practice of
writing TR elements inside a TABLE element without intervening markup, so
they made up an ad hoc rule, allowing TR as direct descendant of TABLE
(well, tr as direct descendant of table, to speak XML):
<!ELEMENT table
(caption?, (col*|colgroup*), thead?, tfoot?, (tbody+|tr+))>
Given that

i. the use of the table section elements is optional,
Not really. The elements THEAD and TFOOT are optional, but a TBODY element
is a required part of a TABLE element's content. The _tags_ <tbody> and
</tbody> are optional, though.
but that
ii. TBODY is implicit when no table section elements are specified with
an HTML table,
Not really. The element's start and end tags are implicit.
what does an HTML parsing agent (browser) do when tree-building from a
TABLE node and it encounters a TR element without having encountered
any table section element?
Technically, an HTML parsing agent is not required to build any tree, by
HTML specifications. For practical reasons, some tree structure is needed.
The appropriate way to handle a <tr> tag encountered inside a TABLE element
but without having seen any <thead>, <tfoot>, or <tbody> tag is to imply a
<tbody> tag. Consequently, the tree should have a TBODY element as a
subelement of TABLE and with the TR element(s) as its subelements. Whether
browsers actually do this might not be directly visible.
Does it:

1. append the TR element node to the TABLE node?
That would be inappropriate for HTML 4.0 or HTML 4.01 (though correct for
XHTML 1.0).
OR

2. examine for the presence of a table section node, and failing to
find one instantiated, perform the following steps in this order:
a. instantiate a TBODY element node
b. append it to the TABLE node
c. create the TR element node
d. append the TR node to the TBODY node
e. continue reading the HTML and develop the table according the
specification?

Well, yes, that would be a (somewhat complicated) different variant of the
description I wrote, assuming that "appending" means creation of something
that corresponds to subelement relationship.

It's really a special case of handling omissible tags. Consider the
following fairly minimal HTML 4.01 document:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<title>demo</title>
<p>Hello world.</p>
Bye world.

An HTML parser needs to infer quite a many start and end tags or - to put
it in another way - to recognize elements even though some start and end
tags have been omitted. For example, upon seeing the tag <p>, the parser
needs to conclude that the HEAD element that had been started (though its
start tag had to be inferred) must be considered as closed (in a sense,
</head> is implied first) and that the BODY element has been started (in a
sense, <body> is implied next). The logical document tree does contains the
HTML element as the root element and the HEAD and BODY element as its
subelements (even though all of these three elements have their start and
end tags omitted), and the P element is a subelement of BODY.

This means, for example, that if there is a style sheet rule that applies
to the BODY element, it affects the text "Bye world.", which is directly
inside the BODY element, and it may affect indirectly, via inheritance, the
text inside the P element. Some browsers used to get this wrong - e.g.,
they did not apply such a rule when the start tag <body> was omitted - so
probably they were not that good at building document trees correctly.

***

You pointlessly crossposted to _three_ groups. The JavaScript group was
_certainly_ wrong for this question. I have restricted followups to the
group that is most specifically devoted to the topic that your question
belongs to.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

[Michael Winter]

[Follow-up ignored: cross-posted to clj, ah and ciwah. Follow-ups set
to ciwah]

Roy Schestowitz wrote:

Patient Guy wrote:

The TR element is not defined as an "immediate" or "direct"
contained element of TABLE.
In other words, a not a child but a descendant.

[snip]
what does an HTML parsing agent (browser) do when tree-building
from a TABLE node and it encounters a TR element without having
encountered any table section element?

Well it depends. Will it encounter any table section elements?

If not, presumably an implementation will create a TBODY element and
place all table rows inside that element. For example, this is what an
implementation should do should a document dynamically create a TABLE
element via the DOM and insert a new row without first creating a TBODY.

If table section elements will be encountered, then we're talking
error correction and the user agent is likely to do anything.

[snip]
Sources I read say that <tbody> and the like are mandatory.

Yes, a TBODY element is mandatory, however its start and end tags are
optional.

"The TBODY start tag is always required except when the table
contains only one table body and no table head or foot
sections."

In the latter case, the table body should be created implicitly.

[snip]

Mike

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.

[Lachlan Hunt]

Jukka K. Korpela wrote:

Patient Guy <Pa*********@nowhere.to.be.found.com> wrote:

1. append the TR element node to the TABLE node?
That would be inappropriate for HTML 4.0 or HTML 4.01 (though correct for
XHTML 1.0).

Although it is correct for XHTML 1.0, it should be noted that current
user agents still imply the tbody element when served as text/html. I'm
not sure whether or not that is the correct behaviour according to the
spec for those circumstances, but it is (I believe) what all of the
popular browsers do.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<title>demo</title>
<p>Hello world.</p>
Bye world.

<snip>description of how the DOM is built for the above example</snip>

Run that example, and some other examples containing tables both with
and without the tbody element through the validator, and select the
"Show Parse Tree" from the extended interface.
http://validator.w3.org/detailed.html or
http://validator.w3.org/file-upload.html

You can also use the DOM inspector within Mozilla or Firefox to see the
tree it builds using such examples.

--
Lachlan Hunt
http://lachy.id.au/
http://GetFirefox.com/ Rediscover the Web
http://SpreadFirefox.com/ Igniting the Web

[Richard Cornford]

Patient Guy wrote:

In my reading of the Strict and Transitional DTD for
HTML 4.0, the table row (TR) elements/8table section
elements: THEAD, TFOOT, and TBODY.
Yes, that is correct.
The table section elements are the defined contents of
the TABLE element.
Along with some others, e.g. CAPTION.
The TR element is not defined as an "immediate" or
"direct" contained element of TABLE.

Given that

i. the use of the table section elements is optional, but that
ii. TBODY is implicit when no table section elements are
specified with an HTML table,

what does an HTML parsing agent (browser) do when tree-building
from a TABLE node and it encounters a TR element without having
encountered any table section element?

Does it:

1. append the TR element node to the TABLE node?
No.
OR

2. examine for the presence of a table section node, and failing to
find one instantiated, perform the following steps in this order:
No, that is much more complicated than is necessary. There is no need to
examine the existing table to see if it already contains a table
section. If an encountered TR opening tag is not contained in a table
section then any preceding table section elements have been closed and
finished, they are unaffected by any following TR elements.
a. instantiate a TBODY element node
b. append it to the TABLE node
c. create the TR element node
d. append the TR node to the TBODY node
e. continue reading the HTML and develop the table
according the specification?
That is what happens regardless of any preceding mark-up.
Corrections to my reading of the HTML DTD are warmly appreciated.

The important detail to note from the HTML DTDs is that both the opening
and closing TBODY tags are _optional_. That is, they do not need to be
explicitly included in HTML source mark-up. So a browser encountering a
TR as an apparent direct child of a TABLE is in a position to infer that
the TR is preceded by an opening TBODY tag even though no such tag is
present. The corresponding closing TBODY tag can then be inferred when
the HTML parser encounters an element that cannot be a descendent of the
TBODY (disregarding other tables nested within cells), such as the
closing TABLE tag or an opening tag for another table section.

HTML offers many optional tags, such as the closing P tag, which can be
inferred when P content apparently includes an element that cannot be
contained in a P element (any element that is not categorised as
%inline). These DTD details often elude HTML authors and causes them to
create mark-up that "works" but does not correspond with their
intentions or expectations.

As a result it is widely felt that authors should explicitly include all
tags regardless of whether they are optional in the DTDs. XHTML makes
this a necessity. Counter arguments point out that taking advantage of
optional opening and closing tags allows less mark-up to be sent to the
browser.

Richard.

[Nick Kew]

Jan Roland Eriksson wrote:

what does an HTML parsing agent (browser) do when tree-building from..

The easiest way to find out what is supposed to happen from an SGML
(HTML) standpoint is to make use of SGMLNORM and let it generate
normalized markup from a few examples you set up for test.

http://valet.webthing.com/code/

Indeed. But I think for HTML, I'd recommend the "visual validator"
mode of Page Valet ahead of that, for most users. It is of course
the same underlying parser (OpenSP), but presents a normalised
source view that is the technically-correct parse tree.

http://valet.webthing.com/page/

--
Nick Kew

[Jukka K. Korpela]

Michael Winter <m.******@blueyonder.co.invalid> wrote:

Yes, a TBODY element is mandatory, however its start and end tags are
optional.
Yes.
"The TBODY start tag is always required except when the table
contains only one table body and no table head or foot
sections."

I was bit surprised at finding that statement in the HTML specification, at
http://www.w3.org/TR/REC-html40/stru....html#h-11.2.3

I'm pretty sure it's an oversight. It's debatable whether it is to be read
as a normative statement, i.e. whether a document conforming to the HTML
4.01 specification must obey it.

In any case, it expresses a requirement that is not derivable from the DTD.
The following piece of markup violates the statement but is valid:

<table>
<thead>
<tr><th>foo
</thead>
<tr><td>bar
</table>

So is the following (with two TBODY elements, the first with both start and
end tags implied):

<table>
<tr><td>bar
<tbody>
<tr><td>bar too
</table>

It's rather perverse, but valid markup.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

[Michael Winter]

Jukka K. Korpela wrote:

[snipped specification quote]

I was bit surprised at finding that statement in the HTML
specification, at
http://www.w3.org/TR/REC-html40/stru....html#h-11.2.3
Thank you. As a rule, I always provide a link to content I quote or
reference, but I forgot to in my last post.
[...] It's debatable whether it is to be read as a normative
statement [...]
I suppose it is, but it's quite possible it is normative. The
statement prior to my quote is (emphasis is my own):

"The following summarizes which tags are *required* and which
may be omitted:"

Then again, I must say I'm confused when the key words listed in
section 4[1] apply (of which one is "required"). For example, when
describing the TITLE element[2], the word "must" is emphasised, but I
don't think other key words are anywhere else in the specification.
In any case, it expresses a requirement that is not derivable from
the DTD.

But there are other conditions that are stated only in the prose and
cannot be indicated by the DTD (none spring to mind at the moment,
though). I'm not familiar enough with SGML to know so perhaps you
could tell me if it would be feasible to define the constraint.

[snip]

Mike
References:

[1] <URL:http://www.w3.org/TR/html4/conform.html>
[2] <URL:http://www.w3.org/TR/html4/struct/global.html#h-7.4.2>

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.

[Lauri Raittila]

in comp.infosystems.www.authoring.html, Jukka K. Korpela wrote:

Michael Winter <m.******@blueyonder.co.invalid> wrote:

Yes, a TBODY element is mandatory, however its start and end tags are
optional.

Yes.

"The TBODY start tag is always required except when the table
contains only one table body and no table head or foot
sections."

I was bit surprised at finding that statement in the HTML specification, at
http://www.w3.org/TR/REC-html40/stru....html#h-11.2.3
In any case, it expresses a requirement that is not derivable from the DTD.

Maybe it is because </thead> is optional, so, if you write

<table>
<thead><tr><td>Foo
<tr><td>Data
</table>

It is invalid (by WDG validator), as there is no TBODY.

So maybe someone found this out, and above text was added to fix problem,
whitout considering markup you posted.


--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
Utrecht, NL.