W3C home > Mailing lists > Public > public-canvas-api@w3.org > October to December 2011

Re: Request to re-open issue 131

From: Sam Ruby <rubys@intertwingly.net>
Date: Tue, 13 Dec 2011 08:24:48 -0500
Message-ID: <4EE75220.7050200@intertwingly.net>
To: Richard Schwerdtfeger <schwer@us.ibm.com>
CC: chuck@jumis.com, Cynthia Shelly <cyns@microsoft.com>, dbolter@mozilla.com, franko@microsoft.com, Maciej Stachowiak <mjs@apple.com>, Paul Cotton <Paul.Cotton@microsoft.com>, public-canvas-api@w3.org, public-html@w3.org, public-html-a11y@w3.org
On 12/13/2011 06:17 AM, Richard Schwerdtfeger wrote:
> Sam Ruby <rubys@intertwingly.net> wrote on 12/09/2011 09:25:14 PM:
>  > From: Sam Ruby <rubys@intertwingly.net>
>  > To: Richard Schwerdtfeger/Austin/IBM@IBMUS,
>  > Cc: chuck@jumis.com, Cynthia Shelly <cyns@microsoft.com>,
>  > dbolter@mozilla.com, franko@microsoft.com, Maciej Stachowiak
>  > <mjs@apple.com>, Paul Cotton <Paul.Cotton@microsoft.com>, public-
>  > canvas-api@w3.org, public-html@w3.org, public-html-a11y@w3.org
>  > Date: 12/09/2011 09:25 PM
>  > Subject: Re: Request to re-open issue 131
>  >
>  > On 12/09/2011 05:42 PM, Richard Schwerdtfeger wrote:
>  > > I see Ian replaced the entire Canvas 2D API spec. without a
> formalproposal:
>  > >
>  > > http://dev.w3.org/html5/2dcontext/
>  >
>  > Should a formal proposal not be forthcoming, and should you be able to
>  > obtain testimonials from at least two major implementors that that they
>  > would be willing to implement your proposal should it be adopted, then
>  > you have nothing to worry about. If you need to modify your Change
>  > Proposal(s) in order to obtain these testimonials, you have the
>  > opportunity to do so. We've not established a deadline yet for this,
>  > but the earliest deadline we would impose would be late January by this
>  > point. It could possibly even be later.
>  >
> 1. We are not in Candidate Recommendation phase. No such W3C process
> requires implementations before CR.

First I will state that I understand the frustration.

At CR we will looking for compatible implementations of the spec.

What we are looking for now is something different than that.

We have statements by individuals purporting to represent 
implementations that they WILL NOT implement the W3C specification. 
Those statements, if true, would represent very strong objections.

To date, those people have declined to provide new information.  They 
have declined to provide a new change proposal.  That's the problem I 
intend to focus on.

> 2. Microsoft, IBM, and Mozilla were presenting a canvas accessibility
> workshop for SXSW targeted for early March where we would be doing
> implementations. By breaking process the HTML working group chairs
> effectively broke the ability to implement the specification as you
> removed all the caret and selection processing.
> We already made a proposal which the chairs voted on and the chairs
> allowed a proposal that has no implementation to come in and override
> it. No browser manufacturer has implemented the new focus ring APIs in
> the edited spec. For example, Webkit does not even have fallback content
> in it yet so indicating where the focus ring is in fallback content on
> an accessible is a very long way off right now.
> 3. Chrome follows the Firefox implementation for accessibility. I know
> this as I work with both browser manufacturers.

Can we get a simple statement from Mozilla?  All it needs to state is 
that they intend to implement whatever the 2D Canvas API might contain 
for a focus ring API in the W3C spec?  We are not looking for a 
commitment as to timeframes.  We are simply looking for a statement of 
intent at this point.

> So, what the chairs have done is responded by heresy by perhaps one
> chair from Apple.

I encourage you to read the Discussion Guidlines:


While the remainder of your email was professional, I will state that 
the above sentence crossed the line.

> This is why W3C has a process and why companies like IBM participate in
> standards efforts. The process is designed to take input from all
> participating members and provides adequate time to allow members to
> implement the specification. Not only did the chairs break process but
> they also hindered implementations under way.
> 4. Caret and selection processing was removed. These were critical
> features that drive magnifiers for low vision users. There is nothing in
> Ian's change that supports those use cases which the chairs approved.
> Now, perhaps Ian preferred a better API but no such replacement came
> forth in the change. They were simply deleted.

