Re: range of non-overflown content

Are browsers wired so that overflow information is only available for the
part of the DOM that is currently in the viewport?

For the purpose of JS based layouting, the current viewport is not really
important, so if such a function would just ignore the viewport and give
overflow info as if the entire page was in the viewport, that would
actually make it easier on the JS side of things.

But maybe that type of information is harder to get at?
This starts getting pretty hairy given that scrolling containers can have
arbitrary children (including children whose containing block is outside of
the scrolling container). That being said, browsers are already in the
business of detecting content visibility.

Also, the page author would have to know to re-call such an API function
once the scroll position of ::any:: ancestor scrolling container changes
(since that can affect content visibility). In general, running script on
each frame of a scroll animation is not something I'd like to encourage.

As Alan said, such an API function would have to return a collection of
ranges (perhaps asynchronously?).

Also, if you scroll down by a single pixel, would that mean that the entire
top row is now no longer visible, since it doesn't entirely lie within the
viewport?

--Myles

On Oct 30, 2015, at 4:04 PM, Johannes Wilm <johannes@fiduswriter.org> wrote:



On Fri, Oct 30, 2015 at 3:03 PM, Alan Stearns <stearns@adobe.com> wrote:

> On 10/30/15, 1:30 PM, "johanneswilm@gmail.com on behalf of Johannes Wilm"
> <johanneswilm@gmail.com on behalf of johannes@fiduswriter.org> wrote:
>
> >Hey,
> >I spoke to Myles Maxfield (who works on Webkit's line-breaking mechanism)
> about what kind of useful information browsers could provide that would
> make it easier to do a lot of custom text layouting in Javascript. Even if
> that will be very slow, it is still
> > something that will be useful for a lot of publishing-related things.
> >
> >
> >Myles shot down several of my ideas, but the one thing he thought was not
> unrealistic to ask for was
> >a range-like description of the parts of the contents of a container that
> are NOT overflown.
> >
> >
> >Currently there are several ways to try to get this information,
> involving functions such as
> document.caretRangeFromPoint/document.caretPositionFromPoint,
> > but none of those are entirely stable and easy to use, AFAIK.
> >
> >
> >I wonder if we could have some kind of function call to get this
> information. If so, which spec would this go into?
>
> I think this would be quite useful, perhaps along with a flag on the
> container saying whether any content overflows or not (which is a perennial
> request that we’ve never addressed).
>

Right, such a flag would cut down on the number of checks one would have to
do in the JS to get what one wants.


>
> I’m wondering whether the range-like thing you’re looking for might need
> to be a sequence of ranges, as you can have complex overflow situations
> such as a container that displays three lines of text, where the second
> line overflows in the inline direction, and the third line contains a float
> where some of the floated content overflows.


Good point.


> Are you looking for:
>
> 1. A start and end point of the displayed content
> 2. Information about overflow in the block direction only
> 3. Information about block *and* inline overflow
>


3 would be best, but 2 would also be useful by itself. It depends a bit on
whether browser vendors think that providing both will cost them more or
not.


>
> Thanks,
>
> Alan
>



-- 
Johannes Wilm
Fidus Writer
http://www.fiduswriter.org