- From: Aryeh Gregor <Simetrical+w3c@gmail.com>
- Date: Fri, 25 Mar 2011 12:57:32 -0400
- To: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Cc: Sam Ruby <rubys@intertwingly.net>, HTML WG <public-html@w3.org>
On Wed, Mar 23, 2011 at 8:22 PM, Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> wrote: > UPDATE: It turns out that HTML5 requires UAs to treat @border as a > boolean: > > When present @border causes an 1px border. [1] Except some bugs, this > rule is well supported. For example, old and new versions of GUI > browsers like Konqueror, Firefox, Opera, Webkit and IE, as well as text > browsers like Links and w3m, all support it as a bolean. > > Thus, despite its current invalidity, @border is actually defined to > work pretty much the same way my CP suggest. > > In light of this, I plan - within a few days - to update the CP to say > that HTML5 should define @border as a boolean. You missed the prose underneath: """ 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. """ http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#punctuation-and-decorations This test-case indicates very clearly that at least in Gecko, WebKit, and Presto, border is not treated as a boolean: data:text/html,<!doctype html><table border=17><td>Hi</td></table>
Received on Friday, 25 March 2011 16:58:25 UTC