Re: range of non-overflown content

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 <mailto:stearns@adobe.com>> wrote:
> On 10/30/15, 1:30 PM, "johanneswilm@gmail.com <mailto:johanneswilm@gmail.com> on behalf of Johannes Wilm" <johanneswilm@gmail.com <mailto:johanneswilm@gmail.com> on behalf of johannes@fiduswriter.org <mailto: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 <http://www.fiduswriter.org/>