- From: <bugzilla@jessica.w3.org>
- Date: Wed, 12 Feb 2014 10:00:30 +0000
- To: www-validator-cvs@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24559
--- Comment #12 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> ---
(In reply to Andrea Rendine from comment #11)
> <http://web.archive.org/web/20140113194820/http://www.w3.org/TR/html5/tabular-data.html#the-table-element>
> <http://www.w3.org/TR/html5/tabular-data.html#the-table-element>
> Who changed the very text of the spec itself? It was told to me that a
> decision had been made about keeping the border attribute when I noticed
> this persistent difference between WHATWG's spec and W3C's.
Above you pasted a link to old and new version of HTML5.x. These versions are
pretty similar. Certainly with regard to @border, I see no difference (unless I
overlook *another* passage):
]]If a table element has a (non-conforming) summary attribute, and the user
agent has not classified the table as a layout table, the user agent may report
the contents of that attribute to the user. [[
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?
Now, as for WHATwg’s spec, the difference was introduced with the HTML Working
Group decision that you refer to.
I am not familiar with (in this very moment) how the text(s) have developed
since the decision. (I must - and will - go through and check.) However, as the
person who authored the change proposal that was adopted, I can say that I was
never quite satisfied with what Ian stated in the spec, right after the
decision, and uttered that view, after his edits back then. However, having got
border into the spec as conforming, I chose to not go more into it. I mention
this only to underline that I am open to changes as long as it remains
conforming.
> One very very little question. I didn't test but I see that my Chrome and
> IE(!!!) versions would interpret <table border="border"> correctly (it draws
> borders), as it was easy to imagine according to the fact that UAs interpret
> @border="" (empty string value).
Where is you question? ;-) 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? (WOuld be useful to know if other persons than David
read it that way.)
> Here's my idea. In HTML5 (or, as mr. Hickson loves to say, in HTML) there
> are attributes that have a direct effect in presentational hints (say,
> @hidden, or <dialog@open>. They're usually boolean attributes and have a
> very simple apparent meaning, but a serious syntactic purpose.
>
> Now for tables. It's hard to say that nowadays we still need layout tables
> as it was the case in the glorious (?!) age of Mosaic. Layout in the sense
> of "2 sections" page is REALLY obsolete and W3C must strongly discourage
> this behavior.
> But we are left with something. Last year I used a 2column-table to serve
> the same purpose that I'd have been able to achieve with a <dl> if the
> content model of <dl> weren't so poor. My table used no thead nor tfoot, and
> in the rows <th>s acted as <dt> and <td>s as <dd>.
I have done the same. I used to use <dl> for glossaries. But sometimes I use
<table>. Once we got feedback from our students that they liked table better
than <dl> simply because it was easier to paste it into MS Word, then …
> That was a layout table
> in some sense.
Indeed, there is no clear definition of what a layout table is.
> Sometimes 1-dimensional data or 2-dimensional with a discreet
> dimension which equals to 2 can be represented with ("layout") tables. So
> there's still a need to hint UAs whether to draw borders or not, in all that
> cases where CSS is unavailable (I usually create pages trying to make them
> readable in cases when connection fails, which is quite commonplace in some
> areas of my country) and some secondary resources fail to load. Why? Because
> if the table is discreet, borders are unnecessary as the author only wants
> to benefit from some table features.
>
> And how? Maybe with a boolean attribute. @border as we knew it until one
> month ago
Please be more specific about what change, 1 month ago, you refer to.
> was practically an abnormal boolean where the spec had to state
> that no values other than 1 and the empty string were allowed. Now, these
> can always be overridden with CSS, whatever value is given to the attribute.
> And the fact that every value can be present is to save old pages with
> @border given the desired value for layout. A real boolean would do the
> same, would be easier to manage in the future (modern browsers can avoid
> parsing the value at all and only consider its presence) and I hope it can
> achieve another result. Yes, @border is presentational in that it admits
> integers and so specifically states a visual representation in detail. Other
> attributes are still "presentational" like @open but mean more. Let @border
> belong to this family, keep it as stated in the past and maybe also the
> WHATwg will accept and suppress this silly gap. Seriously, it's not worth
> all this trouble.
@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.
It would certainly be possible to define it as boolean. ANd such a thing should
be of help to authors. If this would make @border more ”eatable” for the
opponents, the more reason to do it.
Like you, I *think* I disagree with the spec’s links between border and
”non-layout tables”. The spec(s) *only* permit(s) data tables: “Tables must not
be used as layout aids.“ Hence, to say that @border indicate that it is a data
table, may have the side effect of (under the table [sic! pun not quite
intended]) saying that layout tables can be signalled by leaving out the border
attribute.
The @border attribute can be likened to the @type attribute of <ol>: <ol
type="1">. Except that for <ol>, there is no need to add type="1", as the
default rendering is *correct*. And so, if you wish to use <ol> for ”layout” -
or simply fine tune it for your needs, you have to use CSS [or, to a limited
degree, @type itself] to remove the default list style for <ol>. The situation
for <table>, ought to have been the similar. It ought to have been the case
that leaving @border=1 out and leaving it in, had the same effect. (Or better,
there should have been a @borderless attribute.)
Borders by default would have made it less tempting to use borders for layout.
And so, table borders by default would simply have been a technique for
”nudging”[1] people to use <table> correctly. (One could claim that all the
default styles of HTML elements have the purpose of nudging authors to use the
elements correctly.) The table@border attribute should be thought of in those
terms. So, even if the (data) table in question fails to have border - when
viewed in a CSS enabled UA, the table should still have have the
border="border" attribute, to ensure a useful fallback styling.
[1] http://en.wikipedia.org/wiki/Nudge_theory
--
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Wednesday, 12 February 2014 10:00:32 UTC