- From: Greg Whitworth <gwhit@microsoft.com>
- Date: Tue, 8 Mar 2016 04:56:58 +0000
- To: Gérard Talbot <www-style@gtalbot.org>
- CC: Francois Remy <frremy@microsoft.com>, W3C www-style mailing list <www-style@w3.org>
First off, thanks for taking the time to review our frankenspec, we greatly appreciate it. > More than 10 years ago, I wrote that CSS3 modules must (or should?) > specify, must try to resolve all of the instances of "is undefined", "can not > define", "can not be defined", "free to guess", "free to make a guess" > occurences found in CSS2.1. I agree with this, I would really like to avoid this terminology as often as possible as it is almost impossible to achieve interop when these terms are utilized. > Some areas or some sentences of > CSS2.1, section 17 Tables > https://www.w3.org/TR/2011/REC-CSS2-20110607/tables.html > are, in my opinion, difficult or very difficult to understand. > > Tables are over-specified in current specs; therefore, there will be logical > contradictions happening. > And we should try to resolve each contradiction if feasible, we've found a few areas that were stated in one of the three specs as 'musts' and yet no browser actually implemented it this way. For example, we saw this regarding border radius as stated in issue 6: https://drafts.csswg.org/css-tables-3/#issue-e9fed834. At any rate, we'll take this on a case-by-case basis and work together to come up with the best possible solution. > > much as we want to say 2+2=4; the web unfortunately is, at times, > > depending on it equaling 5, and others 6000 (see width and height > > calculation and unit resolution as an example of this). > > Greg, I am not sure I understand what you mean with your "others 6000 (see > width and height calculation and unit resolution as an example of this)" > Sure, I wasn't trying to be extremely specific in these examples, merely to get the point across. But I was specifically thinking about how we found that in width distribution % width units were given priority over specified value columns and the inverse is true in height distribution. Ultimately, I was trying to point out the crazy inconsistencies and letting everyone know to be prepared for illogical logic; of which I'm sure you're more than aware exists :) > In your bug list: > > Table [wrapper!] boxes should be wide enough to contain the caption: > *_this has been already resolved as far as I can say_* > http://www.gtalbot.org/BrowserBugsSection/css21testsuite/horizontal- > layout-table-vs-caption-boxes-1.html > http://www.gtalbot.org/BrowserBugsSection/css21testsuite/caption-100pct- > width-001.xht > http://lists.w3.org/Archives/Public/www-style/2010Sep/0186.html > http://test.csswg.org/suites/css2.1/nightly-unstable/html4/anonymous- > table-box-width-001.htm > https://wiki.csswg.org/spec/css2.1#issue-172 > > When caption is wider than table box (not the table wrapper box): > > Expected: > _____________________________________ > | CAPTION CAPTION CAPTION CAPTION | > ------------------------------------- > | +-----+-----+-----+ | > | | | | | | > | +-----+-----+-----+ | > | | | | | | > | +-----+-----+-----+ | > |___________________________________| > > > Actual in some browsers: > _______________________ > | CAPTION CAPTION CAPTION CAPTION > ----------------------- > | +-----+-----+-----+ | > | | | | | | > | +-----+-----+-----+ | > | | | | | | > | +-----+-----+-----+ | > |_____________________| > > This is great, thanks for sharing this with us we'll review it, I've added this note to the bug notes in the list. > > The spec should answer the tough questions (involving rowspanning cells > and 'border-collapse: collapse') raised by Mitz: > https://bugs.webkit.org/show_bug.cgi?id=8735#c7 We don't plan to shy away from the tough questions, so I've opened an issue on this: https://drafts.csswg.org/css-tables-3/issues-ed-20160202.html > - - - - - > > " > table-row-group (In HTML: TBODY) > Specifies that an element groups one or more rows. > " > 2.1. Table Structure > https://drafts.csswg.org/css-tables-3/#table-structure > > This would have to be changed (and should be changed) into: > > Specifies that an element groups zero or more rows. > > HTML4 said 1 or more. > HTML5 says 0 or more. > > Search for "Chris Rebert" and "empty <tbody>" for this. > > [CSS21][CSS22][css-tables][css3-tables] Table sanity/regression testcase > needs review http://lists.w3.org/Archives/Public/www- > style/2015Jul/0392.html Thanks!! I've added an issue inline for this one so I can just do a quick double check of the specs and then swap it out and opened an issue: https://drafts.csswg.org/css-tables-3/issues-ed-20160202.html > - - - - - - > > > "Value: normal | fixed > Initial: separate " > 3.4.1. The Table-Layout property > https://drafts.csswg.org/css-tables-3/#table-layout-property > > It is now > > "Value: auto | fixed > Initial: auto " > https://www.w3.org/TR/CSS21/tables.html#propdef-table-layout > > so, this must be 2 errors. > Good catch, probably a mistake in the copy and pasting of propdefs, I've fixed it. > > 2.4. Spanning > We should define how spanning works. > https://drafts.csswg.org/css-tables-3/#spanning > > Quick rowspanning test (with minimal code): > http://www.gtalbot.org/BrowserBugsSection/css21testsuite/rowspanning- > cell-challenge-001.html > > Expected result (approximate table layout): > > +-----------+-----------+ > | |C | > |A +-----------+ > | | | > | |D | > +-----------+ | > |B | | > +-----------+-----------+ > > > Actual result (approximate table layout) in many browsers (Firefox 44, Opera > 12.16, IE11) (don't know about Edge14) > > +-----------+-----------+ > | | | > |A |C | > | | | > +-----------------------+ > | | | > |B |D | > | | | > +-----------------------+ > > Whether 'table-layout: fixed' is declared or not makes no difference. > Not sure what you're point is here (sorry if I missed it), besides that we need to define and agree how spanning, and subsequently the width/height calculations should be done in regards to spanning. Again, thanks for the feedback. Greg
Received on Tuesday, 8 March 2016 04:57:30 UTC