W3C home > Mailing lists > Public > www-validator-cvs@w3.org > February 2014

[Bug 24559] Nu Markup Checker emits "Use CSS instead" help message for table@border=1

From: <bugzilla@jessica.w3.org>
Date: Thu, 13 Feb 2014 00:18:49 +0000
To: www-validator-cvs@w3.org
Message-ID: <bug-24559-169-eZ4hwXJm6n@http.www.w3.org/Bugs/Public/>

--- Comment #17 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> ---
(In reply to Andrea Rendine from comment #14)

>> after his edits back then.
> Are you saying that it was the WHATWG (i.e. Mr. Hickson) who
> moved back from the adoption of conformity for @border? Or did I
> misunderstand?

Misunderstanding. <small>I don’t know how or when it happened that @border fell
out the list of table attributes. What I do know is that when the HTML WG’s
border decision had been made, the editor (Hixie) had the task of reflecting
the decision in the spec. And he did place @border on the list of permitted
attributes. But I personally was not 100% satisfied with the prose the prose he

>> the current text to say that *only*
>> “certain” UAs use the @border attribute. But fact is that *all*
>> UAs implements it. Is that your question?

> In my
> opinion "some UAs" refers to visual UAs, like desktop and mobile
> browsers and webTVs. All of them interpret @border as it is: in
> absence of CSS it is a fallback value for drawing borders, which are
> not rendered if neither @border nor CSS{border} is defined on the
> table.

So, the prose might be clear enough, then, in that detail.

> And I also think that most of them even parse the value and
> draw borders whose thickness is defined by it.

I have not seen evidence of that. The UAs I tested do make the frame/border
around the very table element thicker - as required by the rendering section of
HTML5. However, the very table elements are not made thicker - which is also
what the rendering section says.

> Of course if a page
> is standard compliant this value can only be 1 or the empty string,
> which means the same.  That was my question indeed. Do browsers
> parse @border value and render accordingly or do they simply say the
> machinian translation of: "Hey, this is <table@border>. I can safely
> ignore the value and draw a 1px border around cells and the whole
> frame."

Yes they do, for the cells. But not for the very table element.

>> Please be more specific about what change, 1 month ago, you refer to.
> The spec as I linked it.

Thanks! As you know, I have now filed a about that detail.

>> @border already acts as a boolean. Except when its value is "0".     
>> And also, while the empty string is conforming - as in a boolean,    
>> the value "border" (border="border"), is not conforming, as one      
>> would expect in a true boolean.                                      
> At this very moment, according to the spec, nothing in @border is
> conforming, not even its presence.

Yep. Hence the bug I mentioned above.

> It's a good point to stop, decide
> to use it in a good way and give it a meaning. Alas, that value 0
> prevents it from being used as a true boolean, because while in
> booleans all values mean the same (true), here the value 0 means
> "no border rendering" thus acting as a "false". But in my head
> canon it should be parsed as a boolean and should BE a boolean too.
> @border="border" could be allowed.

It could be a ”true boolean” to authors, I think. The error default of
border="not-a-number" is that the user agent defaults to border="1". This is
specified in the spec somewhere. (At least it used to be.)

>> to say that @border indicate that it is a data table, may have the
>> side effect of [...] saying that layout tables can be signalled by
>> leaving out the border attribute.

> Which is indeed what the spec does. 
> That's why even after the sentence I quoted above, I'd rather prefer a
> @border rather than a @borderless. A table is a table is a table. The
> default for a table is to be a table, not to have borders. Thus said,
> if borders have a meaning, we add them via a specific attribute. Does
> it work for you "logically"?

I think I can see your point. E.g. it is not so that data tables in text
browsers (like Lynx or W3m) absolutely always ought to have borders.

You are receiving this mail because:
You are the QA Contact for the bug.
Received on Thursday, 13 February 2014 00:18:51 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:17:56 UTC