Re: pagination features in web apps vs. browsers. (was: Re: [Meeting Summary] Meeting summary for 2015-08-31)

One more thing:

As for features I have requested from CSS Houdini to be able to do
pagination-related features in the browser in JavaScript: They are all
related to fragmentation/breaking.

The most useful would be if we could get an API that gives us access to the
following information:

A. If I WERE TO put content X into container Z, where WOULD the line breaks
in content X occur?

b. If I WERE TO put content X into container Z, how much of X WOULD fit
into Z without causing overflow?


This should be quite useful for a number of things, such as creating
pagination containers, finding out how much space one has left for the main
body text on a page after taking footnotes into consideration, creating
pages with lines of variable lengths, etc. . The reason the two are
formulated in the subjunctive is that many/most times one will inquiry
several times about where things are to go before actually placing them.
For example, one may have a text one wants to fill in a page and therefore
use method B to find out how much would fit on the first page. Once one
figures that out, one can see how many footnotes there are in that content.
So one goes ahead and calculates the space needed for footnotes and has to
ask again how much of the content now would go into the the first page.
Then one finds that some of the footnotes no longer are on the first page,
etc. . It is currently possible through various hacks to more or less
figure out how much content actually fits into a given container and where
line breaks actually take place, but that means one needs to let the
browser draw everything first, then measure, then most likely redraw again,
etc. . Besides being a hack with not entirely certain results, altogether
all the drawing and redrawing operations makes the process rather slow.

Besides that, it would be an obvious advantage if we could rely on
something like CSS Regions to be available in all browsers.


On Sun, Sep 6, 2015 at 10:56 AM, Johannes Wilm <johanneswilm@vivliostyle.com
> wrote:

> Hey,
> I read the minutes of the meeting meeting.
>
>
> I don't think it's quite as negative as some seem to take it. It is true
> that browser vendors simply are not interested in most of these features,
> and that will not change no matter with hos much emphasis one makes clear
> that the publishers really would want this.
>
> But we are not very far away from getting the features we need to do good
>  pagination-related features entirely in JavaScript through the CSS Houdini
> group. Some seem to think that that is the end of talking about
> page-related features in the CSSWG. I think it's rather the other way
> round: Browser vendors may not want to discuss those features anymore, and
> they can go drink coffee meanwhile, but once JavaScript starts consuming
> CSS, the authors of JavaScript apps will want to discuss about
> standardization of the CSS features they implement. And the CSSWG may end
> up being the right place for that.
>
> However, it is true that even with Houdini, most of the features that are
> coming are thought up by browser developers, at times with just a
> rudimentary understanding of all the complexities of web apps. And most of
> those talking about web apps are thinking of things like speeding up
> jQuery, not things that are important for us.
>
> It would really help if some other groups besides us who do page-alike
> layout using CSS could show up at the CSSWG meetings and give their input
> on what technical features are needed. Else it can easily sound as if this
> is just something a few hackers at Vivliostyle came up with and noone else
> is interested in.
>
> I think Nick is right, that in the publishing industry very few want to do
> something others then can use for free. The browser world is different in
> that sense.
>
> But we cannot really ask browsers to please take over the task of creating
> a book display system if they aren't really interested in books at all. The
> publishing world just has to change to survive, and find a way to do it
> without having the browser vendors remove the their features the publishers
> need due to shifting priorities (as we saw with CSS Regions).
>
>
>
>
> On Tue, Sep 1, 2015 at 9:28 AM, Ivan Herman <ivan@w3.org> wrote:
>
>> Meeting summary is here:
>>
>>
>> http://www.w3.org/blog/dpub/2015/09/01/dpub-ig-telco-2015-08-31-css-wg-meeting-charter/
>>
>> Ivan
>>
>> ----
>> Ivan Herman, W3C
>> Digital Publishing Lead
>> Home: http://www.w3.org/People/Ivan/
>> mobile: +31-641044153
>> ORCID ID: http://orcid.org/0000-0003-0782-2704
>>
>>
>>
>>
>>
>