Bug 56982 – table{border:value} causes cell borders to disappear on <table border=value>

• Component: CSS
• Status: RESOLVED CONFIGURATION CHANGED

[Leif Halvard Silli]

* HTML5 says that the presence of @border attribute on a table element, should lead to 1px wide borders for all cells in the table.
   http://dev.w3.org/html5/spec/rendering.html#decohints
   (See bottom of the code examples of this section.)

* Thus, according to HTML5, @border, when used inside <table>, in practise is a boolean attribute.

   And, apart from the bug(s) documented in this very bug, this is what Webkit does too.

   The bug, though, is this: if the author adds a border on the parent element - that is: on the <table> element, then the borders aroun the cells disappear.
   The same does not happen in IE, Opera, Firefox.

Example 1: Here there is a border around all cells in all Web browsers:
     <table border="1"><tr><td>...<td>...</tr></table>

Example 2: Here there is a border around all cells in "all" Web browsers - EXCEPT in Webkit
      <style>table{border:1px solid blue}
     <table border="1"><tr><td>...<td>...</tr></table>

Example3: This example is like Ex 2, except that it uses inline CSS - then the borders do not disappear.
     <table style="border:1px solid" border="1"><tr><td>...</tr></table>

Example 4:  When the value of border = "0", what then? Well, according to HTML5, there should be a 1px wide border still. And at any rate, it should be possible to undoo the styling caused by the @border. However, <table border=0> have similar bugs as documented in Example 2 and 3.

[Leif Halvard Silli]

Replaced old test (http://software.hixie.ch/utilities/js/live-dom-viewer/saved/888) with one that perhaps is clearer: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/892

[David Barr]

Confirmed in WebKit Nightly Version 5.1.5 (6534.55.3, r115022).

Relevant text quoted from: http://dev.w3.org/html5/spec/rendering.html#decohints

The table element's border attribute maps to the pixel length properties 'border-top-width', 'border-right-width', 'border-bottom-width', 'border-left-width' on the element. If the attribute is present but parsing the attribute's value using the rules for parsing non-negative integers generates an error, a default value of 1px is expected to be used for that property instead.

[Daniel Bates]

*** This bug has been marked as a duplicate of bug 102112 ***

[Daniel Bates]

(In reply to comment #3)
> 
> *** This bug has been marked as a duplicate of bug 102112 ***

Actually, this bug isn't a duplicate of bug #102112. As of shipping Safari Version 7.0.3 (9537.75.14), example 1, 2 (*), and 3 appear to be fixed. From my understanding of the HTML5 standard (as of the time of writing), as quoted by David Barr in comment #2, the border width should be 0 in example 4 since 0 is a non-negative integer. I'm re-opening this bug so that we can land layout tests to ensure we don't regress the issues mentioned in this bug.

(*) Assuming we add a </style> before the <table>.

[Brent Fulgham]

Safari, Chrome, and Firefox all agree on rendering for this test case. I don't believe there is any remaining compatibility issue.