56982 2011-03-23 18:04:45 -0700 table{border:value} causes cell borders to disappear on <table border=value> 2022-07-12 14:30:28 -0700 1 1 1 Unclassified WebKit CSS 528+ (Nightly build) All All RESOLVED CONFIGURATION CHANGED http://software.hixie.ch/utilities/js/live-dom-viewer/saved/892 P2 Normal --- 1 xn--mlform-iua webkit-unassigned bfulgham davidbarr dbates eric.carlson oldest_to_newest 372586 0 xn--mlform-iua 2011-03-23 18:04:45 -0700 * 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. 373725 1 xn--mlform-iua 2011-03-25 14:27:43 -0700 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 610346 2 davidbarr 2012-04-25 21:58:00 -0700 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. 1001425 3 dbates 2014-04-16 17:27:48 -0700 *** This bug has been marked as a duplicate of bug 102112 *** 1001432 4 dbates 2014-04-16 17:49:07 -0700 (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>. 1882588 5 bfulgham 2022-07-12 14:30:28 -0700 Safari, Chrome, and Firefox all agree on rendering for this test case. I don't believe there is any remaining compatibility issue.