- From: Sam Ruby <rubys@intertwingly.net>
- Date: Sat, 10 Dec 2011 16:57:49 -0500
- To: Steve Faulkner <faulkner.steve@gmail.com>
- CC: Maciej Stachowiak <mjs@apple.com>, Philippe Le Hegaret <plh@w3.org>, Paul Cotton <Paul.Cotton@microsoft.com>, www-archive <www-archive@w3.org>, "Michael(tm) Smith" <mike@w3.org>
On 12/10/2011 03:22 PM, Steve Faulkner wrote: > Hi Sam, > > just for the record, there are currently NO implementors that have > made a commitment to provide input device independent access to title > attribute content and 2 implementors have publicly stated that the > have no plans to, while the other 2 have declined to provide details > of future implementations. There has been no public change to the > implementor's stated positions or changes to implementations in the > last 9 months (same level of implementation as the past 10 years). Is it fair to assume that this information is relevant to Issue 192? > regards > Stevef - Sam Ruby > On 10 December 2011 14:09, Sam Ruby<rubys@intertwingly.net> wrote: >> 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 22:04:51 UTC