Re: [css3-page] comments on last ED

On 20/02/13 14:09, Håkon Wium Lie wrote:

> Most publications need more than the six option you mention. Here's a picture
> of the first three publications I grabbed from my shelf:
>
>     http://people.opera.com/howcome/2013/tests/css3/samples.jpg
>

Error 404.

> In other common publications, like Lonely Planet books or The
> Economist and you will find more examples.
>
>   >    Furthermore, the specification does not say how the
>   >    settings in that dialog set/conflict/collide/override the ones in
>   >    the stylesheets attached to the printed document. I think that is a
>   >    concern.
>
> The specification should not say anything about dialog boxes. But
> implementation may regard settings from UI dialogs as part of the user
> (or browser) style sheet. So it has its place in the cascade and
> therefore a formal model for resolving conflicts.
>
>   >    The 16 boxes are a mix of flows, flexing, tables and grids. We have
>   >    now better on the radar in the CSS WG. I understand Paged Media 3
>   >    has to be published because there are already implementations in the
>   >    wild, but this is sooooo 2002...
>
> In your preferred solution, how would you express this?:
>
>     @page { @top-center { content: element(header) }}
>     @page :left { @top-left { content: counter(page) }}
>     @page :right { @top-right { content: counter(page) }}
>     header { position: running(header) }

I already said named flows don't do that right now but are easy
to extend to do it, you read too fast.

> One leading publisher, Hachette, uses CSS to print and publish
> hundreds of books on paper every year. Here's a presentation
> describing their setup:
>
>     http://infogridpacific.typepad.com/files/idpf-2012-cramer-smaller.pdf
>
> Naturally, they depend on css3-page, margin boxes and statements like
> the above to achieve this

The CSS WG is not responsible if vendors implement unstabilized features
and if users of these vendors use the features. It says nothing about
the quality of the solution they're using. It only says they use it.
Good for YesLogic and AntennaHouse who shipped experimental features
to the masses, bad for the W3C Process, something you should care about,
right?

> And implementations. Here's a test page for margin boxes along with
> output from three formatters:that
>
>    http://people.opera.com/howcome/2013/tests/css3-page/page-margins.html
>    http://people.opera.com/howcome/2013/tests/css3-page/antennahouse.pdf
>    http://people.opera.com/howcome/2013/tests/css3-page/prince.pdf
>    http://people.opera.com/howcome/2013/tests/css3-page/weasyprint.pdf
>
> Antennahouse and Prince are interoperable. Weasyprint almost so.
>
> Given all this, I think it should be a priority for the WG to advance
> the currently described functionality to REC.

With navigation (out of scope wrt Charter), exclusions (collision with
a chartered document), regions (collision with a chartered document),
footnotes (relying on magic), bookmarks (underspecified) and more?
You're serious Håkon? Clean up your draft first, I mean make it a
real WD of what is *implemented* and you want to take to REC and
strip the kitchen sink/L4 items and we'll see.
If I take the part of GCPM that is implemented AND has been stable in
the recent years, we go down to 8 or 9 sections in the document. That's
11 to strip, Håkon... Do that and we'll discuss the priority in the WG
but don't use the fact a part of the document is interoperably
implemented to push the others that are not, thanks. I'm not that
naive.


</Daniel>

Received on Wednesday, 20 February 2013 13:55:30 UTC