W3C home > Mailing lists > Public > public-css-archive@w3.org > October 2020

Re: [csswg-drafts] [css-break-4] orphans and widows for fragmented monolithic replaced elements (#3405)

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Fri, 23 Oct 2020 16:02:56 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-715431908-1603468975-sysbot+gh@w3.org>
The CSS Working Group just discussed `orphans and widows for fragmented monolithic replaced elements`, and agreed to the following:

* `RESOLVED: work on a mechanism to control where slicing is allowed as a length from either side of the monolithic element`

<details><summary>The full IRC log of that discussion</summary>
&lt;Rossen_> Topic: orphans and widows for fragmented monolithic replaced elements<br>
&lt;Rossen_> github: https://github.com/w3c/csswg-drafts/issues/3405<br>
&lt;fremy> fantasai: this is a feature request for fragmentation level 4<br>
&lt;fremy> fantasai: it would be nice to control widow/orphan in a more monolithic way<br>
&lt;fremy> fantasai: it would be a length instead<br>
&lt;fremy> fantasai: and thus cannot inherit so we need a new property<br>
&lt;fremy> fantasai: it would say how much space you need on the page to accept to start flushing in the container<br>
&lt;florian> q+<br>
&lt;jensimmons> q-<br>
&lt;Rossen_> ack jensimmons<br>
&lt;fremy> fantasai: proposal would be widow-length or something<br>
&lt;fremy> faceless2: I don't think the name should be widow/orphan its a different concept<br>
&lt;fantasai> s/widow-length/widow-something: &lt;length>/<br>
&lt;Rossen_> ack florian<br>
&lt;fremy> florian: maybe I misrember but I think we are not supposed to split monolithic elements at all<br>
&lt;fremy> florian: so the default value should be 100% right?<br>
&lt;Rossen_> q?<br>
&lt;fremy> florian: (split only happens if you cannot fit)<br>
&lt;fremy> fantasai: we want to control that<br>
&lt;fremy> fantasai: and that is the next issue<br>
&lt;fremy> florian: why a different toggle?<br>
&lt;fremy> florian: if you have 100%<br>
&lt;myles> q+<br>
&lt;fremy> fantasai: yes, but break-inside is more reasonable to find for authors<br>
&lt;fremy> florian: yes, that's true<br>
&lt;fremy> Rossen_: are we discussing accepting the proposal?<br>
&lt;fremy> myles: is my understanding correct to say that they don'<br>
&lt;fremy> myles: t like when 3px of their image appears at the end of a page<br>
&lt;fremy> myles: and the rest gets displayed on the next page?<br>
&lt;fremy> fantasai: yes<br>
&lt;fremy> myles: ok<br>
&lt;Rossen_> q?<br>
&lt;fremy> Rossen_: any other thought?<br>
&lt;Rossen_> ack myles<br>
&lt;fremy> florian: I am not sure it's a different than the break-inside thing<br>
&lt;jfkthame> q+<br>
&lt;fremy> florian: for example on some images there might be only three points where you want to break<br>
&lt;tantek> interesting, the image breaking equivalent of soft-hypens<br>
&lt;fremy> Rossen_: is that a reason to hold off on the proposal?<br>
&lt;fremy> florian: I think it's weird to have a toggle for something<br>
&lt;fremy> florian: that we can't do yet<br>
&lt;Rossen_> ack jfkthame<br>
&lt;fremy> fantasai: we slice if it doesnt fit<br>
&lt;fremy> florian: but we might want different if it is forced or not<br>
&lt;myles> q+<br>
&lt;fremy> JonathanNeal: seems to be refinements of break-inside to me<br>
&lt;florian> +1 to jfkthame<br>
&lt;fremy> JonathanNeal: so sub-properties of break-inside<br>
&lt;Rossen_> ack fantasai<br>
&lt;faceless2> q+<br>
&lt;fremy> fantasai: we don't control where you can break in break-inside<br>
&lt;fremy> fantasai: break-inside, so far, is only whether you can break or not<br>
&lt;Rossen_> ack myles<br>
&lt;fremy> fantasai: I think this is a good separation to have<br>
&lt;fremy> myles: also, there are two values, bottom and top<br>
&lt;fremy> myles: if the sum is bigger than 100%, what happens?<br>
&lt;fremy> fantasai: can't break anywhere<br>
&lt;Rossen_> q?<br>
&lt;faceless2> q-<br>
&lt;fremy> florian: but then you are back to the case where you have to differentiate whether you are in the normal case or the error case<br>
&lt;fremy> fantasai: if needed you slice wherever<br>
&lt;fremy> myles: in the case I described, we would not slice though, right?<br>
&lt;fremy> fantasai: you slice<br>
&lt;fremy> myles: I am confused<br>
&lt;fremy> myles: let me restate<br>
&lt;myles> you have an image that's 100px tall<br>
&lt;Rossen_> q?<br>
&lt;myles> the fragmentainer is 75px tall<br>
&lt;myles> and you use both of these properties to say "don't break within 80px of the top and don't break within 80px of the bottom"<br>
&lt;myles> &lt;fin><br>
&lt;myles> this would overflow, right?<br>
&lt;fremy> Rossen_: (btw we only try to decide if we want to work on this, don't need to have all the details nailed in)<br>
&lt;fremy> fantasai: several things happen<br>
&lt;fremy> fantasai: let's start with 120px fragmentainer<br>
&lt;fremy> fantasai: in that case, we move the image to the next fragmentainer<br>
&lt;fremy> fantasai: now, if the fragmentainer is smaller<br>
&lt;fremy> fantasai: we are going to ignore the restrictions<br>
&lt;fremy> fantasai: so we do slice at 75px<br>
&lt;fremy> fantasai: though in theory, the ua is allowed to break anywhere<br>
&lt;fremy> fantasai: there is a further proposal to add toggles for this, but this would remain an opt-in<br>
&lt;fremy> fantasai: by default we make sure all the content is rendered<br>
&lt;fremy> myles: got it<br>
&lt;fremy> Rossen_: so, do we feel we want to pursue this?<br>
&lt;fremy> Rossen_: and add to break-4<br>
&lt;fremy> Rossen_: any objection?<br>
&lt;fremy> RESOLVED: work on a mechanism to control where slicing is allowed as a length from either side of the monolithic element<br>
</details>


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

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:21 UTC