W3C home > Mailing lists > Public > www-style@w3.org > October 2013

Re: [css-regions] Named Flows, Elements and Box Generation

From: Johannes Wilm <johannes@fiduswriter.org>
Date: Sun, 27 Oct 2013 09:02:58 +0100
Message-ID: <CABkgm-RtbUqD9wZXW4fGpgLd5HDxS-1jtK3fEwJmnJA1oOrCFg@mail.gmail.com>
To: Håkon Wium Lie <howcome@opera.com>
Cc: www-style@w3.org
Hey Håkon,

On Sun, Oct 27, 2013 at 1:47 AM, Håkon Wium Lie <howcome@opera.com> wrote:

> Hello Johannes,
>  > you might remember I wrote a little while ago. We have created a little
>  > javascript app that renders pages in the browser the way they are
> printed
>  > using CSS Regions. ( http://sourcefabric.github.io/BookJS/ )
> Yes, here's the conversation:
>    http://lists.w3.org/Archives/Public/www-style/2013Apr/0210.html
> I recoded your examples into pure HTML/CSS here:
>   http://lists.w3.org/Archives/Public/www-style/2013Apr/0631.html
> My conclusion at the time was that it was simpler and easier to write
> this in HTML+CSS, without using the complex book.js.

>   http://sourcefabric.github.io/BookJS/book.js

I think specific CSS for print such ass css-gcpm is a great idea, if there
is enough interest in doing all this just for the cases when people want
good print.

But as I understand it, this will only work for print/PDF output, right?

BookJS we also use as part of an editor where you can "see" the pages as
they will appear in print in the browser first. The pages are drawn with a
black line around them and a grey background and some space in-between them
(very similar to Google Docs). Additionally there are some toolbars on the
top that are not part of the pages, and there can be comments shown off in
the right margin, outside the pages (see
https://www.diigo.com/item/image/4e1dc/hge5?size=o ).

And what about the page counter? If it is a CSS counter, then that is not
available to javascript, right? Then one cannot easily figure out how many
pages there currently are for usage other places in the UI, correct?

> I'm not dissing your code; I think it's amazing what you've been able
> to do in legacy browsers by adding JavaScript. But I do think that
> (say) footnotes and top floats should be "first-class citizens" in a
> page-based rendering systems, and not just the outcome of a javascript
> reordering algorithm.
> They are described as first-class citizens here:
>    http://books.spec.whatwg.org/

In that draft it speaks of screens as well as printed media.

Whereas here http://www.w3.org/TR/2013/WD-css3-page-20130314/#page-model it
seems to only speak of printed media.

Will this also work when you want to display pages on the screen the way
they will be printed and also some additional elements (see above)?

>    http://figures.spec.whatwg.org/

>  > I can understand that overflow:fragments make a lot of sense in many
> cases
>  > when nothing more is required. But if overflow boxes all have to be
>  > siblings, that would certainly be problematic if you do stuff like we do
>  > it. Or what about doing subflows from flows?
> Could you point to one of your example where you use this?

When flowing footnotes or margin notes out of the the already flown main

>  > I do not get the problem with the HTML-element either. Whenever one
> makes
>  > just the most simple websites, one includes a lot of extra elements to
> be
>  > able to position other elements within it.
> We're trying to change that.
> That's why, for example, you can now have multiple backgrounds on a single
> element.
>  > One of the most basic things to
>  > position elements is to have an outer element with the position:absolute
>  > inside an position:relative element. I don't see how adding an extra
>  > element for CSS Region-flowing is much different.
> The fact that 'position: relative' establishes a containing block has
> led to much abuse. We're trying to not make the same mistakes.

I see, but it's very intuitive to do it that way and it seems to be the way
the web is used.

Johannes Wilm
Fidus Writer
Received on Sunday, 27 October 2013 08:03:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:51:03 UTC