[Bug 17152] Support centering an element when scrolling into view.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17152

--- Comment #9 from Simon Pieters <simonp@opera.com> ---
(In reply to Thaddee TYL from comment #8)
> I am not sure what the block direction is. If it is about writing systems,

Yes. http://dev.w3.org/csswg/css-writing-modes-3/#block-flow-direction

> both axes are necessary for my use case. Centering horizontally is useful
> for context; for instance, on a long line that you need to scroll
> horizontally to see, search should center terms horizontally.

OK, I see that some browsers do that for page search, so that seems reasonable.

> > * The "evenIfViewed" thing (how about calling it "force"?)
> 
> I agree that would be useful. I picked the name "evenIfViewed" partly based
> on WebKit's "scrollIntoViewIfNeeded" and partly based on an attempt at
> expressiveness.
> 
> > That is, are there use cases for aligning in the inline direction?
> 
> Do you mean left-to-right?

When the block flow direction is top-to-bottom, yes. :-)

> The use-case for left-to-right is the same as
> that for top-to-bottom, when dealing with a webpage that can be scrolled
> left-to-right. Searching for terms in a page should center things
> horizontally as well.
> 
> > Are there use cases for aligning on the physical axes instead of the logical
> > axes?
> 
> I am not sure I understand the difference between physical axes and logical
> axes. At any rate, I believe all developers would understand vertical and
> horizontal.

The difference is that the logical axes change when the writing system changes,
while the physical axes don't.

Currently scrollIntoView is specified to scroll to the logical top (or bottom).

> > Are there use cases for aligning to arbitrary values 0..1 instead of just
> > start/center/end?
> 
> Providing a value from 0 to 1 allows webpages to specify exactly how much
> context they want to give. For instance, when scrolling to a graph embedded
> in a textual document, we would want to have the top of the graph roughly at
> the top, but we may want to show a piece of the text that introduces the
> graph to the reader.

Wouldn't you scroll the introductory text into view, then, and align that to
the top?

> In any case, scrolling a graph into view and having its top appear exactly
> at the top is ugly, and having its top appear exactly in the middle of the
> viewport is equally ugly (the majority of the viewport should be dedicated
> to the graph).

Yeah, I imagined that "center" would properly center the element, not align the
top of the element with the center of the viewport. That is, align the center
of the element with the center of the viewport. (Possibly aligning the top of
the element with the top of the viewport if the element is taller than the
viewport, and similarly in the other direction.)

> Also, I have seen cases where that percentage was used as a way to visually
> know where we are in a larger picture, specifically when zooming in in
> rectangular maps. When searching a spot on the map, that spot appears on the
> viewport such that its distance to the top and the left of the viewport
> reflects, by proportionality, the distance of the viewport itself to the
> edges of the map.

Do you have a URL for a page that does this?

> PS: based on the feedback about graphs in text, specifying whether what we
> want to scroll into view is the top, bottom, left, right, or center of the
> element can be seen as valuable. However, those are not expressive tools to
> the programmer who might want to center around the top left instead. Using
> percentages (as values between 0 and 1) for both horizontal and vertical
> covers all those possibilities and more, and it isn't much harder to
> implement.

Hmm, so sometimes you want the anchor point of the element to be its center,
and sometimes its top left? If we only support the top left you have to measure
the element's dimensions to really center it, which seems annoying. On the
other hand, having background-position-like behavior is also annoying if you
want exact positioning.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Friday, 19 September 2014 11:53:24 UTC