Re: Request to re-open issue 131

On 12/10/2011 08:38 AM, Steve Faulkner wrote:
> Hi Sam,
> on a  somewhat related issue:
>
> I am trying to understand how the chairs come up with their criteria,
> for canvas you are now asking for ' testimonials' from 2 implementors,
> meanwhile responses in the negative (no commitment) from 4
> implementors did not appear to be good enough in regards to the title
> attribute issue[1], rather it was suggested that I need to obtain
>
> "statements where browser vendors say on the record that they
> absolutely won't implement, or believe it is not possible to do."
>
> is the objective criteria used in the 2 cases the same?
>
> [1] http://www.w3.org/html/wg/wiki/ChangeProposals/notitle
> [2] http://lists.w3.org/Archives/Public/public-html/2011May/0192.html

I'll be totally transparent here: the material difference here is that 
we have people who purport to represent implementors who are 
affirmatively stating that not only that they won't implement what is 
the W3C Working Draft[1], and furthermore have stated that they intend 
to implement what is in the current editors draft[2].

To date, we have seen neither change proposals from those implementors 
nor statements from (other?) implementors that they will implement what 
is in the Working Draft.  Am I happy about this situation?  Absolutely 
not.

However, I do have a job to do.  From where I sit, here's how I see it: 
in order to complete HTML5 on anything resembling a reasonable schedule, 
we need to force the issue and obtain at least one of the two.

> regards
> stevef

[1] http://www.w3.org/TR/2dcontext/
[2] http://dev.w3.org/html5/2dcontext/Overview.html

