- From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- Date: Thu, 28 Apr 2011 19:00:07 +0100
- To: Richard Schwerdtfeger <schwer@us.ibm.com>
- Cc: public-html@w3.org, public-html-a11y@w3.org, public-canvas-api@w3.org, paulc@microsoft.com, Sam Ruby <rubys@intertwingly.net>, "Maciej Stachowiak (mjs@apple.com)" <mjs@apple.com>
On Thu, Apr 28, 2011 at 4:10 PM, Richard Schwerdtfeger <schwer@us.ibm.com> wrote: > it was my impression that Ian and other members of the working group were > wanting to avoid adding authoring guidance to the specification which he has > done. Where have people said they want this? > Nobody should be given carte blanche to write whatever they please in > the HTML specification without process approval. Our decision policy says that the editor should make edits to the editor's draft, and that if anyone has a problem with his edits they should raise them as bugs, then issues, etc. The policy is designed to minimize process approval. http://dev.w3.org/html5/decision-policy/decision-policy.html In this case, no changes have been made to the editor's draft; instead we're just reviewing the editor's patch in lieu of the Chairs providing a patch. > If Ian wants to make changes like this he should submit a bug later on. > > > 1. Ian's patch introduces technical extrapolations, leading to inaccuracies, > in the following comments. Also, not all applications require you to enter > text need to do all of what he is stating such as implementing drag and > drop. Drag and drop is standard behavior for editable text in WIMP desktop environments. > Also, contenteditable sections or standard UI controls don't do all of > what is needed in HTML. Take this one: http://www.lucidchart.com/ How does > one enter text in a drawing object with out editable text in the canvas? Use SVG. Or, if like the Lucid Chart developers you're happy to make your app an morass of nested divs and overlaid canvas elements, I don't really see why you could not mix contenteditable into the chaos to provide text editing. > No drag and drop is required. It is if the text editing experience is to match user expectations for text editing in WIMP desktop environments. > No copy and paste is required It is if the text editing experience is to match user expectations for text editing in most situations in most environments. > I could go on but this editorial comment is so limited in scope (full > blown rich text editing) that it should not be in the spec. in the > first place. The editorial comment is relevant to text editing of any sort, not just rich text editing. > Worse, this does not reflect the chairs decision. The chairs decision does not require this warning, but I don't believe this decision or any other has said we should not discourage authors from attempting to create text editing functionality with canvas. Ian's comment can be seen as an elaboration of the HTML spec's current warning: "Authors should not use the canvas element in a document when a more suitable element is available." http://dev.w3.org/html5/spec/the-canvas-element.html#the-canvas-element It would have been more politic to look to add this elaboration in a subsequent revision rather than in a patch purporting to enact the chairs' decision. > In the agreed on change proposal getCaretBlinkPeriod should return a > value less than zero if no operating system setting exists. Ian removed that > from the chairs decision. Yes, I'm not sure of Ian's rationale here. In fairness, Ian specifically asked twice what negative number to return in the bug and nobody answered him: http://www.w3.org/Bugs/Public/show_bug.cgi?id=11239#c21 http://www.w3.org/Bugs/Public/show_bug.cgi?id=11239#c23 Ian: could we perhaps specify to return -1 in this case? > Furthermore, this text was never in the chairs decision: > > > <p class="warning">Exposing the information mentioned in this > > + section increases the ease with which authors can fingerprint users > > + across sites even in the absence of third-party cookies or other > > + intentionally unique identifiers. Implementors are encouraged to > > + very carefully consider the implications of implementing these > > + features.</p> I note you don't challenge the substance of the warning. This is consistent with the advice given elsewhere in the spec about features that allow fingerprinting, for example: http://dev.w3.org/html5/spec/timers.html#client-identification Surfacing the user's caret blink rate is clearly a member of that set, as I noted in earlier feedback about the proposal: http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/0049.html Adding a note like this did have some support within the Canvas TF. Charles Pritchard said: "I'm up for adding a note somewhere, identifying these a11y apis as data points which could be used for fingerprinting, as a hint to vendors." http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/0057.html > 3. The actual procedural steps for driving magnification do not match the > chairs decision: > > This is what Ian has: > > > <li><p>Optionally, inform the user that the focus is at the > > + location given by the path. (For example, this could involve moving > > + the user's magnification tool.) User agents may wait until the next > > + time the <span>event loop</span> reaches its "update the rendering" > > + step to optionally inform the user.</p></li> > > This was the spec. change to the section: > > 1. If the element is not focused or is not a descendant of the element with > whose context the method is associated, then return false and abort these > steps. > > 2. If supporting an accessibility API, implementors may use the drawing path > to form a best fit rectangle in screen coordinates and apply it to the > bounding rectangle of the associated accessible object. > > 3. If the user has requested the use of particular focus rings (e.g. > high-contrast focus rings), or if the canDrawCustom argument is absent or > false, then draw a focus ring of the appropriate style along the path, > following platform conventions, return false, and abort these steps.
The > focus ring should not be subject to the shadow effects, the global alpha, or > the global composition operators, but should be subject to the clipping > region. > > 4. Return true. > > Ian's change does not reflect what is required to drive a magnifier. > Furthermore, he makes an assumption that the user agent is going to move the > user's magnification tool. The magnification tool moves in response to > accessibility APIs, in some function, and is a separate function. The only > thing the chairs said should not be applied in the change proposal was the > removal of canDrawCustom. The practical differences seem to be: * Ian's patch is less detailed in its suggestion of how focus notification should be approached, whereas your list suggests that a best fit rectangle on screen should be created and surfaced in the accessibility tree. I suppose vagueness provides for accessibility APIs that can understand non-rectangular areas. Ian, could we perhaps include the best fit rectangle approach as just as an example? * Ian's patch tries to ensure notification about change of focus happens after drawing the focus ring (potentially in the next event loop), whereas in your list the notification happens *before* drawing the focus ring (presumably preventing progress to the next event loop). Is this a bad change? Have I missed something? > This was not in the chairs decision either. I have no idea where this > came from: > > -<span>Navigator</span> implements <span>NavigatorStorageUtils</span>;</pre> > +<span>Navigator</span> implements <span>NavigatorStorageUtils</span>; > +<span>Navigator</span> implements > <span>NavigatorUserPreferences</span>;</pre> Ian's patch moves caretBlinkPeriod from the canvas context to window.navigator, much as I suggested in earlier feedback on the proposal: http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/0049.html Every property on the navigator object is defined as part of an interface, so if we're happy with moving the property, defining a new interface is consistent with how we define properties of the navigator object. As with the warnings about the difficulty of implementing text editing, it would have been more politic to put this interface on the canvas context in this patch, then look to migrate it in a subsequent revision. Does anyone object to moving the property from canvas context to navigator in this iteration? -- Benjamin Hawkes-Lewis
Received on Thursday, 28 April 2011 18:00:37 UTC