[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 #14 from Andrea Rendine <master.skywalker.88@gmail.com> ---
(In reply to Leif Halvard Silli from comment #12)
>Are you referring to even older versions of HTML? Or some in-between version of HTML5.1, were the above passage ”fell out” of the spec?
Just look at the introduction box, it's what states what can, what cannot and
what must be inserted in the element. In the older version, the spec said:
]]Content attributes:
  Global attributes
  border[[
In the current spec @border has disappeared, thus making it not conforming. But
as a matter of fact in the prose it is not stated whether @border is conforming
or not.

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

>I have heard from David Carlisle that he (if I understood him perfectly) interpret 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?
I spent quite some time reading the bug you filed and Mr Carlisle's answer.
Actually he only copypasted a section of W3 spec and stated something relevant
about the concept of polyglot definitions. 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. And I also think that most of them even parse the value and draw borders
whose thickness is defined by it. 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."

>Please be more specific about what change, 1 month ago, you refer to.
The spec as I linked it. With @border accepting only 1 and the empty string as
value. Actually idk when the attribute has been removed, i think quite
recently.

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

>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.
]]Tables can be complicated to understand and navigate. To help users with
this, user agents should clearly delineate cells in a table from each other,
unless the user agent has classified the table as a layout table.[[
Look, I don't reject this assumption. You can see it this way: markup is
constituted by all those "things" which have a meaning. Well, data table
borders DO have a meaning, while a layout table doesn't need them. So it could
be used as a way to sniff the purpose of tables: is the content all that
matters or is content division (aka border) important too?
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"?
About <ol>s, also there it's something similar. Think about using an <ol> for a
sports tournament, with the list items representing series. Series are usually
marked with letters in some countries (e.g. here in Italy). The same for
sections in a book/essay, while parts of a law text can be marked with roman
numbers which are usually read as ordinals. There's space for meaning, there,
too.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Wednesday, 12 February 2014 19:16:20 UTC