Can TR element be direct child node of TABLE element?

P

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

Roy Schestowitz

Patient said:
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
 
J

Jan Roland Eriksson

On Sun, 13 Feb 2005 11:17:00 GMT, Patient Guy

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

Jukka K. Korpela

Patient Guy said:
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
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.
 
S

Spartanicus

It's netiquette to note in the message body if you specify a follow up
group, reset to alt.html.

Roy Schestowitz said:
Then again, validators evolve.

They may, but that won't affect whether or not an absent tbody will be
reported as an error. A validator does one thing, and one thing only:
check against the DTD. Anything that doesn't do that is not a validator.
 
M

Michael Winter

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


In other words, a not a child but a descendant.

[snip]

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
 
R

Richard Cornford

Patient said:
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.
 
N

Nick Kew

Jan Roland Eriksson wrote:

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/
 
R

Roy Schestowitz

Spartanicus said:
It's netiquette to note in the message body if you specify a follow up
group, reset to alt.html.

I soon realised that this mistake was made.

In the spirit of netiquette, KNode chooses to pick only one (the first)
newsgroup for follow-up. I did not bother checking if the OP cross-posted.
They may, but that won't affect whether or not an absent tbody will be
reported as an error. A validator does one thing, and one thing only:
check against the DTD. Anything that doesn't do that is not a validator.

I take your point.

Roy
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,899
Latest member
RodneyMcAu

Latest Threads

Top