13915 – The suggested presentation differs from the common (if not universal) browser behavior for a table when no attributes and no author style sheets are used. The common default is to render the table with no borders. However, the CSS rules described here imp

This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 13915 - The suggested presentation differs from the common (if not universal) browser behavior for a table when no attributes and no author style sheets are used. The common default is to render the table with no borders. However, the CSS rules described here imp

Summary: The suggested presentation differs from the common (if not universal) browser...

Status:	RESOLVED FIXED

Alias:	None

Product:	HTML WG
Classification:	Unclassified
Component:	HTML5 spec (show other bugs)
Version:	unspecified
Hardware:	Other other

Importance:	P3 normal
Target Milestone:	---
Assignee:	Ian 'Hixie' Hickson
QA Contact:	HTML WG Bugzilla archive list

URL:	http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:

Depends on:
Blocks:

Reported:	2011-08-26 07:05 UTC by contributor
Modified:	2011-10-24 23:20 UTC (History)
CC List:	6 users (show)

See Also:

Attachments

Description contributor 2011-08-26 07:05:25 UTC

Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html
Multipage: http://www.whatwg.org/C#tables
Complete: http://www.whatwg.org/c#tables

Comment:
The suggested presentation differs from the common (if not universal) browser
behavior for a table when no attributes and no author style sheets are used.
The common default is to render the table with no borders. However, the CSS
rules described here imply a default of outset border, and as the border-width
is not set here in that case, it defaults to medium by CSS specs. Demo page:
http://www.cs.tut.fi/~jkorpela/html5/test-default.html

Posted from: 88.114.31.151
User agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0) Gecko/20100101 Firefox/6.0

Comment 1 Ian 'Hixie' Hickson 2011-10-12 19:23:51 UTC

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Accepted
Change Description: see diff given below
Rationale: Concurred with reporter's comments.

Comment 2 contributor 2011-10-12 19:25:48 UTC

Checked in as WHATWG revision r6672.
Check-in comment: Tables don't have a border by default, so we need to set the default border width to zero.
http://html5.org/tools/web-apps-tracker?from=6671&to=6672

Comment 3 L. David Baron (Mozilla) 2011-10-12 20:33:44 UTC

That solution to this issue is not compatible with implementations -- implementations default to tables having neither a border-width style (the initial value is 'medium') nor a border-style style (the initial value is 'none').  Using presentational attributes on the table can set these properties.

