- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 07 May 2020 23:39:36 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `#4934 Add contain-paint-margin CSS property`, and agreed to the following: * `RESOLVED: Add ink-skip-clip-margin property (name tbd) with non-negative values` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: #4934 Add contain-paint-margin CSS property<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/4934<br> <dael> chrishtr: Purpose is to apply a clip so the ink overflow does not exceed it. Allows UA to detect that it's offscreen so don't have to paint. THis property allows dev to have a margin to expand the clip. In case devs have certain amount of ink overflow b/c useful for layout like shadows ot flourishes<br> <florian> q+<br> <Rossen_> ack<br> <Rossen_> ack f<br> <dael> florian: Additional use case is outline and accessibility purposes. If the outline would be in screen and rest wouldn't you might want to see. Optimizations can work if you just expand boundary of rectangle a bit. If it works, why not<br> <dael> fantasai: Is contain:paint containing paint of elemet or contents?<br> <dael> florian: both<br> <dael> fantasai: Seems weird. Mostly cotnain is about contents. Why would you clip box shadows?<br> <smfr> q+<br> <Rossen_> ack fantasai<br> <dael> TabAtkins: Containing layout is one thing b/c elements own layout won't extend but children can so it's fine. But box shadows can be arbitrarily far away so if you only clip children you still have to look at element, compute styles,a nd car about paint.<br> <dael> fantasai: For to do it anyway so you know where it is<br> <dholbert> q+<br> <dael> florian: Element yes, but the paint. If you have containment you can say it's offscreen so stop. not check if there's a shadow and maybe compute that<br> <dael> AmeliaBR: Also when having element on its own layer how big is it an reserving memory for animations and whatnot<br> <Rossen_> ack smfr<br> <dael> smfr: I think I would understand better if desc how data goes into compositor. Is it knowing when overlap?<br> <dael> chrishtr: Reducing size of textures is an optimization. Motivation is allow dev to benefit without being strict about clipping to size of element.<br> <TabAtkins> This is basically exactly analogous to the filter margin concept for SVG filters<br> <dael> florian: fantasai point about just for children doesn't change problem. Could have 0 padding 0 border div around something with a shadow and same problem<br> <Rossen_> ack dholbert<br> <dael> dholbert: Similar to shape marging property but that rounds at corners. IS that what we're intending?<br> <dael> TabAtkins: SHouldn't be necessary. Just extending rectangular box<br> <Rossen_> ack fantasai<br> <Zakim> fantasai, you wanted to suggest auto initial value<br> <dholbert> s/shape marging/shape-margin/<br> <dael> fantasai: I'm still skeptical about definition. Would it make sense to have auto that calc things like default outline width or outset of border image or poss ignoring blur radius box shadow distance<br> <dael> florian: Possibly. We have a bunch of cases where win of optimization is real but small. If you have a bunch of checks before it defets optimization<br> <dael> fantasai: It's auto. You don't do every time you paint optimize. You look at 3 properties and calc outsets<br> <dael> AmeliaBR: Animating shadow<br> <dael> fantasai: If you have auto on contain paint that's aniumated<br> <dael> chrishtr: But has to be cached and that's a cost. It also doesn't solve content in subtree issue<br> <TabAtkins> Back on the last discussion, btw, Sass defines *both* `@if`/`@else` at-rules, *and* an `if(bool, val1, val2)` function, so yeah, it's got conditionals on both rule-level and value-level.<br> <dael> florian: If you do width of outline you wouldn't on child of element that's adjacent so only partly helping.<br> <dael> fantasai: Having arbitrary clip of what's doing containment is weird<br> <dael> AmeliaBR: Is the concern default is too strict? Could give a default of something like margin 16px. Default you assume a little overflow.<br> <dael> fantasai: Maybe. Havign a typical box shadow or border image get clipped when you contain paint seems weird<br> <dael> fantasai: Understand about clipping children. but clip box itself<br> <dael> dholbert: That's not what happens in FF or Chrome. We clip descendants to padding box<br> <Rossen_> q<br> <dael> TabAtkins: You should clip box shadow, not border<br> <fantasai> s/itself/itself is weird/<br> <dael> florian: I misspoke earlier. Spec says content of element incl paint of descendants must be clipped. Border is not content so what fantasai wants is what spec says. If it should is another question, but we're not spec you must clip<br> <dael> fantasai: sgtm<br> <dael> Rossen_: Would adding this property address the issues you're aware of chrishtr?<br> <dael> chrishtr: yes. Adding contain-paint:marging is<br> <dael> florian: You still want this in light of me misunderstanding?<br> <dael> chrishtr: Yeah, I came into it with that believe<br> <dael> fantasai: I'm okay with it.<br> <dholbert> I tested box-shadow, and indeed it's not clipped.<br> <dael> Rossen_: Obj to adding contain-paint amrgin property to contain paint?<br> <dholbert> My testcase (shadow isn't clipped in Firefox or in Chrome): data:text/html,<div style="border: 3px solid black; box-shadow: 50px 50px black; contain:paint; height: 10px; ">abc<br> <dael> florian: No objection. We looked at non-0 initial value so with this understanding lets have default be 0<br> <dael> chrishtr: Can set to non-0<br> <dael> smfr: Cna you set negative?<br> <dael> chrishtr: Good question. Not sure there's a purpose<br> <dael> smfr: Should it clamp?<br> <dael> florian: Yeah...<br> <dholbert> shape-margin definition, for reference: https://drafts.csswg.org/css-shapes-1/#propdef-shape-margin<br> <dael> Rossen_: When we discussed in context of shape outside resolution was easy that you want to have shape margin be non-camppped so you can pull content under<br> <dael> florian: Yes, but this is a lot weirder.<br> <dael> Rossen_: Should we clip to non-negative<br> <dael> florian: I think so<br> <dael> fantasai: Start and expand<br> <dael> cbiesinger: I think you want clamp not error<br> <astearns> +1 to fantasai<br> <dael> fantasai: Yeah<br> <cbiesinger> s/clamp not error/error not clamp/<br> <dael> florian: One number or one or two or three or four numbers?<br> <dael> smfr: Same as margin t/r/b/l<br> <dael> smfr: Do adjacent paint margins collapse?<br> <dael> fantasai: no<br> <dael> smfr: It has margin in the name and it makes me concerned<br> <dael> florian: adjacent margin collapsing has no meaning<br> <dael> smfr: SHould it have margin in name or call it outset?<br> <dael> fantasai: We always have scroll-snap-margin so there's precedent<br> <dael> smfr: okay<br> <dael> TabAtkins: and filter-marking in svg<br> <dael> Rossen_: Objections to adding?<br> <TabAtkins> s/marking/margin/<br> <dael> fantasai: Scope question<br> <dael> fantasai: Makes sense to have it overact with overflow clip?<br> <dael> fantasai: Why not operate on overflow clip so maybe more generica name<br> <dael> dholbert: THen same behavior as overflow scroll<br> <dael> fantasai: hidden, auto,a nd ascroll are different. Overflow clip is different.<br> <dael> dholbert: Yeah, if defined in terms of overflow-clip it would have to<br> <dael> chrishtr: If it's a paint thing that's fine<br> <dael> fantasai: And useful if people don't want full containment<br> <dael> florian: clip-margin?<br> <dael> dholbert: Don't love the name. Clips to a margin is what it sounds like<br> <dael> AmeliaBR: Or related to clip-path, Yeah. Name to be bikeshed?<br> <dael> AmeliaBR: Need to look more details about complications from overflow-clip<br> <dael> fantasai: I think it's worth looking at things that clip and which should hook in<br> <dael> Rossen_: ink-margin?<br> <dael> fantasai: I don't think that's how people think about it<br> <fantasai> overflow-margin?<br> <dael> florian: Doesn't add margin to ink. Visible ink overflow it doesn't do anything. It's an ink-clip-margin-ish<br> <dael> florian: Bikeshedding to be done<br> <dael> Rossen_: Obj Adding ink-skip-clip-margin property (name tbd) with non-negative values<br> <faceless2_> Sounds like a Dr Seuss plotline<br> <dael> RESOLVED: Add ink-skip-clip-margin property (name tbd) with non-negative values<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4934#issuecomment-625550490 using your GitHub account
Received on Thursday, 7 May 2020 23:39:40 UTC