W3C home > Mailing lists > Public > public-html@w3.org > September 2012

Re: Issue 30 (Was: RE: Getting HTML5 to Recommendation in 2014)

From: Sam Ruby <rubys@intertwingly.net>
Date: Thu, 20 Sep 2012 14:37:59 -0400
Message-ID: <505B6287.4020207@intertwingly.net>
To: Adrian Roselli <Roselli@algonquinstudios.com>
CC: "public-html@w3.org" <public-html@w3.org>
On 09/20/2012 02:06 PM, Adrian Roselli wrote:
>> From: Maciej Stachowiak [mailto:mjs@apple.com]
>>
>> On Sep 20, 2012, at 8:48 AM, Adrian Roselli <Roselli@algonquinstudios.com>
>> wrote:
>>
>>>> From: Sam Ruby [mailto:rubys@intertwingly.net]
>>> [...]
>>>>>
>>>>> I am still new to the group and trying to get a handle on the
>>>>> process overall.
>>>>>
>>>>> In this proposed draft plan can the a11y TF simply take the authored
>>>>> CP to re-instate longdesc and call it an extension spec? I assume
>>>>> format changes would be required, but I thought the heavy lift had
>>>>> been done to define it.
>>>>
>>>> Yes.
>>> [...]
>>>
>>> After some time doing other things (ok, deciding on lunch) another idea
>> occurred to me...
>>>
>>> This Plan 2014 document is just a proposal and it's up for discussion now
>> with an indeterminate agreement date.
>>>
>>> Can we just move ahead on the issue 30 survey? If that was the last step to
>>> resolving it, it might close (one way or the other) one of the 10 remaining
>>> open items for moving HTML5 along-- the only item that has a date on it and
>>> which has also passed.
>>
>> The Chairs expect that a decision in favor of any ISSUE-30 Change Proposal is
>> likely to lead to a Formal Objection. We believe the approach outlined in the
>> plan may be able to avoid a Formal Objection. This will save time on net, if we
>> can get everyone's buy-in. We also think treating the remaining issues
>> equally is important to getting people to agree with this approach for their
>> own pet issues, which is why we did not suggest singling any out for different
>> treatment.
>
> I'm not buying into that for three reasons:
>
> 1. This proposed process is just a discussion, it may not pan out or it may go differently, but all other activity appears to be coming to a halt. I don't see any reason why anything should come to a halt when there is no deliverable date for this new process. If the current process is fundamentally and demonstrably broken then I'd reconsider (which then calls into question all other related processes).

I encourage you to scan the A11y TF list:

http://lists.w3.org/Archives/Public/public-html-a11y/2012Sep/

The key point is that there is continuing active discussion, and it is 
the consensus of the HTML WG Chairs and the PFWG Chairs that this 
discussion should be allowed to proceed.  This was discussed on both the 
A11y and HTML WG calls today.  I encourage you to check the minutes.

http://www.w3.org/2012/09/20-html-a11y-minutes.html
http://www.w3.org/2012/09/20-html-wg-minutes.html

> 2. Not acting because there *may* be a Formal Objection isn't a reason. Granted, I don't know the players, who might object or how complex that process is. If I tell a client I'm not going to follow the agreed scope of work (the existing committed process and deadline, in this analogy) because he or she may object, I'd expect to be fired. I'd continue to move ahead and follow the expectations that have already been set. A Formal Objection will be dealt with, but at least there will be *movement*.

There is no "may" about it.  We have people making such statements 
without having even seen a decision.  We have every reason to believe 
that they will follow through.  And that resolving such FOs will delay 
our entry to CR.

> 3. The remaining issues are equally important. I also happen to see a deadline on this CP [1] when none of the others have one, which implies to me that it *should* be treated differently (it already is different). So don't single it out, just follow through on the commitment already made to it. *Not* following through (and allowing the missed deadline to continue to get older) means that this issue is, in fact, being singled out for different treatment (to use your words).

We had a deadline that was moved at the request of the Interaction 
Domain lead.  It was then moved again while we worked through the issue 
with the Director and CEO.  The plan you now see is the outcome of that 
process.  Once we get consensus on the plan forward (and has been noted 
there is at least one clear bug and undoubtedly are others), that entire 
page will need to be updated.

But instead of looking backwards, I would encourage us to look forward.

In fact, there is also a point that I would like clarification on.  I 
would like to know if longdesc is only ever intended to be used in 
controlled educational environments with significant copyright 
restrictions and for that usage universal adoption by mainstream 
browsers is not a requirement?

Or is there a universal need for "long textual descriptions" that is not 
currently being met?  If so, what changes are required in order to get 
browser vendors to sign on?

Key to this is the following data:

http://lists.w3.org/Archives/Public/public-html-a11y/2012Sep/0295.html

Possible answers include that usage on "top 10,000 web sites home pages" 
is not a market that longdesc intends to serve, in which case that data 
is irrelevant except to point out that the messaging on longdesc needs 
to be updated to make it clear what the target market of this attribute 
indeed is.

Another possible answer is that this is indeed a market that long 
descriptions (by whatever the attribute is named) is a requirement for. 
  In which case, we need to take this data very seriously first the TF 
and ultimately the HTML WG as a whole will need to determine what 
corrective course corrections is needed.

And I will note that these answers are not necessarily mutually 
exclusive.  Perhaps we need two separate attributes.

I will note that it is not my intent to advocate any of these positions.

- Sam Ruby

> 1. http://dev.w3.org/html5/status/issue-status.html
Received on Thursday, 20 September 2012 18:38:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 20 September 2012 18:38:22 GMT