In particular, Gecko, WebKit, and Opera interoperate on this test:
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Ctable%3E%3Ctr%3E%3Ctd%3Eno%20style%3C%2Ftable%3E%0A%3Ctable%20style%3D%22border-width%3A%203px%22%3E%3Ctr%3E%3Ctd%3Eborder-width%3A3px%3C%2Ftable%3E%0A%3Ctable%20style%3D%22border-style%3A%20solid%22%3E%3Ctr%3E%3Ctd%3Eborder-style%3Asolid%3C%2Ftable%3E%0A
which shows that what keeps table borders hidden initially is the border-style being none, not the border-width being zero (just like for pretty much everything else that doesn't have a border by default).

Comment 4 Ian 'Hixie' Hickson 2011-10-12 21:55:26 UTC

Ah, indeed. So the right solution is just to remove the border-width _and_ the border-style on the default table rule, and move the border-style rule to table[border]?

Comment 5 L. David Baron (Mozilla) 2011-10-12 23:01:48 UTC

That would certainly be an improvement.  It even appears to be correct for border="0", based on http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Ctable%20border%3D%220%22%3E%3Ctr%3E%3Ctd%3Eno%20style%3C%2Ftable%3E%0A%3Ctable%20border%3D%220%22%20style%3D%22border-width%3A%203px%22%3E%3Ctr%3E%3Ctd%3Eborder-width%3A3px%3C%2Ftable%3E%0A%3Ctable%20border%3D%220%22%20style%3D%22border-style%3A%20solid%22%3E%3Ctr%3E%3Ctd%3Eborder-style%3Asolid%3C%2Ftable%3E%0A%3Ctable%20border%3D%220%22%20style%3D%22border-style%3A%20solid%3B%20border-width%3A%203px%22%3E%3Ctr%3E%3Ctd%3Eborder-style%3Asolid%3C%2Ftable%3E%0A in Gecko and WebKit.

It's hard to say off the top of my head whether it's right.  This stuff is pretty complicated given the multiple presentational attributes (border, frame, rules) that have effects on tables, cells, and the elements in between -- and it's actually sort of hard to write CSS rules that get the cascading correct so as to get the interactions of those different presentational attributes correct.

Gecko actually does implement almost all of this in terms of CSS (rather than C++ code like we used to) -- though the mapping of the border attribute to border-*-width on the table is in C++ (and you describe it in prose), and I needed to sneak in a :-moz-table-border-nonzero selector to handle things like border="0bar".

So http://mxr.mozilla.org/mozilla-central/source/layout/style/html.css#257 may be informative here.

Comment 6 L. David Baron (Mozilla) 2011-10-12 23:04:56 UTC

(In reply to comment #5)
> So http://mxr.mozilla.org/mozilla-central/source/layout/style/html.css#257 may
> be informative here.

(And I think it's worth noting that a substantial amount of effort went in to writing those rules -- the specificity and order is often important.)

Comment 7 Ian 'Hixie' Hickson 2011-10-14 00:37:54 UTC

Lots of effort went (and is still going!) into the spec's rules too. :-)

I don't understand several things about the Gecko rules:

- line 305: why do you reset border-color for table[frame] but not table[rules] ? (I guess it doesn't matter since it's the default anyway.)

- line 288: why do you set the border-width for table[rules] ? It seems to disagree with IE, WebKit, and Opera: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1191

- line 336: why do you not do 'border-collapse:collapse' for rules=none? All other browsers seem to: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1196

- :-moz-table-border-nonzero: why do you treat border=0 differently than border=1, other than for the width being mapped to 0 rather than 1? This seems to only be done by Opera and Gecko, and Opera's behaviour is buggy in other ways so I'm not sure it really counts: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1197

- why are there rules for cells that are children of tables? I haven't put these in the spec for now.

- line 340: why do you override the border-width for cells if rules="" is present even if it's not a valid value? IE does not. Opera mostly does not; it's a bit buggy. Chrome does for valid values, but also has a weird but where it sets it to zero by default so I'm not sure what to make of it: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1199 (I've gone with Gecko's behaviour here except only for valid values.)

- lines 342 and 354: the rules whose selector starts with "table[rules][rules="none"]" are redundant with those that start "table[rules]:not([rules=""])". Am I missing a reason why both need to be given?

Other notes:

- I couldn't get any interop on http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1192 which tests whether table[rules] should get border-style:hidden. IE doesn't have it at all (they leave the default 'none'), Opera uses 'hidden' but only does it for valid values of rules="", WebKit does 'none' but seems to default the width to 0 except on valid values, and Gecko uses 'hidden' on presence of rules="". (I've done it but only for valid values.)

- Different browsers seem to have different ideas of which borders should be given an explicit width in various rules="" states. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1200 http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1201 http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1202 (I've set the value on cells for all valid values of rules, and on the borders that get an explicit style in the cases where rules="" styles non-cells.)


I've attempted to fix the spec's rules to be more like Gecko except where Gecko's rules are not compatible with anyone else. I would appreciate your review.

Comment 8 contributor 2011-10-14 00:39:08 UTC

Checked in as WHATWG revision r6681.
Check-in comment: Try to improve compat for legacy <table border='' rules='' and frames=''> attributes.
http://html5.org/tools/web-apps-tracker?from=6680&to=6681

Comment 9 L. David Baron (Mozilla) 2011-10-14 01:01:37 UTC

I asked fantasai to look at these comments in a bit more detail.  However, to respond to just one of them:

(In reply to comment #7)
> - :-moz-table-border-nonzero: why do you treat border=0 differently than
> border=1, other than for the width being mapped to 0 rather than 1? This seems
> to only be done by Opera and Gecko, and Opera's behaviour is buggy in other
> ways so I'm not sure it really counts:
> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1197

There are two uses of :-moz-table-border-nonzero, and I believe both of them are required for interop as shown in this page:
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Ctable%20style%3D%22border-style%3Asolid%22%3E%3Ctr%3E%3Ctd%3Eborder-style%3Asolid%3C%2Ftable%3E%0A%3Ctable%20border%3D%220%22%20style%3D%22border-style%3Asolid%22%3E%3Ctr%3E%3Ctd%3Eborder%3D%220%22%20border-style%3Asolid%3C%2Ftable%3E%0A%3Ctable%20border%3D%225%22%20style%3D%22border-style%3Asolid%22%3E%3Ctr%3E%3Ctd%3Eborder%3D%225%22%20border-style%3Asolid%3C%2Ftable%3E%0A%3Ctable%20style%3D%22border-width%3A5px%22%3E%3Ctr%3E%3Ctd%3Eborder-width%3A5px%3C%2Ftable%3E%0A%3Ctable%20border%3D%220%22%20style%3D%22border-width%3A5px%22%3E%3Ctr%3E%3Ctd%3Eborder%3D%220%22%20border-width%3A5px%3C%2Ftable%3E%0A%3Ctable%20border%3D%225%22%20style%3D%22border-width%3A5px%22%3E%3Ctr%3E%3Ctd%3Eborder%3D%225%22%20border-width%3A5px%3C%2Ftable%3E

The first use sets border-style:outset on the table only when :-moz-table-border-nonzero.  If this rule applied whenever the border attribute was present, the fifth of the six tables would have a visible border (which it does not in Gecko or WebKit).  (There's also a border-width:thin in that rule that's (a) always overridden and thus pointless.)

The second use is what sets the borders on the cells.  Making border="0" lead to cell borders would be an extremely obvious Web compatibility regression; using simply [border] in those cases would cause cell borders in the second and fifth of the six tables and on countless tables all over the Web that don't expect cell borders.  (All nonzero values of the border attribute apply the given number to the table border and lead to 1 pixel cell borders.)

Comment 10 Ian 'Hixie' Hickson 2011-10-14 18:49:46 UTC

Hm, yes. The spec handles the second case already, but for the first case, I need to make sure border-style remains 'none' otherwise the first table here would get table and cell borders:

<!DOCTYPE HTML>
<style>table, td { border-width: 10px; }</style>
<table border="0"><tr><td>X</table>
<table border="x"><tr><td>X</table>
<table border="1"><tr><td>X</table>

More prose to add, I guess.

Oddly IE doesn't give a table even for the third table above. Dunno what that's about.

Comment 11 contributor 2011-10-14 19:09:48 UTC

Checked in as WHATWG revision r6684.
Check-in comment: <table border=0> shouldn't set a border-style on the table or the cells
http://html5.org/tools/web-apps-tracker?from=6683&to=6684

Comment 12 Ian 'Hixie' Hickson 2011-10-24 23:20:13 UTC

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Accepted
Change Description: see diff given below
Rationale: As far as I am aware, all outstanding issues have been resolved. Please don't hesitate to reopen the bug if there are outstanding issues.