- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 01 May 2019 23:42:39 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Remove padding-box, content-box values from <shape-box>`, and agreed to the following: * `RESOLVED: no change on this issue` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: Remove padding-box, content-box values from <shape-box><br> <dael> github: https://github.com/w3c/csswg-drafts/issues/3872<br> <dael> iank_: As redoing parts of shapes impl for our layout engine I noticed something that bugged me. I put in use counters. Padding-box and content-box as values on shape outside is weird. If you have scrollable content inside it won't respect scroll bars. Not a strong use case for these values<br> <dael> iank_: Use counter was basically 0.<br> <dael> iank_: Given all this, to simplify can we remove?<br> <dael> Rossen_: Move to L2 or at all?<br> <dael> iank_: Just remove it. I don't know there are strong use cases for these values. Be interested if there are.<br> <dael> amelia: mentioned a few use cases in a comment earlier today. It's matching up shapes with either actual content image of an element. shape-outside can be defined using an image and you use it to match actual content image and you need them to align to correct layout box<br> <dael> amelia: Also aligning...shape-outside shapes with clip-path shapes functions. One issue there is Chrome and poss WK don't support shape boxes on clip-path and default is border-box so if people are using a combo they're almost automatically using border box. That might effect use counter more than anything else.<br> <dael> amelia: Other is matching with background images that can be aligned to many other boxes. Definitely use cases, but need to deal with...there's inside boxes and outside boxes when talking about scroll and that doesn't seem thought of in the spec<br> <dael> amelia: Something needs to change in the spec. I don't think deleting is best b/c then have to deal with that that set of boxes is used in a lot of graphic properties. Also clip-path and shape-inside in the future.<br> <dael> amelia: Getting rid of it all together will prob cause problems with consistency to other properties<br> <dael> iank_: Doesn't sound like...we haven't shipped padding box for clip path<br> <dael> amelia: no<br> <dael> iank_: My primary issue is no one has thought about scrollable boxes. It's also weird for engine caching, this reaches inside internals of the box.<br> <dael> fantasai: I think for dealing with scrollable boxes you would want to, for clip-pathas well, only thing that would make sense is inset it by border edge by amount of border and padding width. Can't draw it around scrollable area<br> <dael> amelia: That's one option. Makes perfect sence. Figure out what padding box would be working from existing box.<br> <dael> amelia: Other option is for scrolling boxes only you make at used value time these values get re-written but still allow content-box and border-box to work on non-scrollers. I like fantasai suggestion better<br> <dael> fantasai: As we switch to incorporate padding into scrollable [gives example]<br> <dael> iank_: Other thing to keep in mind for boxes with scrollers you've got to account for where scrollbars are with is a potential world of pain<br> <dael> iank_: I don't care where we fall on this issue. 9 months ago I found this weird, hence use counters<br> <dael> fantasai: If we hadn't impl it would make sense to drop. Since they are impl i'm ambivellent<br> <dael> iank_: Impl but no usage. I can drop based on that.<br> <fantasai> s/ambivellent/ambivalent/<br> <dael> amelia: Willing to accept this. Going back to Rossen_ question is make them invalid for now and defer to L2 where people can look more carefully about how should impl. If we've got something not impl consistently and we don't agree how and it's not used a lot we should take it out. I don't want to resolve to never support<br> <dael> jensimmons: Do we know if we have interop and complete impl or a lack of interop and confusion what it should be<br> <dael> iank_: Based on amt of WPT there's good interop. Good between Blink and WK because of heritage. Good with FF based on WPT.<br> <dael> amelia: On the things you want to remove?<br> <dael> iank_: Yes. There's well tested I believe. I can check. But that said they have 0 usage<br> <dael> amelia: But if weve got clear interop why is issue to get rid of it? You don't like behavior standardize on?<br> <dael> iank_: Yeah. Behavior is weird for scrollers<br> <dael> amelia: Wrapping around area overflowing the box? I don't have any pictures...<br> <dael> iank_: ake simple impl, apply to scroller and that's what you get.<br> <dael> Rossen_: Going back to original motivation to add them was completeness and symmetry with other prop. That's what motivated us to add them in<br> <dael> Rossen_: Given there's no uptake on the values and a reason to remove from a given impl. In terms of being safe to unship it sounds okay. Technical PoV sounds like we can unship with no negative effect on content.<br> <dael> Rossen_: Question is are we completely uninterested or are we saying we don't know enough but might have reasons to work on it and we push to L2<br> <dael> Rossen_: Where on this spectrum are we? Push to L2 and worry later? Or no use cases and let's move on.<br> <dael> fantasai: amelia point that some things it would work with aren't shipped yet means we won't know potential usage accurately until those are widespread<br> <dael> Rossen_: Push to L2<br> <dael> fantasai: If we have interop and spec and impl there's no reason to move to L2 b/c it would pass REC. If we didn't have impl it would make sense to drop<br> <dael> Rossen_: Sounds like one impl will unship so we won't reach rec without having another impl<br> <dael> florian: Don't we have 3?<br> <dael> Rossen_: 2 only<br> <dael> amelia: WK and Chromium aren't independent is the issue?<br> <dael> iank_: Correct<br> <dael> amelia: Agree playing witht he demo what's happening is not good behavior. If we leave as a valid value we'd want to spec and define better behavior. Considering status of spec I don't think that can really happen in timelines we want.<br> <dael> Rossen_: Yeah<br> <dael> florian: Suggestion is push to L2 with an issue saying there is interop but we want to change?<br> <dael> Rossen_: If it is unshipped from blink there's no interop<br> <dael> amelia: FF and Chrome aren't identical. Both bad, but not interop<br> <dael> Rossen_: Let's see if we can resolve. Objections to move these properties out of L1 and into L2 and add a note about the interop problem?<br> <dael> dbaron: What does that imply impl should do?<br> <dael> florian: [missed] work before usage and then fix it<br> <florian> s/[missed]/rediscuss how it should/<br> <dael> Rossen_: In short term blink is looking into removing their impl. In long term spend more time thinking about how should work in conjunction with scrolling, overflow, etc.<br> <dael> amelia: One thing, if we change definition there will be dependencies beyond this one property.<br> <dael> amelia: Just practical for whoever does edits<br> <dael> amelia: We've got a shape-box type that's equal to set of keywords. Used in more than this one property<br> <dael> Rossen_: Right<br> <dael> jensimmons: For me...I'm not hearing that a browser needs to unship this in order to get through re-engineering of platform. not hearing a compelling reason to remove. AS a person that's taught about this property adjusting the shape-box property is the last thing people think about or learn. Switching from border-box to margin-box makes sense, but makes me nervious to unship.<br> <dael> jensimmons: THat people aren't using it doesn't convince me b/c I think peoplehave not dug into it. I haven't thought of use cases, but makes me nervious<br> <dael> TabAtkins: Shouldn't fall pray to status quo fallicy. Since no one hascome up with reasonable reason to have it in, it's weakly supported at best<br> <dael> dbaron: Sounds like reason to remove isn't that it's complicated, but it's not useful.<br> <dael> dbaron: Could argue using it on a thing with scrollbars is a bad idea. Then it's not that bad that it has wierd results. Clipping a scrollbar is prob not what you wanted. QUestion is are there use cases for non-scroll bar<br> <dael> amelia: That's what I brought up. There are use cases. Simpliest solution from spec is add a warning that using content-box or padding-box on an element with scrollbars has undefined behavior. it's a warning to authors you'll get weird stuff. In non-scrollbar case we've got clear interop. but for the intersection of properties adding a warning behavior is undefined might be quick<br> <dael> TabAtkins: Officially undefined is something we try not to use. All it means is we hope to revisit once web compat has frozen.<br> <dael> TabAtkins: No one has brought up use cases and I can't think of when I'd want text outside to flow into a box past a border<br> <dael> fantasai: WE see this frequently with first letter shapes. You can have a light color bg and want text to flow over and wrap shape of letter. This kind of design does happen<br> <dael> jensimmons: And a lot of ability to overlap with negative margin. You can't do that here.<br> <dael> fantasai: I don't see use case for padding box, but for content-box you have that<br> <dael> iank_: In the wild when people want that they reach for insets to modify<br> <dael> fantasai: If you want to take an image, cut into a circle. You don't want to have to do an inset of your border and padding when you can just say make the circle that covers the content box. Less repeating yourself, less complications. That's what these keywords are for. If want to cut image to a circle, then want text wrap in a circle<br> <dael> TabAtkins: And also have the image have a border and have text overlap?<br> <dael> fantasai: Might not be a circle so yeah. I think it's not the common case, but I don't think it's totally crazy<br> <dael> jensimmons: Interesting question to ask now. If we asked a year ago when there's one impl and the question at the time is this is complicated. But we jsut shipped it all and we've got interop except the corner case of scrollbars, why remove it now? Only reason I'm hearing is it would make things feel better for those reading the code so you don't have to drag around extra code. I get that as an engineer, but not compelling to change a spec<br> <dael> TabAtkins: Trying to ignore scrollbar doesn't work, we still need interop. People will have to add code to handle it. It's not a matter of leave it alone, someone will have to pay additional cost to get it right. Then there's the non-0 matienence for a feature we're not going to use and doesn't have a realistic use case<br> <dael> fantasai: We've spent a lot of time talking about removing a feature that's mostly interop. I'm inclined to leave things along with no change<br> <dbaron> +1 to spending time on other things<br> <dael> Rossen_: Also a valid option<br> <dael> Rossen_: iank_ would you be okay no change for now?<br> <dael> iank_: Fine. No work for me now, this is for someone down the line with scrollers.<br> <dael> Rossen_: Objections to no change on this issue?<br> <dael> amelia: Can we leave an issue about scrollbar case?<br> <dael> Rossen_: We can<br> <dael> RESOLVED: no change on this issue<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3872#issuecomment-488498771 using your GitHub account
Received on Wednesday, 1 May 2019 23:42:41 UTC