Re: Bug 11239

On Thu, 28 Apr 2011, Benjamin Hawkes-Lewis wrote:
> 
> One example would be that the system has no caret. For example, a system 
> with no visual output presumably does not have a caret blink rate.

Could you provide an example of such a system where the author would 
nonetheless be using this value and where a return value of 0 would not 
be more likely to be handled correctly by the author?


> Perhaps where you currently have:
> 
> On platforms where a caret does not blink or is otherwise not adequately 
> described by a blink period, the attribute should return zero.
> 
> We could have:
> 
> If the caret does not blink, the attribute should return 0. On platforms 
> that do not have a caret or where the caret is not adequately described 
> by a blink period, the attribute should return -1.</p>
>
> Would that be acceptable?

That seems like terrible API design. You do not want rare cases in Web 
APIs, because authors will never test for them.

Or to put it another way: what problem does this solve?


> The representation of a visible object in an accessibility tree tends to 
> include a bounding rectangle property:
> 
> UI Automation AutomationElement.BoundingRectangleProperty 
> http://msdn.microsoft.com/en-us/library/system.windows.automation.automationelement.boundingrectangleproperty.aspx
> 
> MSAA IAccessible::accLocation 
> http://msdn.microsoft.com/en-us/library/ms696118(v=vs.85).aspx
> 
> Apple Cocoa NSView::frame 
> http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ApplicationKit/Classes/NSView_Class/Reference/NSView.html%23//apple_ref/doc/uid/TP40004149
> 
> Such bounding rectangles can be used by magnifiers to zoom the 
> appropriate part of the screen on change of focus.
> 
> A best-fit rectangle for a drawn path would be the smallest rectangle 
> that can contain all the points on the path.
> 
> So one clear goal here is that when user agents exposing content to such 
> APIs update the accessible tree, they populate properties like 
> BoundingRectangleProperty with the coordinates of the best-fit 
> rectangle.
> 
> Does this much seem workable?

Sure, but what's that got to do with what the spec says? We definitely do 
not want to be specifying UI, and this seems to be doing exactly that. The 
UA should be entirely at liberty to do what is best for the user; if the 
UA notices that the path consists of a single point off the screen and a 
rectangle on the screen, it seems like the UA should be entirely at 
liberty to ignore the point off the screen, for example.


> The same APIs tend to include hit testing that is /supposed/ to take 
> account of irregular areas. Here's documentation about how this is 
> supposed to work in the case of MSAA:
> 
> http://msdn.microsoft.com/en-us/library/ms695714(v=vs.85).aspx
> 
> I do not know whether canvas's design allows for more accurate 
> hit-testing than a best-fit rectangle. Olivier Hunt objected that 
> anything more would turn canvas into a retained mode API:
> 
> http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/0095.html

Hit-testing has nothing to do with drawing the focus area as far as I can 
tell. That's what isPointInPath() is for.


> Richard's position, which I imagine informed the Change Proposal, 
> appears to be that a best-fit rectangle is sufficient for hit-testing:
> 
> http://lists.w3.org/Archives/Public/public-html/2011Apr/0277.html
> 
> http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/0096.html
> 
> I seem to remember you've talked in the past about adding more of a 
> retained mode to canvas for enabling hit testing. Would it be viable to 
> start with hit testing based on best-fit rectangle and improve hit 
> testing for irregular shapes later?

I don't understand the relevance of this to this WG decision.


> > It's a required change; the alternative is that every time the UA 
> > draws the focus ring and then the caret the magnifier would blink 
> > around creating exactly the kind of situation that might lead to 
> > seizures, which is what a big part of this patch is about avoiding.
> 
> Sorry, this /sounds/ good I'm not sure I actually follow. Is the idea to 
> only send accessibility events if the method results in the focused 
> element changing or visible focus ring moving from where it was 
> previously drawn? Or are you talking about repainting that doesn't arise 
> directly from a call to this method?

The idea is to allow UAs to only inform the user once per event loop 
rendering step.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 28 April 2011 19:55:51 UTC