The text that was selected continues in the lasted published WG draft. 
It is true that it no longer exists in Ian's editor's drafts.  I have 
stated that you have an opportunity to produce a "Richard's" editor's 
draft, and have it published alongside Ian's.

Should we get statements from multiple browser vendors of their intent, 
and we continue to NOT get new information and NOT get a new Change 
Proposal, then we will reinstate the prior decision.

>  > > Could you please clarify how this is consistent with the HTML working
>  > > groups decision policy or with the process you refer to below?
>  >
>  > There exists a document in CVS with Ian's name on it with the following
>  > text prominently in the frontmatter:
>  >
>  > The publication of this document by the W3C as a W3C Working Draft
>  > does not imply that all of the participants in the W3C HTML working
>  > group endorse the contents of the specification. Indeed, for any
>  > section of the specification, one can usually find many members of
>  > the working group or of the W3C as a whole who object strongly to
>  > the current text, the existence of the section at all, or the idea
>  > that the working group should even spend time discussing the
>  > concept of that section.
>  >
>  > If you would like to create a parallel document in CVS with your name on
>  > it and the same disclaimer, we will help you do that. But I will state
>  > that there really is no need to do that. Your Change Proposals are
>  > sufficient.
>  >
> If our original change proposals were sufficient and they were indeed
> voted on then why would the chairs allow an alternative (non-voted on
> spec.)?
> The point being that our change proposals for Issue 131 were clearly not
> sufficient as someone is simply able to overwrite them.
>  > I already stated why the Chairs elected to take this action. If you
>  > have a problem with this, I encourage you to take this up with PLH.
>  > Mike Smith will assist you in this effort should you decide to go this
>  > route.
>  >
>  > Obviously, I would encourage you to focus on obtaining implementer
>  > testimonials instead of taking that path, but the choice is yours.
>  >
> As I stated, we are not in CR. There should be no reason to do this at
> this time. We were in the process of implementing them and the chairs
> torpedoed the effort. Enterprise browser manufacturers want to implement
> a spec. that is approved. The chairs killed that effort.

No spec, at this point, is approved.  I encourage you to read the status 
section of the editor's working draft carefully.

>  > > I also noticed Ian went into numerous related defects and added
> requests
>  > > for use cases, such as:
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=13578
>  > >
>  > > We have on numerous occasions provided information on things like
>  > > providing the bounds of an object such as Frank Olivier presented at
>  > > TPAC. Please refer to the use cases minuted at the TPAC discussion.
>  >
>  > I'm pleased to see that things are progressing again. As to Ian's
>  > request: since you state that the data is already publicly available, I
>  > encourage you to provide pointers to that data.
>  >
> You were at the TPAC face to face and in fact sat in on Frank Olivier's
> presentation. You are welcome to spend your cycles sending Ian a link to
> the meeting minutes. The chairs created this situation - not the people
> working on canvas accessibility.
> Allowing this to happen raises some concerns for me. These are that the
> W3C's processes for producing specifications appears compromised and
> that we are entering an anti-competitive state on the Web. One that does
> not favor people with disabilities.
> Unfortunately, we will have to present this change on Canvas
> accessibility at SXSW and CSUN. Where at one time we had hoped to
> provide positive work on canvas accessibility, now due solely to the
> chairs response in this matter, we do not.
> This is a very sad situation.

Again, I understand the frustration.  But if Mozilla is planning on 
sending representatives to SXSW and CSUN and making statements as to 
what Mozilla intends to implement, perhaps those individuals could be 
encouraged to make such a statement on the public_html mailing list?

>  > In any case, if for any reason these bugs aren't resolved to your
>  > satisfaction by December 31st 2011[1], you will have the opportunity to
>  > escalate the bugs and propose your own resolutions in the form of
>  > concrete Change Proposals.
>  >
>  > > I am leaving for vacation in an hour and will be unavailable for mostly
>  > > through the end of the year. I look forward to your reply.
>  >
>  > Unfortunately, I wasn't around to respond within the hour. Hopefully
>  > you will see this when you return.
>  >
>  > > Best Regards,
>  > > Rich
>  >
>  > - Sam Ruby
>  >
>  > [1] http://lists.w3.org/Archives/Public/public-html/2011Jun/0315.html

- Sam Ruby
Received on Tuesday, 13 December 2011 13:32:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:31:54 UTC