Can TR element be direct child node of TABLE element?

Discussion in 'HTML' started by Patient Guy, Feb 13, 2005.

  1. Patient Guy

    Patient Guy Guest

    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.
     
    Patient Guy, Feb 13, 2005
    #1
    1. Advertising

  2. 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
     
    Roy Schestowitz, Feb 13, 2005
    #2
    1. Advertising

  3. On Sun, 13 Feb 2005 11:17:00 GMT, Patient Guy
    <> 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
     
    Jan Roland Eriksson, Feb 13, 2005
    #3
  4. 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.


    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
     
    Jukka K. Korpela, Feb 13, 2005
    #4
  5. Patient Guy

    Spartanicus Guest

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

    Roy Schestowitz <> wrote:

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

    --
    Spartanicus
     
    Spartanicus, Feb 13, 2005
    #5
  6. [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.
     
    Michael Winter, Feb 13, 2005
    #6
  7. 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.
     
    Richard Cornford, Feb 13, 2005
    #7
  8. Patient Guy

    Nick Kew Guest

    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
     
    Nick Kew, Feb 13, 2005
    #8
  9. Spartanicus wrote:

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

    > Roy Schestowitz <> wrote:
    >
    >>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.


    I take your point.

    Roy

    --
    Roy Schestowitz
    http://schestowitz.com
     
    Roy Schestowitz, Feb 13, 2005
    #9
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    0
    Views:
    1,642
  2. Bryan Ax
    Replies:
    6
    Views:
    566
    Peter Flynn
    May 17, 2006
  3. Tjerk Wolterink
    Replies:
    2
    Views:
    1,504
    Dimitre Novatchev
    Aug 24, 2006
  4. Replies:
    3
    Views:
    3,932
    A. Bolmarcich
    Oct 20, 2006
  5. Replies:
    1
    Views:
    1,228
    Joe Kesselman
    Nov 1, 2006
Loading...

Share This Page