Re: [whatwg] Table integrity and conformance
On Fri, 10 Nov 2006 00:36:20 +0600, Henri Sivonen [EMAIL PROTECTED] wrote: Do you mean moving all TFOOTs after TBODYs, so that the HTML 4.01 placement would be forbidden? TFOOT should be allowed before TBODY because it helps progessive rendering on paged media. I'm not sure if it should be allowed after TBODY as well -- the renderer cannot finish layout of the first page until it knows whether or not there is a TFOOT at the end. HTML 4.01 has had TFOOT above TBODY for years. Have progressive paged media renderers made use of it? Can you give examples of shipping progressive paged media renderers? Maybe Prince? I don't know, really. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Table integrity and conformance
On Nov 9, 2006, at 13:18, Henri Sivonen wrote: Not deployed yet. The table integrity checker is now part of all (X)HTML presets at http://hsivonen.iki.fi/validator/ There's a pseudo-schema called http://hsivonen.iki.fi/checkers/table/ which isn't a schema but a magic URL that causes the system to instantiate the table integrity checker. There's a pseudo-pseudo-schema called http://hsivonen.iki.fi/checkers/ all/ which expands to all pseudo-schemas, but at the moment, there's only one. This isn't necessarily release often, but this is release early. I have very few test cases. If the checker doesn't work as previously advertised in this thread, please let me know. There are other new features, too: * The pipeline has an xml:id processor in it and a filter that applies IDness to XHTML id. This allows custom Schematron schemas to use the id() function without a DTD. * There's a very preliminary preview of support for the embed element. There are also a couple of bug fixes. The XHTML5 conformance checker preview version shouldn't crash anymore. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] Table integrity and conformance
Lachlan Hunt wrote: scope= will probably only be allowed for THs. Maybe it should be REQUIRED for THs that aren't in obvious locations (first row, first column, or whatever). Maybe. I think the spec should explicitly define how to determine which header cells are associated with each cell. IIRC, the HTML 4 spec does define an algorithm like that, so maybe it could be improved. The HTML 4 spec says to use TD for a cell that functions both as data cell and an header cell. [1] For these cases, it would be necessary to allow scope on TDs. [1] http://www.w3.org/TR/html40/struct/tables.html#h-11.4.1 ~fantasai
Re: [whatwg] Table integrity and conformance
Henri Sivonen wrote: On Oct 27, 2006, at 16:21, Anne van Kesteren wrote: On Fri, 27 Oct 2006 15:17:16 +0200, Lachlan Hunt [EMAIL PROTECTED] wrote: That's fine for document conformance, but what about how browsers will handle it? Is the spec still going to require browsers to render overlapping cells, or would it be possible to resolve this difference between HTML and XHTML rendering, as documented in CSS 2.1 [1]? http://www.w3.org/mid/[EMAIL PROTECTED] [1] http://www.w3.org/TR/CSS21/tables.html#q7 WHOA! How on earth did that end up in a CSS WG draft in general and in the CSS 2.1 draft in particular? Easy: it didn't get removed. http://www.w3.org/TR/CSS2/tables.html#q7 ~fantasai
Re: [whatwg] Table integrity and conformance
Michel Fortin wrote: Sometime, presentational information is needed to display a document correctly, and in those few cases where the presentation is tied to the content, I think it belongs in the markup. The align attribute, when used on table cells, covers one of those cases. I think that is a stronger argument for keeping char than align. Another argument for align is that CSS alone can't do anything useful about alignment in columns, since inheritance only works through the element tree. Of course, I'd prefer to see that fixed in CSS. ~fantasai
Re: [whatwg] Table integrity and conformance
On Nov 10, 2006, at 02:12, fantasai wrote: Henri Sivonen wrote: On Oct 27, 2006, at 16:21, Anne van Kesteren wrote: On Fri, 27 Oct 2006 15:17:16 +0200, Lachlan Hunt [EMAIL PROTECTED] wrote: That's fine for document conformance, but what about how browsers will handle it? Is the spec still going to require browsers to render overlapping cells, or would it be possible to resolve this difference between HTML and XHTML rendering, as documented in CSS 2.1 [1]? http://www.w3.org/mid/[EMAIL PROTECTED] [1] http://www.w3.org/TR/CSS21/tables.html#q7 WHOA! How on earth did that end up in a CSS WG draft in general and in the CSS 2.1 draft in particular? Easy: it didn't get removed. http://www.w3.org/TR/CSS2/tables.html#q7 I hope that the CSS WG accepts Anne's objection and defines rendering in a browser-compatible way. For the table integrity checker I implemented what browsers do: A cell slides to the right until there's a free slot for its top left corner. If the cell spans multiple columns and overlaps with a cell still in effect from an earlier row, it is an error, but doesn't cause the cell to move further to the right. Since browsers interoperate, I think it would be a bad idea to change this behavior. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] Table integrity and conformance
On Oct 23, 2006, at 21:31, Ian Hickson wrote: I think it would be good to require table integrity. Specifically I think overlapping cells would be a MUST NOT. Made it an error. I don't think there's a problem with missing table cells at the end of rows (i.e. a ragged table is fine). Made it a warning if the width wasn't established by cols/colgroups. I think cells extending (via colspan/rowspan) into columns or rows that contain no cells other than extended cells should be at least a SHOULD NOT, maybe a MUST NOT. Made it an error to have a row or column that doesn't have at least one cell beginning in it. I don't know whether we'll keep the requirement that TFOOTs be above TBODYs. COLGROUP span= will be illegal if the COLGROUP has COLs. Those are easy to handle in RELAX NG. To make the table integrity checker applicable to HTML 4.01, the COLGROUP span= thing is only a warning, but the schema layer makes it an error for (X)HTML5. Do you mean moving all TFOOTs after TBODYs, so that the HTML 4.01 placement would be forbidden? Currently, the RELAX NG-enforced content model for TABLE is ( caption.elem? , ( colgroup.elem+ | col.elem+)? , ( ( thead.elem?, tfoot.elem?, tbody.elem+ ) | ( tr.elem+ ) ) ) The table integrity checker itself doesn't care if colgroups and cols appear side-by-side, if row groups don't have any rows, what the order of thead/tfoot/tbody is or if explicit and implicit row groups are mixed. (Moreover, the table integrity checker only sees a projection of the document tree that contains nothing but table-significant elements and crazy subtrees of table-significant elements in wrong places are silently pruned, so the checker needs a sane schema to keep random stuff out of places where it would bother browsers.) COLs and COLGROUPs will probably have a SHOULD NOT requirement about spanning into columns with no actual cells. Made it an error. Also made it an error to have rows that exceed the width established by column markup. And the SHOULD NOTs will probably be MUST NOTs. I only have errors and warnings. If it makes the doc non-conforming, it is an error. If it doesn't make the doc non-conforming but the author may still be shooting him/herself in the foot, it is a warning. headers= will have a MUST requirement to point to TH elements in the same table, Made it an error if the headers attribute doesn't point to TH elements in the same table. and will probably only be allowed on TDs. Adjusted in RELAX NG. scope= will probably only be allowed for THs. Adjusted in RELAX NG. Maybe it should be REQUIRED for THs that aren't in obvious locations (first row, first column, or whatever). Didn't do anything about this, yet. I think more discussion is needed. And more precision if this idea still stands after discussion. It might be interesting to have some sort of testing with the axis attribute too, or maybe we should drop it. (Indeed maybe we should drop some of the others, too.) Didn't do anything about this. Specifically, the errors are: * Table cell is overlapped by later table cell. * Table cell overlaps an earlier table cell. (Single overlap gets reported in both directions to show source location for both cells.) * Table cell spans past the end of its row group. * Row has no cells starting on it. * Table row column count is greater than the column count established by cols/colgroups. * Table row column count is less than the column count established by cols/colgroups. * The headers attribute doesn't point to th elements in the same table. * Column has no cells starting on it. (Contiguous cell ranges established by a single element are coalesced to a single error to protect against denial of service attacks.) The warnings are: * colspan exceeds 1000, which is a magic number in Gecko (and according to comments in Gecko source, in IE and Opera, too) * rowspan exceeds 8190, which is a magic number in Gecko * Table row column count is greater than the column count established by the first row in the absence of cols/colgroups. * Table row column count is less than the column count established by the first row in the absence of cols/colgroups. * A col element causes a span attribute to be ignored on the parent colgroup. Not deployed yet. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] Table integrity and conformance
Henri Sivonen wrote: I don't have strong feelings about whether tfoot should be allowed before, after or either before or after tbodys. I'd allow before because it's conforming in HTML4 and it works and I'd allow after because it's quite commonly done that way anyway, and I can't think of any good reason to disallow either. ( thead.elem?, tfoot.elem? tbody.elem+ ) That doesn't look right to me. I think you meant this: ( thead.elem?, ( ( tfoot.elem?, tbody.elem+ ) | ( tbody.elem+, tfoot.elem? ) ) ) That's what I had first, but then I thought it could be condensed to the other one. Since (a b) is equivalent to (a, b)|(b, a), aren't both of those equivalent as well? -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Table integrity and conformance
On Nov 9, 2006, at 16:07, Lachlan Hunt wrote: Since (a b) is equivalent to (a, b)|(b, a), aren't both of those equivalent as well? That's one of the limitations of DTDs. :-) In RELAX NG means a real interleave, so the above equivalence holds if a and b are terminals but doesn't hold if a and b are non- terminals that expand with + or *. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] Table integrity and conformance
On Thu, 09 Nov 2006 17:18:46 +0600, Henri Sivonen [EMAIL PROTECTED] wrote: Do you mean moving all TFOOTs after TBODYs, so that the HTML 4.01 placement would be forbidden? TFOOT should be allowed before TBODY because it helps progessive rendering on paged media. I'm not sure if it should be allowed after TBODY as well -- the renderer cannot finish layout of the first page until it knows whether or not there is a TFOOT at the end. Maybe it should be REQUIRED for THs that aren't in obvious locations (first row, first column, or whatever). Didn't do anything about this, yet. I think more discussion is needed. And more precision if this idea still stands after discussion. TH in the middle of a table is OK. There can be various subtitles inside the table. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Table integrity and conformance
On Oct 23, 2006, at 21:31, Ian Hickson wrote: I think cells extending (via colspan/rowspan) into columns or rows that contain no cells other than extended cells should be at least a SHOULD NOT, maybe a MUST NOT. Wouldn't it be sufficient and more desirable to require each row to have at least one cell that starts on that row and each column to have at least one cell that starts in that column? (By starts I mean having the top left corner there.) This would allow tables like this: 112 344 and 12 13 43 (Where numbers denote cells so that 11 means a cell spanning two columns.) Browsers don't choke: http://hsivonen.iki.fi/test/wa10/tables/extended-cells.html -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] Table integrity and conformance
On Wed, 8 Nov 2006, Henri Sivonen wrote: On Oct 23, 2006, at 21:31, Ian Hickson wrote: I think cells extending (via colspan/rowspan) into columns or rows that contain no cells other than extended cells should be at least a SHOULD NOT, maybe a MUST NOT. Wouldn't it be sufficient and more desirable to require each row to have at least one cell that starts on that row and each column to have at least one cell that starts in that column? (By starts I mean having the top left corner there.) This would allow tables like this: 112 344 and 12 13 43 (Where numbers denote cells so that 11 means a cell spanning two columns.) What's the difference? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Table integrity and conformance
On Nov 8, 2006, at 02:59, Ian Hickson wrote: On Wed, 8 Nov 2006, Henri Sivonen wrote: On Oct 23, 2006, at 21:31, Ian Hickson wrote: I think cells extending (via colspan/rowspan) into columns or rows that contain no cells other than extended cells should be at least a SHOULD NOT, maybe a MUST NOT. Wouldn't it be sufficient and more desirable to require each row to have at least one cell that starts on that row and each column to have at least one cell that starts in that column? (By starts I mean having the top left corner there.) This would allow tables like this: 112 344 and 12 13 43 (Where numbers denote cells so that 11 means a cell spanning two columns.) What's the difference? Your formulation seemed to require at least one non-extended (i.e. colspan=1 rowspan=1) cell on each row and column, unless by extending into you didn't mean the row/column on which the cell starts. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] Table integrity and conformance
On Sat, 28 Oct 2006 04:43:10 +0200, Michel Fortin [EMAIL PROTECTED] wrote: * align I don't agree. Yes it is presentational, but data tables can look pretty crappy if you remove their alignement information. Delegating alignment to CSS will just make tables harder to read without the corresponding stylesheet to align the data as intended. That's not just style, it's also a usability issue. So I think align= should be preserved for table cells, rows and columns. It's known that styling and good design improves usability. That doesn't make align any less presentational. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Table integrity and conformance
Dear all,even i think that overlapping cells should not be supported, as it would be an encouragement to table based layouts. The specifications not supporting overlapping cells would encourage developers to use table for tabular data only.
-- {Ro}h(a)[n]_-_[P]{rab}(h)u
Re: [whatwg] Table integrity and conformance
Ian Hickson wrote: I think it would be good to require table integrity. Specifically I think overlapping cells would be a MUST NOT. That's fine for document conformance, but what about how browsers will handle it? Is the spec still going to require browsers to render overlapping cells, or would it be possible to resolve this difference between HTML and XHTML rendering, as documented in CSS 2.1 [1]? Do you have any statistics on the number of sites that depend on overlapping cells in HTML? Could that rendering be removed from standards mode (but left in quirks mode) without breaking a significant number of pages? I think the spec should define an algorithm to unambiguously determine which rows and columns a cell fits into. If browsers can calculate that, there are 2 benefits I can think of. 1. It would make it easier to implement a :column() pseudo-class (as discussed on www-style a few months ago) which would select a cell based on it's semantic position. 2. Assistive technology can more accurately determine the header cells, especially in non-conforming tables. (This algorithm should also be well defined, see below) I don't think there's a problem with missing table cells at the end of rows i.e. a ragged table is fine). Agreed. I think cells extending (via colspan/rowspan) into columns or rows that contain no cells other than extended cells should be at least a SHOULD NOT, maybe a MUST NOT. I don't think it should be a must not. Here's a use case for where it's useful to span cells across multiple columns like that. Consider a online TV guide where columns represent the time and rows represent the channel. The headers for the times could be split into half hour time slots, because most shows take up units of half an hours. However, there are some programs that only take 5 or 10 minutes (e.g. lottery draws or short news breaks) and to allocate such programs a full half hour slot in the table wouldn't be very useful. Consider this markup demonstrating this: http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%0A%3Chtml%3E%0A%3Chead%3E%0A%3Cmeta%20http-equiv%3D%22Content-Type%22%20content%3D%22text/html%3B%20charset%3Dutf-8%22%3E%0A%3Ctitle%3ETable%20Cells%3C/title%3E%0A%3Cstyle%3E%0A%09col%20%7B%20width%3A%205em%3B%20%7D%0A%09table%2C%20td%2C%20th%20%7B%20border%3A%201px%20solid%20black%3B%20border-collapse%3A%20collapse%3B%20%7D%0A%3C/style%3E%0A%3C/head%3E%0A%3Cbody%3E%0A%0A%3Ctable%3E%0A%09%3Ccol%3E%0A%09%3Ccol%3E%0A%09%3Ccol%3E%0A%09%3Ccol%3E%0A%09%3Ccol%3E%0A%09%3Ccol%3E%0A%09%3Ccol%3E%0A%09%3Ccol%3E%0A%09%3Ccol%3E%0A%09%3Ccol%3E%0A%09%3Ccol%3E%0A%09%3Ccol%3E%0A%3Cthead%3E%0A%09%3Ctr%3E%0A%09%09%3Cth%3E%3C/th%3E%0A%09%09%3Cth%20colspan%3D%226%22%3E20%3A00%3C/th%3E%0A%09%09%3Cth%20colspan%3D%226%22%3E20%3A30%3C/th%3E%0A%09%3C/tr%3E%0A%3C/thead%3E%0A%3Ctbody%3E%0A%09%3Ctr%3E%0A%09%09%3Cth%20scope%3D%22row%22%3EChannel%201%3C/th%3E%0A%09%09%3Ctd%20colspan%3D%225%22%3E20%3A00%20-%2025%20minute%20progr am%3C/td%3E%0A%09%09%3Ctd%20colspan%3D%221%22%3E20%3A25%20-%205%20minute%20program%3C/td%3E%0A%09%09%3Ctd%20colspan%3D%226%22%3E20%3A30%20-%2030%20minute%20program%3C/td%3E%0A%09%3C/tr%3E%0A%09%3Ctr%3E%0A%09%09%3Cth%20scope%3D%22row%22%3EChannel%202%3C/th%3E%0A%09%09%3Ctd%20colspan%3D%226%22%3E20%3A00%20-%2030%20minute%20program%3C/td%3E%0A%09%09%3Ctd%20colspan%3D%226%22%3E20%3A30%20-%2030%20minute%20program%3C/td%3E%0A%09%3C/tr%3E%0A%09%3Ctr%3E%0A%09%09%3Cth%20scope%3D%22row%22%3EChannel%203%3C/th%3E%0A%09%09%3Ctd%20colspan%3D%2210%22%3E20%3A00%20-%2050%20minute%20program%3C/td%3E%0A%09%09%3Ctd%20colspan%3D%222%22%3E20%3A50%20-%2010%20minute%20program%3C/td%3E%0A%09%3C/tr%3E%0A%3C/tbody%3E%0A%3C/table%3E%0A%0A%3C/body%3E%0A%3C/html%3E%0A I don't know whether we'll keep the requirement that TFOOTs be above TBODYs. I agree. I think that requirement is silly, and most people who I've seen use tfoot inevitably put it at the end of the table. It can also be more convenient in a generated table, where a server side script is calculating something from the contents of each row in tbody (e.g. a total) and then outputting that total in the tfoot. COLGROUP span= will be illegal if the COLGROUP has COLs. COLs and COLGROUPs will probably have a SHOULD NOT requirement about spanning into columns with no actual cells. Agreed. headers= will have a MUST requirement to point to TH elements in the same table, and will probably only be allowed on TDs. Maybe. What about in tables where one th is like a subheading of the one above? scope= will probably only be allowed for THs. Maybe it should be REQUIRED for THs that aren't in obvious locations (first row, first column, or whatever). Maybe. I think the spec should explicitly define how to determine which header cells are associated with each cell. IIRC, the HTML 4 spec does define an algorithm like that, so maybe it could be improved. It might be interesting to have
Re: [whatwg] Table integrity and conformance
On Fri, 27 Oct 2006 15:17:16 +0200, Lachlan Hunt [EMAIL PROTECTED] wrote: That's fine for document conformance, but what about how browsers will handle it? Is the spec still going to require browsers to render overlapping cells, or would it be possible to resolve this difference between HTML and XHTML rendering, as documented in CSS 2.1 [1]? http://www.w3.org/mid/[EMAIL PROTECTED] [1] http://www.w3.org/TR/CSS21/tables.html#q7 -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Table integrity and conformance
On Oct 27, 2006, at 16:21, Anne van Kesteren wrote: On Fri, 27 Oct 2006 15:17:16 +0200, Lachlan Hunt [EMAIL PROTECTED] wrote: That's fine for document conformance, but what about how browsers will handle it? Is the spec still going to require browsers to render overlapping cells, or would it be possible to resolve this difference between HTML and XHTML rendering, as documented in CSS 2.1 [1]? http://www.w3.org/mid/[EMAIL PROTECTED] [1] http://www.w3.org/TR/CSS21/tables.html#q7 WHOA! How on earth did that end up in a CSS WG draft in general and in the CSS 2.1 draft in particular? -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] Table integrity and conformance
Hi, From: Ian Hickson [EMAIL PROTECTED] headers= will have a MUST requirement to point to TH elements in the same table, and will probably only be allowed on TDs. scope= will probably only be allowed for THs. In HTML4, as I understand it, TDs can act as both data cells and header cells if they have scope= or have headers= pointing at them. Regards, Simon Pieters _ Sök bilder på glammiga kändisar! http://search.msn.se
Re: [whatwg] Table integrity and conformance
On Oct 23, 2006, at 21:31, Ian Hickson wrote: I think it would be good to require table integrity. Specifically I think overlapping cells would be a MUST NOT. Excellent! Thanks! It might be interesting to have some sort of testing with the axis attribute too, or maybe we should drop it. I think it should be dropped due to lack of implementations and use after being in HTML 4 for years. If you do do this, I expect your experience with writing the conformance checker will be a large influence on what the spec end up saying. Hopefully I can come up with something useful. On a related note, a potentially interesting feature of a conformance checker would be to output the document outline so that a human can check that that is correct. Noted as a feature request for the future. :-) -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] Table integrity and conformance
On Oct 26, 2006, at 9:27 AM, Henri Sivonen wrote: It might be interesting to have some sort of testing with the axis attribute too, or maybe we should drop it. I think it should be dropped due to lack of implementations and use after being in HTML 4 for years. It strikes me that the axis and headers attributes could both potentially be very useful; but if I were to use them, I'd almost certainly generate the table and attributes with server-side script (such as PHP), and then there would be no need for the HTML attributes since I could generate any desired reports the same way. They seem to me to provide alternative functionality for tables in lieu of an actual database, but if the tables aren't generated from a database they'd have to be marked up by hand, and that would be a tremendous amount of work in which errors could easily be introduced. That may explain why the attributes are underused. Is the headers attribute any more widely used than axis? I admit I've never used either, but I don't typically generate complex data tables. David Walbert LEARN NC [EMAIL PROTECTED]
Re: [whatwg] Table integrity and conformance
On Aug 29, 2006, at 10:44, Henri Sivonen wrote: Should one expect HTML table row/column integrity to become an HTML5 conformance requirement? My plan is to spend November prototyping conformance checker parts that don't belong in the parser, don't belong in schemas (RELAX NG or Schematron 1.5) and don't belong in a RELAX NG datatype library. That is, I intend to implement a couple of such features and figure out which such features need to be implemented later. (Stuff specified in the parsing section belongs in the parser. Element nesting and attribute occurrence that is nicely expressible as a grammar belongs in RELAX NG. Assertions that can be tested with IDness-unaware XPath belong in Schematron. The format of the values of individual attributes belongs in a datatype library. I'm talking about checking conformance requirements that aren't covered by any of those.) I think table integrity checking would be sufficiently complex to work as a technical proof of concept and useful enough compared to SGML-based validators to work as a nice demo. However, it doesn't make sense to work on it as part of a conformance checker if table integrity won't be a conformance requirement. I'd appreciate some indication on what I should expect in this area, i.e. whether it makes sense to prototype a table integrity checker based on HTML 4 forms. I am also open to suggestions on what non-schema checks to prioritize in prototyping if it turns out that it is too early to work on tables. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] Table integrity and conformance
On Mon, 23 Oct 2006, Henri Sivonen wrote: Should one expect HTML table row/column integrity to become an HTML5 conformance requirement? I'd appreciate some indication on what I should expect in this area, i.e. whether it makes sense to prototype a table integrity checker based on HTML 4 forms. I'm not planning on actually speccing tables for a while (but maybe I'll get to it by the end of the year), which is why I haven't replied to your last e-mail yet. I think it would be good to require table integrity. Specifically I think overlapping cells would be a MUST NOT. I don't think there's a problem with missing table cells at the end of rows (i.e. a ragged table is fine). I think cells extending (via colspan/rowspan) into columns or rows that contain no cells other than extended cells should be at least a SHOULD NOT, maybe a MUST NOT. I don't know whether we'll keep the requirement that TFOOTs be above TBODYs. COLGROUP span= will be illegal if the COLGROUP has COLs. COLs and COLGROUPs will probably have a SHOULD NOT requirement about spanning into columns with no actual cells. And the SHOULD NOTs will probably be MUST NOTs. headers= will have a MUST requirement to point to TH elements in the same table, and will probably only be allowed on TDs. scope= will probably only be allowed for THs. Maybe it should be REQUIRED for THs that aren't in obvious locations (first row, first column, or whatever). It might be interesting to have some sort of testing with the axis attribute too, or maybe we should drop it. (Indeed maybe we should drop some of the others, too.) If you do do this, I expect your experience with writing the conformance checker will be a large influence on what the spec end up saying. On a related note, a potentially interesting feature of a conformance checker would be to output the document outline so that a human can check that that is correct. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Table integrity and conformance
Should one expect HTML table row/column integrity to become an HTML5 conformance requirement? That is, will these tables be non-conforming: table trtd rowspan=2/td/tr /table table trtd/td/tr trtd/tdtd/td/tr /table ? (This is something static document authors probably would prefer to have flagged, and for dynamic document authors it isn't a particularly good idea to leave the DOM in an incoherent state for prolonged times.) -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
