Re: headers attribute debate

At 5:48 PM -0500 1 06 2007, Laura Carlson wrote:
>Related blog post:
>http://juicystudio.com/article/html-scope-headers-debate.php

Thanks for the reference.  Yes, the comments here do expose "the
usual arguments" in a way that saves us a lot of writing time, here.

>
>Comment from HTML 5 editor, Ian Hickson:
>http://juicystudio.com/article/html-scope-headers-debate.php#comment8
>
>>I have to be clear.
>>We are not going to have semantics for everything. If something is
>>rare, then it won't be supported. It really is that simple. This is
>>about achieving the 80% common case, it's not about making a language
>>that does everything. There are hundreds of things that people have
>>asked for which are not included because right now they simply don't
>>have the demand. For example, there's no way to mark up the
>>relationship between two SPAN elements containing the name of a lion
>>and the name of its kitten.

Just to indulge in 'commenting on the comments' briefly, as an aside,
this shows that the issues are not being clearly drawn.  Because there
is obviously a way to do this with a <link> drawn from the RDFa
namespace and a @rel drawn from a genealogy namespace.

What he is trying to say is there is no way to do this relying on
pure HTML markup. And we are not necessarily saying that the HTML
namespace has to do the whole job. But it has to play nice with
markup that does. [But functionally complete TD:TH association
semantics should be built in, in our opinion.]

>>There's no way to mark up the
>>relationship between two numbers in a big table (e.g. "that number is
>>twice this number"). If the occurrences of such tables  are rare,
>>then that, on its own, is an argument against this feature.

That is where the technical discussion turns into a food fight.

Frequentist arguments, the "80% rule" and its relatives, are a
guaranteed red flag among accessibility advocates.  Is this the
real issue, or is @scope vs. @headers the issue, unfortunately
there is probable some of each.

How can we turn the corner to a constructive dialog?

>>We have to have this razor, this restraint in adding features,
>>because otherwise our language will become bloated and
>>incomprehensible.

Ian is concerned about 'featuritis' -- adding many terms in the
markup vocabulary based on whatever anyone thinks is a requirement.

We need to make clear that we share this concern.  The question
is, is @headers featuritis, or is @scope?  That's a question that
may not really have been answered well in past decision making
outside W3C.  It is in that context that we should be approaching
feature tradeoffs.

And we really want to cooperate with and foster reform in HTML.

Note that Ian's remarks, taken in their entirety, are much more
'friendly' to supporting accessibility than is this quote.  So we
can also inflame the dialog by reading this out of context.

His post contains multiple errors of fact.

There is a way to mark up the relationship between the names
of the father and son lion.  Give each span an ID and comment
about the relationship in RDF somewhere.  That's just one
example, not the highest and best approach for future HTML
to take.

The Web security problem can't be built-in to the extent that
it doesn't require care on the part of people.  Just ask the
Web Security Context Working Group.  Their whole charter
revolves around enhancing the performance of the human nut
behind the wheel of the web browser, striving to change the
semi-formal language that goes to the user so as to improve
their performance in the exercise of prudence as regards the
extension of trust.

Web accessibility is the same way.  There is always some human
care that has to go into the authoring.  Our approach to this in
PFWG is to a) minimize the trouble we put authors to and b) build
in as much 'curb cut' side-effect benefits from taking that care
so that even 'though the author would not have asked for the
discipline, they will tend to thank us for it once the content is live.

But so what.  We need to grease the path to constructive action.
I'll see what I can do to weave the 80%-rule-NOT reasoning into
the response and we'll discuss it in the PF call this week.

On the whole, however the evidence offered here supports the
draft I floated earlier, thanks.

Al



>
>Laura
>
>--
>Laura L. Carlson
>http://www.d.umn.edu/goto/webdesign/

Received on Saturday, 2 June 2007 15:42:09 UTC