Re: [css3-break] page-break-* and break-* aliasing

On 08/11/2012 12:11 AM, MURAKAMI Shinyu wrote:
> fantasai<fantasai.lists@inkedblade.net>  wrote on 2012/08/08 10:38:08
>>
>> Florian's full writeup, explaining various alternatives and their impacts,
>> is available at
>>     http://wiki.csswg.org/ideas/aliasing
>> The proposal in question is the last one: Shorthand/Longhand Take 2. I've
>> added it to the editor's draft here:
>>     http://dev.w3.org/csswg/css3-break/#page-break
>
> I am ok with this approach. It is nice the shorthand
> 'page-break-*: always' → longhand 'break-*: page' mapping.
> But I think it is not very good the shorthand
> 'page-break-*: avoid'  →  longhand 'break-*: avoid-page' mapping.
> I think  the shorthand 'page-break-*: avoid'  →  longhand 'break-*: avoid'
> is better, because in most cases when we need to avoid page break
> we also need to avoid column or region break.
>
> For example, headings (h1-h6) usually have 'page-break-after: avoid'
> settings in existing stylesheets, and when they are used in multi-column or
> multi-region context, we expect that column/region breaks are also avoided.
>
> [...] I want XSL-FO and CSS properties with same names are compatible.

Thanks for your review, Murakami-san.
I've updated the Editor's Draft, and will bring up your points when
I introduce this topic later this week. :)

> I have one more question. I think the value 'always' and 'avoid' are
> not necessary for page-* properties, because 'always' should be same as
> 'column' and 'avoid' should be same as 'avoid-column'.
> (if not in multi-column context, a column break is a region break, and
> if not in multi-region context, a region break is a page break)
> Is this understanding wrong?

Well, we can't remove 'page-break' values, because they're in CSS2.1.
And since column breaks and region breaks are not always the same thing
(you can have a single region with multiple columns, or multiple regions
within a column), 'column' and 'always' or 'avoid' and 'avoid-column'
are not the same.

> BTW, I think this is a editorial error that recto and verso values are missing in the break-before value definition:

Ah, yes. Fixed. :)

~fantasai

Received on Monday, 13 August 2012 00:50:40 UTC