- From: Robert Burns <rob@robburns.com>
- Date: Thu, 9 Aug 2007 07:59:30 -0500
- To: HTML WG <public-html@w3.org>
table, column group, column, row groups, TABLE, CAPTION, COLGROUP, COL, THEAD, TFOOT, TR, part of my review of 3.15 Tabular data Re:<http://dev.w3.org/cvsweb/~checkout~/html5/spec/Overview.html? rev=1.78#tabular> SUMMARY -------------------------------- • editorial suggestions • consider allowing COL to be child of TABLE • consider keeping TFOOT before TBODY or TR for document conformance • consider adding DOM methods for insertBody and deleteBody TABLE -------------------------------- Consider allowing COL elements as a child of TABLE instead of only as a grandchild (child of COLGROUP). It's not clear what disallowing COL as a child of TABLE solves. If it is just to pave a cowpath, where authors mistakenly place the TFOOT last, then why not just let that mistake go through UA conformance criteria. That way we pave the cowpath, but we don't make it a truck route. Consider reverting the TABLE content model to have TFOOT before TBODY as a part of of document conformance. UA conformance can continue to allow TFOOT, but I think we should begin to push for better table rendering (including better incremental rendering). Certainly other things can prevent incremental rending of tables, but why add another. (see, RFC 1942[1]) Right now the ordered list of table contents has: "5. Either: Zero or more tbody elements, or One or more tr elements." Should we make that one or more TBODY elements, or do we really mean to allow a table with only a TFOOT, a THEAD, COLGROUP, and CAPTION (or even an empty TABLE since the others are all optional too). Currently there's no DOM method insertBody or deleteBody. It would be useful to have an insertBody that worked similarly to insertRow. Especially when working with more complex tables this would give easier access to inserting and deleting table bodies. COLGROUP -------------------------------- I can't tell what how the error should be handled when a colgroup contains col elements and the @span attribute has a positive integer value. The algorithm looks like it favors COL child elements over the @span attribute. We should make that clear in the COLGROUP subsection to inform both authors and UA developers of which takes precedence. For the paragraph: "The span DOM attribute must reflect the content attribute of the same name, with the exception that on setting, if the new value is 0, then an INDEX_SIZE_ERR exception must be raised." does this really involve a discrepancy between the two attributes: i.e., won't 'get' on the DOM attribute still return the same value as the content attribute, after the error (since the error will fail to set the DOM attribute or the content attribute)? This exception is not listed in other paragraphs related to other DOM attributes (with similar error handling situations). COL -------------------------------- Consider allowing COL as a child of TABLE instead of only as a child of COLGROUP TBODY -------------------------------- Nothing to report TR -------------------------------- Currently, there are two paragraphs that are nearly identical: one for the rowIndex element and one for the rowIndex DOM attribute (is this an Easter egg?). Right now there's no definition of a rowIndex element. "The rowIndex element must, if the element has a parent table element, or a parent tbody, thead, or tfoot element and a grandparent table element, return the index of the tr element in that table element's rows collection. If there is no such table element, then the attribute must return 0. "The rowIndex DOM attribute must, if the element has a parent table, tbody, thead, or tfoot element, return the index of the tr element in the parent element's rows collection (for tables, that's the rows collection; for table sections, that's the rows collection). If there is no such parent element, then the attribute must return 0." The sectionRowIndex is not defined. Perhaps that's the difference the two paragraphs are supposed to differentiate. [1]:: Though it has been superseded by RFC 2854, RFC 1942 has a great approach to interactive UA table rendering that got lost in the updated RFC. See: <http://tools.ietf.org/html/rfc1942>
Received on Thursday, 9 August 2007 12:59:48 UTC