Bug 56982 - table{border:value} causes cell borders to disappear on <table border=value>
Summary: table{border:value} causes cell borders to disappear on <table border=value>
Alias: None
Product: WebKit
Classification: Unclassified
Component: CSS (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL: http://software.hixie.ch/utilities/js...
Depends on:
Reported: 2011-03-23 18:04 PDT by Leif Halvard Silli
Modified: 2022-07-12 14:30 PDT (History)
4 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Leif Halvard Silli 2011-03-23 18:04:45 PDT
* HTML5 says that the presence of @border attribute on a table element, should lead to 1px wide borders for all cells in the table.
   (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.
Comment 1 Leif Halvard Silli 2011-03-25 14:27:43 PDT
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
Comment 2 David Barr 2012-04-25 21:58:00 PDT
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.
Comment 3 Daniel Bates 2014-04-16 17:27:48 PDT

*** This bug has been marked as a duplicate of bug 102112 ***
Comment 4 Daniel Bates 2014-04-16 17:49:07 PDT
(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>.
Comment 5 Brent Fulgham 2022-07-12 14:30:28 PDT
Safari, Chrome, and Firefox all agree on rendering for this test case. I don't believe there is any remaining compatibility issue.