Re: [csswg-drafts] [css-masking] Not clear how clip-path applies to fragmented elements (#6383)

The CSS Working Group just discussed `Fragmented elements with clip-path`, and agreed to the following:

* `RESOLVED: masking should follow same rules as backgrounds with regards to box-decoration-break`
* `RESOLVED: clip-path and masking should follow same rules as backgrounds with regards to box-decoration-break`

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> Topic: Fragmented elements with clip-path<br>
&lt;fantasai> github: https://github.com/w3c/csswg-drafts/issues/6383<br>
&lt;dael> scribenick: dael<br>
&lt;dael> heycam: There's nothing in the css masking spec that says how clippath interacts with box decoration<br>
&lt;dael> heycam: slight reference to rbeak in section for mask image that implies it applies to masks on fragmented elements<br>
&lt;dael> heycam: Did some testing with clip-path and found safari, ff, and chrome different<br>
&lt;dael> heycam: What I would expect is similar to what happens to borders where if you have bo-decoration break slice you would slice up the clip and apply with different offsets<br>
&lt;dael> heycam: break clone evlauate size and position differently for each fragment<br>
&lt;fantasai> +1 to honoring box-decoration-break as heycam described<br>
&lt;dael> heycam: FF and Chrome similar in that they apply the clip=path computed based on one fragement, but using different elements. WK computes bounding box of all and evaluate clip-path.<br>
&lt;dael> heycam: I think none are exactly what we want<br>
&lt;dael> heycam: Wanted to see if you think it's reasonable or if clip-paths are different enough<br>
&lt;dael> fantasai: Agree with matching to way backgrounds and borders are handled. Makes a lot of sense<br>
&lt;dael> astearns: Seeing head nodding<br>
&lt;dael> florian: Agree. If in long run need to distinguish we could add longhands<br>
&lt;dael> iank_: Note that you don't need fragmenetation to trigger. Inline like a span with a clip-path triggers this<br>
&lt;dael> fantasai: That's still fragmenetation.<br>
&lt;dael> iank_: Sure<br>
&lt;dael> astearns: Hearing consensus. Anyone against?<br>
&lt;dael> chrishtr: iank_ do you have believe if this has impact on fragmeenation in [missed] architecture?<br>
&lt;dael> heycam: Basically behavrio is same as box-decoration break. If you have box-decoration-break slice you compute box for unfragmented thing and slice clip-path and apply separately<br>
&lt;dael> iank_: What happens if you have a fragment that is varying width...this is the problem in...case is inline when you have a fragmeneted span. span can have different heights. What happens there?<br>
&lt;dael> heycam: What happens with backgrounds?<br>
&lt;dael> fantasai: Spans don't have different heights on different lines b/c set by first available font<br>
&lt;dael> fantasai: As far as backgrounds and block level fragmentation it's defined in break. You recalc your size on each fragment. Maintain a concept of proress through element<br>
&lt;fantasai> https://www.w3.org/TR/css-break-3/#varying-size-boxes<br>
&lt;fantasai> s/proress/progress/<br>
&lt;dael> astearns: Background is sliced...compute for unfragmented and then you slice it up. First fragment ends up shorter does the bg resize per fragment after slicing?<br>
&lt;chrishtr> q+<br>
&lt;dael> fantasai: For slicing you do layout first. Then you assemble it. You've accounted for the spacing. You have an oval clip-rect. You do the fragmenetion, layout, and then draw background around that<br>
&lt;astearns> ack fantasai<br>
&lt;dael> fantasai: It's not that you  layout as if there was no fragmenation. That would be different spacing<br>
&lt;astearns> ack chrishtr<br>
&lt;dael> chrishtr: Does the same problem, heycam , apply to other visual effects? masking, filters, and so on?<br>
&lt;dael> heycam: Masking and clipping seem they should do the same. Filters I had no considered<br>
&lt;dael> heycam: Gut feeling is that filters feel a little more different and it's not so obvious we should apply same rules. Maybe not the case<br>
&lt;dael> chrishtr: alisonmaher thoughts?<br>
&lt;dael> alisonmaher: I didn't work too much with this part of fragmentation. Keeping consistent feels like it would make sense<br>
&lt;dael> astearns: Sounds like there are some complications to work out.<br>
&lt;dael> astearns: General conensus that masking should follow same as backgrounds with regards to box-decoration-break<br>
&lt;dael> astearns: Anyone obj to trying this out?<br>
&lt;dael> RESOLVED: masking should follow same rules as backgrounds with regards to box-decoration-break<br>
&lt;dael> astearns: Definitely clip-path. Masking should be the same<br>
&lt;dael> RESOLVED: clip-path and masking should follow same rules as backgrounds with regards to box-decoration-break<br>
&lt;dael> astearns: We can think on filters separately. Might be better to try and reasond for clip-path and see if it would work first<br>
</details>


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


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

Received on Wednesday, 3 November 2021 22:28:38 UTC