Re: [csswg-drafts] [css-break] Specify that ink overflow doesn't fragment? (#4099)

The CSS Working Group just discussed `Specify that ink overflow doesn't fragment?`, and agreed to the following:

* `RESOLVED: ink overflow does not cause new fragments to exist, and does not fragment`

<details><summary>The full IRC log of that discussion</summary>
&lt;Rossen_> Topic: Specify that ink overflow doesn't fragment?<br>
&lt;astearns> github: https://github.com/w3c/csswg-drafts/issues/4099<br>
&lt;fremy> fantasai: we don't specify if ink-overflow gets paginated or not<br>
&lt;fremy> fantasai: I think we should say it does not<br>
&lt;fremy> fantasai: that's my proposal<br>
&lt;astearns> +1 from me<br>
&lt;fremy> Rossen_: that sounds like a reasonable resolution indeed<br>
&lt;jfkthame> +1<br>
&lt;fremy> myles: if it doesn't cause scrollbars it shouldn't cause new pages<br>
&lt;fremy> fantasai: that was my reasoning<br>
&lt;fremy> Rossen_: ok, any objection?<br>
&lt;fremy> smfr: also box-shadow?<br>
&lt;fremy> fantasai: yes<br>
&lt;fremy> fantasai: you should render it if that works<br>
&lt;fremy> fantasai: but it should not generate a page if that's the only thing<br>
&lt;fantasai> s/you should render it if that works/if it renders across adjacent columns, that's fine/<br>
&lt;fremy> Rossen_: so if the box shadow is long, and it goes beyond the end of the page<br>
&lt;fremy> Rossen_: then we don't create a page for that shadow<br>
&lt;fantasai> s/but it should not generate a page if that's the only thing/but it should not fragment in the fragmentation direction/<br>
&lt;fremy> Rossen_: but if there is content that generate the page, then we don't drop the shadow<br>
&lt;fremy> smfr: yes, both cases were things I considered<br>
&lt;fremy> florian: ink overflow does not cause new fragmentainers to exist<br>
&lt;fremy> florian: I don't think we have reached consensus on the first question if the fragmentainer exists anyway<br>
&lt;fremy> fantasai: there are things you don't want to slice though<br>
&lt;Rossen_> q?<br>
&lt;fantasai> s/there/these/<br>
&lt;jensimmons> q+<br>
&lt;fremy> fantasai: so if the things that generate the shadow is in two fragmentainers, you get it in both places<br>
&lt;fantasai> s/though/though, such as parts of glyphs that are outside the bounding box/<br>
&lt;astearns> I agree with fantasai on where ink overflow should get rendered<br>
&lt;fremy> fantasai: but if there is no reason to draw it because the item itself doesn't fragment, then you don't draw it<br>
&lt;fremy> Rossen_: we can split in two resolutions<br>
&lt;fremy> Rossen_: the first one is mature<br>
&lt;fremy> Rossen_: whether or not you create a new fragment<br>
&lt;fremy> Rossen_: depends on content<br>
&lt;fremy> Rossen_: and ink overflow does not cause the creation of a new fragment<br>
&lt;fremy> fantasai: what I want to define is that you don't fragment ink overflow<br>
&lt;fremy> Rossen_: that would be the combination of the two resolutions<br>
&lt;faceless2> +1 to Elika's proposal.<br>
&lt;fantasai> s/ink overflow/ink overflow. Neither can it cause new fragmentainers, nor can it be sliced across them if they exist/<br>
&lt;fremy> jensimmons: something I have seen is that the shadow sometimes appear at the top of the next column and it's weird<br>
&lt;fremy> iank_: we consider that a bug indeed<br>
&lt;fremy> Rossen_: let's try to take the super resolution<br>
&lt;fremy> Rossen_: the ink overflow does not cause new fragments to exist, and does not fragment<br>
&lt;fremy> RESOLVED: ink overflow does not cause new fragments to exist, and does not fragment<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4099#issuecomment-715424499 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 15:49:28 UTC