- From: Sam Ruby <rubys@intertwingly.net>
- Date: Sat, 10 Dec 2011 07:23:27 -0500
- To: "public-html@w3.org" <public-html@w3.org>
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 12:24:09 UTC