Re: range of non-overflown content

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