Re: Bug 11239

On Fri, 29 Apr 2011, Maciej Stachowiak wrote:
> On Apr 28, 2011, at 11:25 AM, Ian Hickson wrote:
> 
> Could we get at least temporary agreement on -1 so we can get the 
> decision applied, and pursue the discussion of whether the "no setting" 
> case should return -1 or a hardcoded UA-chosen value?

Sure.


> It seems like the no setting case is likely to be an edge case, so we 
> can take our time refining it.

As far as I can tell, it's a case that literally never happens today. The 
main reasons that it's a bad idea are that it forces an attribute to be 
signed when it should logically be unsigned, and that it risks future user 
agent vendors sometimes returning -1 but finding that doing so breaks Web 
pages, leading to the feature being never implemented but wasting UA 
implementor time trying. Then, if the feature is never in fact 
implemented, any authors who tried to do the right thing by supporting it 
are themselves going to have wasted time on it.


> >>  * 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?
> > 
> > The best-fit approach text in the proposed patch is completely 
> > meaningless. I have no idea what was even _intended_ by the text. If 
> > someone could explain what it means, I would be happy to make sure the 
> > spec fully defines whatever is appropriate.
> 
> After thinking about it, I believe the intent is as follows: 
> 
> - Many screen magnifiers are driven by a general-purpose accessibility API.
> - From the point of view of a system accessibility API, when drawFocusRing() is called, the accessibility tree object that is marked as focused is the relevant backing element.
> - In order for a magnifier hooked up to the accessibility API mechanism to properly drive magnification based on a focus change, it needs the bounds for the newly focused object.
> - A good way to do that is to alter the accessibility object representing the element to have bounds matching the path for the focus ring.
> 
> In theory it is possible that UAs might drive a magnifier more directly, but in practice this is how it will happen. I believe describing it that way would be more useful to implementors.

I've tried to add a note to this effect.

New patch on the bug:

   http://www.w3.org/Bugs/Public/attachment.cgi?id=981

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

Received on Friday, 29 April 2011 20:04:55 UTC