W3C home > Mailing lists > Public > public-css-archive@w3.org > November 2018

Re: [csswg-drafts] [css-break-3] Should 'break-before' / 'break-after' have an 'always' value? (#3318)

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Wed, 21 Nov 2018 17:28:09 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-440748394-1542821288-sysbot+gh@w3.org>
The CSS Working Group just discussed `Should 'break-before' / 'break-after' have an 'always' value?`, and agreed to the following:

* `RESOLVED: add 'always' and 'all' to break-before/after where always is on the nearest fragmentationer and all breaks across all fragmentaners`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: Should 'break-before' / 'break-after' have an 'always' value?<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/3318<br>
&lt;dael> fantasai: As emilio and I looked into these aliases we noticed IE impl 'always' which is not in spec. IN earlier revisions there was 'always' but not clear. WE considered breakt hrough all fragementation context or in closest one.<br>
&lt;dael> fantasai: IE treats as alias to page and only works in paged mode<br>
&lt;dael> fantasai: Options: We can define that break-before:always doesn't exist but it looks like usage is high<br>
&lt;dael> fantasai: We define it to exist has 3 options<br>
&lt;dael> fantasai: Alias of Page, Trigger break at inner most fragmentation context, or Trigger to break through all available fragmentation contexts<br>
&lt;dael> fantasai: Those are our options<br>
&lt;dael> fantasai: My preference is if we have this we should break at inner most fragmentation context. That way author working on content can ask for a break at the next thing. That seems most useful when trying to simulate pages.<br>
&lt;bradk> Innermost seems the most sane to me.<br>
&lt;dael> fantasai: Most compat is define as page break. I'm not sure we need that level of compate b/c main difference is if inside a multi-col. In IE you will not trigger any break in a multi-col unless you're printing. So if you're using break in multi-col you'll get really inconsistant results depending on mode.<br>
&lt;rachelandrew> florian: that would be great thanks<br>
&lt;dael> florian: I think last time we talked we agreed main use case was inner most, but also a use case for outermost. We removed b/c needed to name both consistantly. I think we had any/all, but not sure.<br>
&lt;dael> fantasai: Now we have 'always' which needs to be defined in some way<br>
&lt;dael> florian: Always and all and always and any that always pairs best. I think we should get both, but if we have both which name is obvious<br>
&lt;bradk> always|all<br>
&lt;dael> fantasai: I think inner most is most useful, but interested in hearing from rachelandrew and dauwhe<br>
&lt;dael> dauwhe: In ebook people fake pagination with multi-col all the time. Inner sounds like would make sense for us<br>
&lt;dael> florian: If you're not nesting it doesn't make difference where you punch through. If you are nesting I think you'll need both. Like, you're at a chapter break and want to break all context. Or smaller break.<br>
&lt;dael> fantasai: bradk suggests 'always' and 'all'<br>
&lt;dael> florian: I think that's okay<br>
&lt;rachelandrew> always and all sounds good to me<br>
&lt;dael> florian: If we're stuck with always it's reasonable<br>
&lt;dael> fantasai: Rossen would you be willing to change in Edge?<br>
&lt;dael> Rossen: Potentially. Use cases I've heard are compelling and make sense. From impl PoV it's not super hard. more juggling to re-order breaks in the right priority and break as much as needed based on current stack of breaks.<br>
&lt;florian> s/difference where you/difference whether you/<br>
&lt;dael> Rossen: Break through all or just current is similar to things we're doing.<br>
&lt;dael> Rossen: Having heavy hammers of those two, it'll be fine. I don't think from impl PoV this is a huge concern as long as it fits the bill and addresses enough use cases.<br>
&lt;dael> fantasai: I think having 'always' makes it easy for authors. They don't have to think about context, they just want a break. If you want a page break, you can say that specificially.<br>
&lt;dael> Rossen: Wouldn't disagree.<br>
&lt;dael> Rossen: In principle my model for breaking and fragmentation has been ideally one you can declare your own levels and then have your own defined break for that level. It could be a page, a column, and article, and you should expect that's how it happens<br>
&lt;dael> Rossen: Since we're static defining the levels something to punch through is needed.<br>
&lt;dael> Rossen: You'll always have cases where they say punch through everything except this one. Hoping to not have to discuss that.<br>
&lt;dael> florian: Might need that with region or region-like things. But it's just a maybe. If we do it's not hard, but hopefully unneeded complexity<br>
&lt;dael> Rossen: I see last proposal was break-before/after: always | any | first<br>
&lt;myles> Rossen: if you have columns inside pages, how do you force a page break without forcing a column break?<br>
&lt;dael> fantasai: Always and all, always is nearest<br>
&lt;dael> Rossen: All is a superset of always<br>
&lt;dael> fantasai: always means you always get the minorest amount of break<br>
&lt;dael> Rossen: All implies always everywhere<br>
&lt;dael> fantasai: umhum<br>
&lt;bradk> always break right here, or always break all levels.<br>
&lt;dael> Rossen: What do others think?<br>
&lt;myles> just making the face at the wordplay<br>
&lt;dael> Rossen: myles are you unhappy or borderline happy?<br>
&lt;myles> "all implies always everywhere"<br>
&lt;dael> Rossen: Objections to adding 'always' and 'all' to break-before/after where always is on the nearest fragmentationer and all breaks across all fragmentaners<br>
&lt;dael> RESOLVED: add 'always' and 'all' to break-before/after where always is on the nearest fragmentationer and all breaks across all fragmentaners<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3318#issuecomment-440748394 using your GitHub account
Received on Wednesday, 21 November 2018 17:28:15 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:39 UTC