> On 10 December 2011 12:23, Sam Ruby<rubys@intertwingly.net>  wrote:
>> While I am forwarding this to the list (Charles: care to join the HTML WG?
>>   See: http://www.w3.org/html/wg/#join), I am not going to comment further as
>> it neither provides the implementor testimonials requested nor pursues the
>> process question with PLH.
>>
>> - Sam Ruby
>>
>>
>> -------- Original Message --------
>> Subject: Re: Request to re-open issue 131
>> Date: Fri, 09 Dec 2011 23:12:09 -0800
>> From: Charles Pritchard<chuck@jumis.com>
>> To: Sam Ruby<rubys@intertwingly.net>
>> CC: Richard Schwerdtfeger<schwer@us.ibm.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
>>
>> TL;DR: The set of methods approved by a chair decision earlier this year
>> were reverted by the HTML5 editor and subsumed by new methods. These
>> were done without discussion, but as there are no implementations, the
>> decision was easily vacated.
>>
>> http://www.w3.org/html/wg/wiki/ChangeProposals/CaretSelection
>> http://lists.w3.org/Archives/Public/public-html-a11y/2011Apr/att-0129/HTML_Canvas_2DContext20110415.html
>>
>> drawFocusRing(element, canDrawCustom) was moved into two methods,
>> instead of an optional boolean argument.
>> setCaretSelectionRect was moved into scrollPathIntoView, with some minor
>> tweaks.
>> caretBlinkRate() was removed.
>>
>> The only stable consensus at this point is that the checkbox in the
>> following example should be reachable by .focus() and tab navigation.
>>
>> <canvas><legend for="checkbox">Checkbox Item<legend><input id="checkbox"
>> type="checkbox" tabindex="0" /></canvas>
>>
>> This focusability has been in the HTML5 standard for quite some time,
>> but was likely overlooked by implementers thinking the fallback content
>> for<canvas>  was irrelevant to implementations where<canvas>  is supported.
>>
>>
>> Rest of reply is in thread.
>>
>>
>> On 12/9/11 8:08 PM, Sam Ruby wrote:
>>>
>>> On 12/09/2011 10:46 PM, Charles Pritchard wrote:
>>>>
>>>> On 12/9/11 7:25 PM, Sam Ruby wrote:
>>>>>
>>>>> On 12/09/2011 05:42 PM, Richard Schwerdtfeger wrote:
>>>>>>
>>>>>> I see Ian replaced the entire Canvas 2D API spec. without a formal
>>>>>> proposal:
>>>>>>
>>>>>> 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.
>>>>
>>>>
>>>> I'm not intimately familiar with W3C processes -- but I must ask -- why
>>>> do you claim this action is "nothing to worry about"? The latest
>>>> revision reverts changes made by the chair decision "applied no later
>>>> than the end of day on the Thu 12th of May [2011]".
>>>> http://lists.w3.org/Archives/Public/public-html/2011May/0138.html
>>>
>>>
>>> The issue is now reopened, you can verify that status yourself:
>>>
>>> http://www.w3.org/html/wg/tracker/issues/131
>>>
>>> If, as I stated above, if there is no formal proposal that covers the
>>> changes the editor has elected to make, and we obtain testimonials
>>> that the changes that were previously proposed and were adopted would
>>> be implemented, then I see absolutely no reason to believe that the
>>> next time we close issue 131 that we will come to the same decision.
>>>
>>> Meanwhile, there is an opportunity to address one or both of the
>>> exclusions.
>>
>>
>> I'm having a hard time parsing your syntax, I can't figure out which of
>> the two subjects you are referring to.
>>
>> There is the determination of the Chairs to "Modify existing Canvas 2D
>> API caret and focus ring support to drive screen magnification":
>> http://lists.w3.org/Archives/Public/public-html/2011Apr/0271.html
>> http://www.w3.org/2002/09/wbs/40318/issue-131-objection-poll/results#xkeepnew
>>
>> And there is the minor part of that decision where more clarification
>> was needed:
>> "The change to add baseline to the TextMetric interface is not
>> adopted... Proposals to add baseline measurement support can be
>> considered if sufficient detail is provided"
>> http://lists.w3.org/Archives/Public/public-html/2011May/0351.html
>>
>> The first subject involved several added methods to the Canvas 2d API
>> including a caret position method and blink rate information. The second
>> subject involves the addition of one property to the TextMetrics API.
>> They are two very different subjects.
>>
>> The deficiency of the TextMetrics API does not need to be expressed in
>> the terms of Issue 131, it clearly stands on its own. It affects a
>> variety of things, not just accessibility. One very simple example is
>> that it's absurdly difficult to reproduce the following graphic in
>> Canvas, as it does not currently report baseline offsets:
>> http://www.whatwg.org/specs/web-apps/current-work/images/baselines.png
>>
>> And here's the issue:
>> http://www.w3.org/html/wg/wiki/ChangeProposals/FocusRingTextBaseline
>>
>> That's quite a different document than the one the representing the
>> issue the Chairs made a final decision upon:
>> http://www.w3.org/html/wg/wiki/ChangeProposals/CaretSelection
>>
>>
>> I'm coming to the conclusion that you're referring to them together.
>>
>>
>>>> The proposal Richard has been floating recently simply covers
>>>> TextMetrics and has little-to-nothing to do with the chair decision from
>>>> May. It was requested that the issue remain separate from the May action
>>>> by the chairs.
>>>
>>>
>>> That's not what was said.  What was said was "Proposals to add
>>> baseline measurement support can be considered if sufficient detail is
>>> provided."
>>>
>>
>> A separate bug report was to be filed, and the issue treated with a
>> separate Change Proposal.
>>
>> Instead of addressing item #7 on the "accepted" Change Proposal, the
>> entire CP has been reverted and the chair decision apparently reversed.
>> http://www.w3.org/html/wg/wiki/ChangeProposals/CaretSelection
>>
>>
>>>> I'm thoroughly confused as to what the subject is, when you are
>>>> referring to "your proposal". What weight or authority does the decision
>>>> from May have? The patch was applied by W3C staff as the editor would
>>>> not apply it himself. The editor recently reverted the change, and
>>>> neither the chairs nor editor have provided an explanation.
>>>
>>>
>>> We vacated that decision for the reasons specified.  If you are
>>> unhappy with the chairs action in this matter, I encourage you to take
>>> this matter up with PLH.  However I will again state that from my
>>> perspective if you can't get implementers lined up, it doesn't much
>>> matter.  And if you can get implementers lined up and nobody follows
>>> through to prepare a suitable proposal to match the edits that Ian has
>>> made, then you have nothing to worry about.
>>>
>>
>> Is one reason being that six months have passed without implementation?
>> Is the other reason being that issue #7 on the CP is being re-evaluated?
>> Is the third reason being the disclaimer entered into the CVS, and the
>> ease in which the document can be forked?
>>
>> I'm well aware that implementers must deliver a working product for a
>> specification to be meaningful.
>>
>> The unstable, opaque process at work here is counter-productive toward
>> that goal.
>> Take Mozilla's bug report for example, on focus rings:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=540456
>>
>> What name should they have used? From the prior chair decision, it was
>> drawFocusRing(element, canDrawCustom)
>> Now there are two methods, and there has been no public discussion as to
>> why there are two methods.
>>
>> I've got no idea why there are two methods.
>>
>> I'm concerned about trying to hit a moving target. The instability in
>> that Mozilla bug report, undermines my ability to get work done with
>> vendors, and it devalues my time and contributions to this process. I
>> sought public review and cooperation from the W3C and followed
>> procedure. I'm hearing that the time should have been spent coding
>> implementations.
>>
>> Vendors, including the two I could easily submit patches to, Mozilla and
>> Webkit, tend to follow the specifications authored in this process. So
>> if I go and start sending them patches that aren't reflected in w3c
>> documentations, they're likely to reject those patches. I understood my
>> involvement with W3C procedure to be a precursor to implementation.
>>
>>
>>>>>> Could you please clarify how this is consistent with the HTML working
>>>>>> groups decision policy or with the process you refer to below?
>>>>>
>>>>> ...
>>>>> Obviously, I would encourage you to focus on obtaining implementer
>>>>> testimonials instead of taking that path, but the choice is yours.
>>>>
>>>>
>>>> I think we all understand that the existence of an implemented API
>>>> across two independent implementations is an often used and accepted
>>>> measure for writing the standard. Many implementers are hesitant to put
>>>> in such implementations in relation to accessibility until there's some
>>>> guidance from the w3c. We seem to be in a catch-22 here.
>>>
>>>
>>> It's not a catch 22.  The text that you cited has been in place for
>>> over six months.  If you have implementations to point to, I encourage
>>> you to do so.
>>
>>
>> It's only been six months. Six months is a very short amount of time to
>> introduce new methods into multiple implementations.
>>
>> If I had implementations to point to, they'd now be out of spec and
>> their associated vendors would have pie in their face.
>>
>> I get it though, implementations first, W3C procedure can follow. I'll
>> adjust my attention accordingly.
>>
>>
>>>>> 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.
>>>>
>>>>
>>>> They've been escalated as far as I'm aware.
>>>
>>>
>>> Since you haven't specified a bug number, I can't verify this.  The
>>> bugs that are current escalated can be found here:
>>>
>>> http://dev.w3.org/html5/status/issue-status.html
>>>
>>> If the bug that you are thinking of is not on that list, I again
>>> encourage you to read the resolution text that is provided in the bug
>>> report itself.
>>
>>
>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=13176
>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=11342
>>
>> There's no push-back on the TextMetrics proposal, I'm not too concerned.
>>
>> I suppose this has to be re-opened in light of setCaretSelectionRect
>> being subsumed by the editor's scrollPathIntoView
>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=11240
>>
>>
>>
>>>> The HTML editor continues to assert that interactive Canvas
>>>> accessibility is not an issue as Canvas should not be used for
>>>> interactive components, beyond an arbitrary set of button, checkbox and
>>>> radio. This is reflected on the whatwg specification.
>>>>
>>>> We're in a bit of a bind here.
>>>>
>>>> I'm sure vendors will move forward, regardless, as they have real-world
>>>> commitments to accessibility. The chairs previously put forward a
>>>> decision which has now been circumvented by the HTML editor. It seems
>>>> odd to submit Change Proposals under such circumstances. Why go through
>>>> the process if it holds no authority?
>>>
>>>
>>> That text has been in place for six months.  We've had explicit
>>> statements to the contrary from implementors.  What's different about
>>> this go around is that we are asking for the statements from
>>> implementors up front.
>>
>>
>>
>> I did not intend to suggest they would move forward with the old change
>> proposal. I meant to say they will move forward with improving Canvas
>> accessibility.
>> Canvas works quite fine for authoring widgets in its present state, it
>> merely lacks wide support for the sub-tree as the concept of fallback
>> content has only recently evolved into what amounts to a live
>> alternative view.
>>
>>
>>>
>>>>>> 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.
>>>>
>>>>
>>>> Cute.
>>>
>>>
>>> Nothing cute intended by that statement.  In the interest of full
>>> disclosure, I live in Raleigh.  Take a look at the timestamp of
>>> Richard's email.  By the time I saw it, I was out to dinner.  They my
>>> wife and I, our daughter and a friend of hers went to see a play:
>>>
>>> http://rltvolunteers.org/rltphotos/yearbook/cinderella.html
>>
>>
>> It that's not cute, I don't know what is.
>>
>>> I responded as soon as I got home.  I will also note that as I
>>> continue to be in Raleigh, should you respond further tonight, I will
>>> likely not see it until the morning.
>>
>>
>> I don't expect same hour nor same day response, but I do appreciate your
>> level of attentiveness.
>>
>> As you've noted, there's no rush here. I don't think anyone expects you
>> to be around to respond within the hour.
>>
>>
>>> While I have responded, what I am requesting is that those interested
>>> in pursuing this either post vendor testimonials or get with PLH.
>>> There still will be plenty of opportunity to obtain and provide these
>>> in at least the first part of January, so there is no need to rush to
>>> obtain these before everybody else disappears.
>>
>>
>> I'm fine waiting on this. The TextMetrics issue is a trivial patch and
>> the subsequent changes by the HTML5 editors aren't relevant until
>> implementers catch up to simply supporting focus on sub-tree elements.
>> Those patches are not as simple, but in a nutshell, involve changing
>> HTMLCanvasElement to behave more like a form control, where it currently
>> behaves like a simple rendering block.
>>
>> We'll see some new patches in January and go from there.
>>
>>
>> -Charles
>>
>>
>
>
>

Received on Saturday, 10 December 2011 14:16:13 UTC