W3C home > Mailing lists > Public > www-style@w3.org > June 2012

Re: [CSSOM-view] Support centering an element when scrolling into view.

From: Thaddee Tyl <thaddee.tyl@gmail.com>
Date: Mon, 4 Jun 2012 18:08:34 -0700
Message-ID: <CAE3TfZOP98OLpKzQtv7s+BG0iLmr5bb8=zkugcGt4c2-9U-Pug@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>, "Robert O'Callahan" <robert@ocallahan.org>
Cc: www-style@w3.org
On Mon, May 28, 2012 at 7:56 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Mon, May 28, 2012 at 4:05 AM, Robert O'Callahan <robert@ocallahan.org> wrote:
>> On Sat, May 26, 2012 at 5:12 PM, Thaddee Tyl <thaddee.tyl@gmail.com> wrote:
>>> >> Also, don't forget to specify exactly what the area that is scrolled
>>> >> into
>>> >> view is. Currently CSSOM View refers to "the border box of the
>>> >> element",
>>> >> which is of course ill-defined since there can be zero or more
>>> >> border-boxes
>>> >> for the element.
>>>
>>> Should I redefine "the border box of the element"? I am afraid that would
>>> be
>>> hard to do.
>>
>> "The border-box of the element" is simply meaningless. You can't use that
>> phrase in a spec.
>
> Well, you can in some circumstances.  ^_^
>
> What you need to, Thaddee, is figure out what browsers do when, for
> example, an inline is broken around a large float, or a block is
> broken across multicol columns.  The usual answers are that they
> either care about (1) the (border) box of the first fragment, or (2)
> the bounding box containing all the fragments.

Webkit's scrollIntoViewIfNeeded cares about the bounding box
containing all the fragments.

>> > Also, I believe with CSS Regions it's possible to have an element which
>> > has
>> > some boxes in one scrollable container and other boxes in a different
>> > scrollable container. I'm not sure what should happen in that case.
>>
>> While I have no idea how it should work, I believe that this may not be
>> too important right now.
>
>
> If it's not specified now, then different engines will do different random
> things and it'll be much harder to fix later.

This issue is similar to what happens to
an element that gets scrolled into view inside an iframe.

I believe the behavior should be the same for the iframe and for
any scrollable container. What would benefit the user
(and what scrollIntoView already does) would be
to apply scrollIntoView to the element with respect to the iframe's
viewport, and then to apply scrollIntoView to the iframe's parents
one after the other.

For security reasons, I cannot create a polyfill for that behavior
(a script in an iframe from a third-party cannot run scrollIntoView on
the iframe itself).
Received on Tuesday, 5 June 2012 01:09:03 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:55 GMT