W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > December 2010

[Bug 11479] add new row and rowgroup elements

From: <bugzilla@jessica.w3.org>
Date: Mon, 06 Dec 2010 13:52:45 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1PPbUj-0006WO-F6@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11479

Toby Inkster <mail@tobyinkster.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mail@tobyinkster.co.uk

--- Comment #4 from Toby Inkster <mail@tobyinkster.co.uk> 2010-12-06 13:52:45 UTC ---
(In reply to comment #3)
> you can't expect joe web developer to read this bug report to know that tbody
> is supposed to group TR elements.  

Given than <thead>, <tbody> and <tfoot> are the only elements allowed to nestle
between <table> and <tr>, those are the only candidates for grouping <tr>
elements.

The H:TML draft makes it fairly clear which elements are allowed inside
<table>:

  http://www.w3.org/TR/html-markup/table.html#table

And the definition of <tbody> linked to makes it pretty clear that <tbody> is
intended for grouping rows:

  http://www.w3.org/TR/html-markup/tbody.html#tbody

> also, the word tbody suggests that it is a container for the collective whole
> of the content of the table just like body suggests that it is a container for
> the collective whole of the content of the page.

Changing an element's name can potentially break a lot of software. In
particular changing <tbody> to <rowgroup> would break every browser that
currently exists, thanks to HTML5's adoption algorithm and pre-HTML5 variants
of it. Introducing a new <rowgroup> that complemented <tbody> would have
similar effects.

I'm not saying that element name changes should never be considered, but they
are a major backcompat issue, so should only be done when there is an
overwhelming reason to do so.

> I do not think tbody is a good candidate as a row grouper.  I don't think
> anybody expects it to be.  I haven't seen any examples in any books which show
> it as such either (which also tells me what people are thinking, that tbody is
> a container for all the tr and td elements in the table).

Then you've not been looking very hard for examples. If you search Google for
"html tbody examples" the first result contains an example of multiple <tbody>
elements:

http://www.htmlcodetutorial.com/tables/_THEAD.html

So does the third:

http://www.htmlquick.com/reference/tags/tbody.html

As far as books are concerned, O'Reilly's "HTML & XHTML: The Definitive Guide"
offers this definition of <tbody>:

"Use the <tbody> tag to divide your table into discrete sections. The <tbody>
tag collects one or more rows into a group within a table."

The following section in the book contains a full example of a complicated
multi-section table, including multiple <tbody> elements.

> also, does tr have the span attribute and other attributes which are associated
> with col?  they should have the same attributes.

No, there is no reason to add the span attribute to <tr> or <tbody>. The column
span of a row or group of rows can be calculated by inspecting the table cells
(<td> and <th> elements) within it. <col> and <colgroup> are empty elements
(except for <colgroup> containing <col>) and do not contain any table cells
themselves, so it's necessary to have a span attribute to make their spans
explicit.

Adding span to <tr> and <tbody> would result in some authors adding redundant
information to the attribute. (Not needed because it can always be calculated.)
Some authors would get the information wrong which would lead to a mismatch
between what was specified in the attribute, and what could be calculated from
the cells. I'm guessing browsers would go down the "trust the calculation"
route as the alternative would make no sense (do you chop some cells out of a
row or rowgroup?). Thus the contents of the span attribute would become
universally ignored.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Monday, 6 December 2010 13:52:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:35 UTC