Re: function and impacts (was: @scope and @headers reform)

Hi Henri,
you wrote:
"Work[ing] with" and "cooperat[ing]" are different from the attitude I
was referring to. What I was referring to has been observable on the
list and on telecons, but it's elusive to pinpoint there, so I point
to the operative verb in title of this blog post for illustration:
http://www.paciellogroup.com/blog/?p=80
(The title is: "Circumventing Hegemony in the HTML WG")

This is just my advice and opinion and should not be attributed to the
motives or actions of anyone else.
as someone wryly pointed out it should have been titled "Circumventing
Hixie in the HTML WG"

If the HTML WG was a "working group" instead of a shell for a
dictatorship, there would be no need to circumvent anything.

regards
stevef


2008/9/25 Henri Sivonen <hsivonen@iki.fi>:
>
> On Sep 24, 2008, at 21:01, Laura Carlson wrote:
>
>> Henri wrote:
>>
>>> I don't like the attitude of trying to fast-track this particular
>>> thing even by trying to use another WG to override this WG when there
>>> are some many other things in the queue (including the WF2 stuff from
>>> 2006,
>>
>> HTML WG has requirements in our charter to work with  WAI, and PFWG in
>> particular. It says: "The HTML Working Group will cooperate with the
>> Web Accessibility Initiative to ensure that the deliverables will
>> satisfy accessibility requirements.
>
> "Work[ing] with" and "cooperat[ing]" are different from the attitude I was
> referring to. What I was referring to has been observable on the list and on
> telecons, but it's elusive to pinpoint there, so I point to the operative
> verb in title of this blog post for illustration:
> http://www.paciellogroup.com/blog/?p=80
> (The title is: "Circumventing Hegemony in the HTML WG")
>
>> However the @headers issue is 14 months old. Over a thousand messages
>> have been written on this subject on-list.
>
> What proportion of those messages has carried new information? I wouldn't
> want the WG to set a precedent that sending a huge volume of email gets an
> issue ahead of queue just to make the flood stop.
>
>> It has been an issue since
>> May 2007. [4] Like Julian mentioned "if each feedback loop takes two
>> years we have a serious problem that we need to fix, for instance by
>> installing more editors". [5]
>
> It would be great if we could go faster without having to make a tradeoff
> that would sacrifice something else (such as spec precision).
>
> Just having more people--any people--is not a solution (compare with
> http://en.wikipedia.org/wiki/The_Mythical_Man-Month). Potential editors who
> are competent, willing, available and have sustainable funding for spending
> substantial time on editing are in very short supply.
>
>>> Headers pointing to td. I may be missing some practical issues here,
>>> but to me it seems that this is essentially a statement against
>>> native markup semantics enabling accessibility and for promoting
>>> bolt-on accessibility as an ongoing solution. To raise the overall
>>> accessibility on the Web, making things work out-of-the-box should be
>>> the way to go, so we should promote proper use of th semantics.
>>
>> It is highly commendable to improve the algorithm, but retaining
>> headers/id functionality is needed as well as backwards compatibility.
>> I June 2007 PF advised grandfathering it into the spec
>
> In the part of my email you didn't quote, I said I was in favor of
> grandfathering headers/id into the spec. (With the caveat about the case of
> research showing net harm given existing content.) Your response makes it
> seem like I had said the contrary. (In fact, I also got off-list mail that
> seemed to assume I had opposed grandfathering headers/id, so perhaps I'm not
> communicating clearly.)
>
> As for only making it conforming to point to th (i.e. not td), consider
> compatibility with legacy clients:
> If an author marks up a table properly using th for headers so that the
> table would work with presumed future clients automatically, to feed the
> same associations to legacy clients, the author only needs to point to th
> elements with the headers attribute. (If the author were pointing to td
> element, (s)he'd be doing something other than merely adding compatibility
> for legacy clients. I'm assuming here that legacy clients don't barf on th
> elements, so th avoidance isn't required by legacy clients.)
>
> Consider amending cases where the automatic algorithm fails:
> If an author marks up a table properly using th for headers and the
> algorithm fails, the author needs to override associations and point to the
> right th(s). Here again, if the author were pointing to td elements, (s)he'd
> be doing something other than merely fixing associations that the algorithm
> got wrong.
>
> What am I missing?
>
> BTW, when I asked for expedited consideration regarding this issue in 2006
> because I was *about to write code* pertaining to this spec area, Hixie
> guessed
> (http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2006-October/007430.html)
> that the spec would have headers/id but only pointing to th in the same
> table would be conforming. If you try, you'll notice that the code is still
> running in Validator.nu, which means my guess is that we'll end up having
> headers/id in the spec.
>
> --
> Henri Sivonen
> hsivonen@iki.fi
> http://hsivonen.iki.fi/
>
>
>
>



-- 
with regards

Steve Faulkner
Technical Director - TPG Europe
Director - Web Accessibility Tools Consortium

www.paciellogroup.com | www.wat-c.org
Web Accessibility Toolbar -
http://www.paciellogroup.com/resources/wat-ie-about.html

Received on Thursday, 25 September 2008 08:18:28 UTC