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

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24559

--- 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
added.</small>

>> 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