w3c / csswg-drafts

CSS Working Group Editor Drafts
https://drafts.csswg.org/
Other
4.49k stars 660 forks source link

[css-masking] Not clear how clip-path applies to fragmented elements #6383

Open heycam opened 3 years ago

heycam commented 3 years ago

https://drafts.fxtf.org/css-masking-1/#the-clip-path

I don't see anything in the CSS Masking spec that defines how clip-path interacts with box-decoration-break, or more broadly how multiple fragments influence the clipping that's applied. My expectation is that it would work like masks, where the reference box (specified in the clip-path property, unlike for masks where it's in mask-origin) is either computed separately for each fragment (when box-decoration-break is slice) or once over a hypothetical unfragmented box (when box-decoration-break is clone).

There's a very brief reference to box-decoration-break in https://drafts.fxtf.org/css-masking-1/#mask-positioning-area but nothing similar for clip-path.

Here's a test that doesn't have interop:

Screen Shot 2021-06-15 at 2 29 24 pm Screen Shot 2021-06-15 at 2 29 46 pm Screen Shot 2021-06-15 at 2 30 04 pm

The way I guess it should work is:

heycam commented 3 years ago

i.e. it should look like this:

Screen Shot 2021-06-15 at 2 38 16 pm
css-meeting-bot commented 2 years ago

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

The full IRC log of that discussion <fantasai> Topic: Fragmented elements with clip-path
<fantasai> github: https://github.com/w3c/csswg-drafts/issues/6383
<dael> scribenick: dael
<dael> heycam: There's nothing in the css masking spec that says how clippath interacts with box decoration
<dael> heycam: slight reference to rbeak in section for mask image that implies it applies to masks on fragmented elements
<dael> heycam: Did some testing with clip-path and found safari, ff, and chrome different
<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
<dael> heycam: break clone evlauate size and position differently for each fragment
<fantasai> +1 to honoring box-decoration-break as heycam described
<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.
<dael> heycam: I think none are exactly what we want
<dael> heycam: Wanted to see if you think it's reasonable or if clip-paths are different enough
<dael> fantasai: Agree with matching to way backgrounds and borders are handled. Makes a lot of sense
<dael> astearns: Seeing head nodding
<dael> florian: Agree. If in long run need to distinguish we could add longhands
<dael> iank_: Note that you don't need fragmenetation to trigger. Inline like a span with a clip-path triggers this
<dael> fantasai: That's still fragmenetation.
<dael> iank_: Sure
<dael> astearns: Hearing consensus. Anyone against?
<dael> chrishtr: iank_ do you have believe if this has impact on fragmeenation in [missed] architecture?
<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
<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?
<dael> heycam: What happens with backgrounds?
<dael> fantasai: Spans don't have different heights on different lines b/c set by first available font
<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
<fantasai> https://www.w3.org/TR/css-break-3/#varying-size-boxes
<fantasai> s/proress/progress/
<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?
<chrishtr> q+
<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
<astearns> ack fantasai
<dael> fantasai: It's not that you layout as if there was no fragmenation. That would be different spacing
<astearns> ack chrishtr
<dael> chrishtr: Does the same problem, heycam , apply to other visual effects? masking, filters, and so on?
<dael> heycam: Masking and clipping seem they should do the same. Filters I had no considered
<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
<dael> chrishtr: alisonmaher thoughts?
<dael> alisonmaher: I didn't work too much with this part of fragmentation. Keeping consistent feels like it would make sense
<dael> astearns: Sounds like there are some complications to work out.
<dael> astearns: General conensus that masking should follow same as backgrounds with regards to box-decoration-break
<dael> astearns: Anyone obj to trying this out?
<dael> RESOLVED: masking should follow same rules as backgrounds with regards to box-decoration-break
<dael> astearns: Definitely clip-path. Masking should be the same
<dael> RESOLVED: clip-path and masking should follow same rules as backgrounds with regards to box-decoration-break
<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