On Mon, Jan 6, 2014 at 10:54 PM, Ian Hickson <i...@hixie.ch> wrote: > On Mon, 6 Jan 2014, Dominic Mazzoni wrote: > > > > I understand that the addHitRegion APIs are the intended way to specify > > the permanent location of a fallback content element. But practically > > speaking, it makes far more sense to "cache" the bounding box of each > > element when you call draw*FocusRing, otherwise you end up with a timing > > problem, because as soon as you focus the fallback element, the screen > > magnifier immediately wants to know its bounding box - but > > drawSystemFocusRing may not get called until sometime later, when the > > app decides to repaint - and by then it's already drawn the bounding box > > in the wrong location. Some magnifiers respond to a "location change" > > event, but others don't, requiring an ugly hack like sending a second > > focus event, or delaying the first one. > > The paint is going to come within 16ms (unless the app has high latency, > in which case it'll be unusable anyway). That's when the magnifier should > be updated, not when the focus moves in the HTML document. >
We don't currently delay accessibility events until paint. It'd actually be a lot of extra work to do this and I can't see any benefit outside of this one corner case. > The simplest implementation of the current spec to cache the bounding > > box when you call drawSystemFocusRing and return whenever the assistive > > technology requests the bounding box of that fallback element, whether > > it's focused or not. I know it isn't exactly what was intended, and > > addHitRegion will be a more powerful solution, but I don't see the harm > > in implementing it this way. > > The harm is what I described in the earlier e-mails. You are likely to end > up zooming on the wrong thing. For example, if the app only renders the > focused element, and puts it in a random place when it's focused, you'll > draw the bounding box wherever the control was last time it was rendered, > which may have nothing to do with where it'll be this time. Similarly, if > the control is moving, but you only update the bounding box when the > control is first focused, then you'll leave the magnifier behind. > I think that's a good argument that we need to handle the case where the app updates the focus ring after it's been focused, which I agree with. There's no reason to assume the app would update the location before the first paint - it could just as easily begin a transition on the element once it's focused, so it doesn't reach its 'final' location until 1 second later. We should handle this case as well as possible. I don't see that as an argument against caching the last known location of an object too. - Dominic