Re: [csswg-drafts] [css-break-4] Should fragmentation of block-level replaced-elements be configurable? ("object-slice") (#3404)

The CSS Working Group just discussed `Should fragmentation of block-level replaced-elements be configurable? (“object-slice”)`, and agreed to the following:

* `RESOLVED: add "break-inside: allow" to enable slicing of images even if they could fit in the next page`

<details><summary>The full IRC log of that discussion</summary>
&lt;Rossen_> Topic: Should fragmentation of block-level replaced-elements be configurable? (“object-slice”)<br>
&lt;Rossen_> github: https://github.com/w3c/csswg-drafts/issues/3404<br>
&lt;fremy> fantasai: the issue is that, for replaced elements, we can't control whether they are breaking or not<br>
&lt;fremy> fantasai: we would like to add a control to say "hey, even if you could avoid slicing, you don't need to"<br>
&lt;fremy> fantasai: the proposal would be to add a new property for this<br>
&lt;fremy> fantasai: I would rather add a value for break-inside<br>
&lt;fremy> fantasai: then if you add "allow" then we trigger this behavior<br>
&lt;fremy> fantasai: auto is avoid for replaced and allow for non-replaced<br>
&lt;fremy> fantasai: in the future, we can also add "never" which is not like "avoid" because it doesn't even slice, it justs get clipped<br>
&lt;Rossen_> q<br>
&lt;fremy> fantasai:  this should be a different issue though, let;s walk back<br>
&lt;fremy> fantasai: I would like to propose "break-inside: allow" that would enable to slice a replaced element<br>
&lt;fremy> florian: we should accept this otherwhise what we accepted in the previous issue doesn't make much sense<br>
&lt;fremy> florian: so I am in support<br>
&lt;fremy> Rossen_: any other thoughts?<br>
&lt;fremy> Rossen_: hearing no other remark, let's call for objections<br>
&lt;fremy> RESOLVED: add "break-inside: allow" to enable slicing of images even if they could fit in the next page<br>
&lt;fremy> fantasai: can we discuss the "never" value?<br>
&lt;fremy> fantasai: I would like to suggest taking this here<br>
&lt;fremy> fantasai: we add "never" which prevent slicing if slicing would be necessary, and then we just clip<br>
&lt;fremy> fantasai: it's fine because it's an opt-in<br>
&lt;fremy> Rossen_: do we want to resolve this now?<br>
&lt;fremy> Rossen_: the name "never" seems a bit too strong<br>
&lt;fremy> florian: that's not the meaning of never we want here<br>
&lt;fremy> fantasai: we just overflow and clip<br>
&lt;fremy> myles: the last issue we said the reverse<br>
&lt;fremy> florian: yes, that is the 'avoid' behavior<br>
&lt;fremy> florian: the proposal is to add a new behavior<br>
&lt;fremy> JonathanNeal: but you have to print it right?<br>
&lt;fremy> JonathanNeal: engines don't slice an image now<br>
&lt;fantasai> s/JonathanNeal/faceless2/<br>
&lt;fantasai> s/JonathanNeal/faceless2/<br>
&lt;fremy> fantasai: I am pretty sure it's not true<br>
&lt;fremy> fantasai: avoid allows to slice across pages as a last resolt<br>
&lt;jfkthame> +1 to florian<br>
&lt;fremy> florian: this proposal is to disallow that<br>
&lt;fremy> Rossen_: the name confused me<br>
&lt;fremy> Rossen_: but this could be lack of caffeine<br>
&lt;fremy> Rossen_: do we really want to take this now?<br>
&lt;fremy> Rossen_: it's a break 4 thing, let's maybe open a new issue<br>
&lt;fremy> Rossen_: unless fantasai you feel strongly we should resolve now<br>
&lt;fremy> fantasai: no we don't need to, but it would be nice<br>
&lt;fremy> Rossen_: and the resolution we just took covers that no?<br>
&lt;fremy> fantasai: no it's a different behavior<br>
&lt;myles> q+<br>
&lt;fremy> Rossen_: ok, let's resolve on keep working on this<br>
&lt;fremy> Rossen_: but with keyword tbd<br>
&lt;Rossen_> ack myles<br>
&lt;fremy> myles: reading through the thread, one of the issue is that there are no example use cases<br>
&lt;fremy> myles: and I think it would be useful to have them, because we could hit cases<br>
&lt;fremy> myles: like what you can fit in the first column would be 1px<br>
&lt;fantasai> s/behavior/behavior. We discussed allowing things to break without avoidance, that currently avoid breaking (by moving to a next page first). The other option discussing now is to forbid breaking./<br>
&lt;fremy> myles: so we should think about this more<br>
&lt;fremy> Rossen_: the way I'm perceiving this is very similar to ink-overflow, it's just decorative like it's an image but it works like a shadow or something<br>
&lt;fremy> Rossen_: I need that decoration to take some space, but when printing I don't care about it<br>
&lt;fremy> Rossen_: at least that's what I understood<br>
&lt;fremy> Rossen_: but I don't know how frequently this is needed<br>
&lt;fremy> florian: if that's the use case, you don't need that behavior<br>
&lt;fremy> florian: because you don't want to push if possible to the next page<br>
&lt;fremy> myles: yes, in this case, you don't want the decoration at the top of the next column<br>
&lt;fremy> myles: so this is not what we described there<br>
&lt;fremy> florian: ok, let's open a new issue to review use cases<br>
&lt;fremy> Rossen_: let's move to the next issue<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3404#issuecomment-715438832 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 23 October 2020 16:16:05 UTC