By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,740 Members | 844 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,740 IT Pros & Developers. It's quick & easy.

Can TR element be direct child node of TABLE element?

P: n/a


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.
Jul 23 '05 #1
Share this Question
Share on Google+
5 Replies


P: n/a
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
Jul 23 '05 #2

P: n/a
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

Jul 23 '05 #3

P: n/a
Roy Schestowitz <ne********@schestowitz.com> wrote in
news:cu**********@godfrey.mcc.ac.uk:
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.


Both the Strict and the Transitional do appear to say that the TBODY
element MUST occur one or more times in a table:

http://www.w3.org/TR/html401/sgml/dtd.html
http://www.w3.org/TR/html401/sgml/loosedtd.html

Probably my thoughts about TBODY being optional came from this:

http://www.w3.org/TR/html401/struct/tables.html

where the document text said:

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

If the TBODY start tag is always required according to the DTD, then it is
seemingly contradictory to even talk about exceptions.

I think most tables coded by hand never bother with TBODY only because
THEAD and TFOOT have been effectively useless: I have yet to see a web
browser that is able to follow the wishes of those who thought of the table
sections concept in which headers/footers are printed from page to page
when the table itself is printed, so thus the inclusion of TBODY is
superfluous and ignored by habit.

The tool TIDY is probably conforming to a reading of the DTD, which seems
sensible.
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.


I suppose the thing for me to do is to run a simple example HTML document
with a table through some well-known popular browsers and then inspect
their DOM and assume that if they all agree on the construction of the
table, then they all must be reading the specification the same way, likely
the correct way.
Jul 23 '05 #4

P: n/a
[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.
Jul 23 '05 #5

P: n/a
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.
Jul 23 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.