Bug 56982
Summary: | table{border:value} causes cell borders to disappear on <table border=value> | ||
---|---|---|---|
Product: | WebKit | Reporter: | Leif Halvard Silli <xn--mlform-iua> |
Component: | CSS | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED CONFIGURATION CHANGED | ||
Severity: | Normal | CC: | bfulgham, davidbarr, dbates, eric.carlson |
Priority: | P2 | ||
Version: | 528+ (Nightly build) | ||
Hardware: | All | ||
OS: | All | ||
URL: | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/892 |
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.
Attachments | ||
---|---|---|
Add attachment proposed patch, testcase, etc. |
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.