On Tue, Nov 19, 2013 at 8:24 AM, Dominic Mazzoni
<notifications@github.com>wrote:

> In src/js/AccessibilityUtils.js:
>
> >
> > -    if (rect.top >= scroll_height || rect.bottom <= -scroll_top ||
> > -        rect.left >= scroll_width || rect.right <= -scroll_left)
> > -        return true;
> > -    return false;
> > -};
> > +    var parent = element.parentElement;
> > +    var defaultView = element.ownerDocument.defaultView;
> > +    while (parent != null) {
> > +        var style = defaultView.getComputedStyle(
> parent);
> > +        if (style.overflow == 'auto' && parent.scrollHeight > scrollHeight) {
> > +            if (axs.utils.elementIsOutsideScrollArea(parent)) {
>
> OK, but the recursive call searches up all of the parent chain also, so
> that makes it up to O(n^2) in the number of parents, admittedly only in the
> rare case where they are all scrollable.
>
Right - I'm not too worried about the complexity here, because only in
extremely pathological cases is N going to be more than even a few binary
digits.

> I don't quite follow how it matters if the parent is outside the body, and
> if so why you want to just continue with the next parent.
>
Because if the parent is outside the body, it doesn't form part of the
accessible (to any user) scroll area. Say I have a scrollable div which is
(1000x1000)px but positioned at -10000px, -10000px. There's no way I'm
going to see anything *within that element's scroll area*. Outside of its
scroll area is a different story, but I'm not interested in that - I'm
interested in things within the accessible scroll area, which this element
doesn't form a part of. I'll still be checking whether the element is part
of the scroll area of other elements which do form part of the total scroll
area (i.e. the case where it's positioned way outside the scroll area of
*this* element, but inside the scroll area of one of its parent elements).

> Suppose the parent is outside the body. If it's overflow:visible, then
> that's irrelevant, right? Because the parent could be positioned way to the
> right, but the original element could be outside its bounds and on-screen.
> So it seems like you need to check overflow first.
>
I don't think I follow this, sorry.

> If the parent is overflow:scroll or overflow:clip, then I agree you could
> cut off the computation early if the parent is offscreen, too - but that's
> not what you're doing, you're continuing with the next parent. I think you
> could just return false, unless I'm misunderstanding.
>
I don't think so - I think there could be elements in the parent chain
(it's unlikely but possible) which do overlap with the accessible scroll
area, so I still want to check them.

> Still, my inclination is to do something like this:
>
> if (element is outside the body)
> return false;
>
> for each parent:
> if (parent clips or scrolls, AND the element is outside this parent)
> return false;
>
> return true;
>
> Does that work?
>
Note that my logic is inverted from this (now - it wasn't earlier). I'm
trying to find a case where it's *inside* the scroll area of something
which can be accessed, and then return true (i.e. say that the element is
outside the accessible scroll area) only in the case where that can't be
done.

> —
> Reply to this email directly or view it on GitHub<https://github.com/GoogleChrome/accessibility-developer-tools/pull/71/files#r7762395>
> .
>