* 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.
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
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.
*** This bug has been marked as a duplicate of bug 102112 ***
(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>.
Safari, Chrome, and Firefox all agree on rendering for this test case. I don't believe there is any remaining compatibility issue.