- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 05 Jun 2019 19:13:40 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `corner-shape use cases`, and agreed to the following: * `RESOLVED: Add Florian as editor of css-text-4` * `RESOLVED: drop the less useful values, and rename as proposed in the issue` <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: corner-shape use cases<br> <argyle> 🎉<br> <astearns> github: https://github.com/w3c/csswg-drafts/issues/3457<br> <fantasai> https://drafts.csswg.org/css-backgrounds-4/#corner-shaping<br> <fantasai> <br type=5min><br> <fantasai> RESOLVED: Add Florian as editor of css-text-4<br> <fremy> ScribeNick: fremy<br> <fremy> una: corner-shape is something that google uses in the material design system<br> <fremy> una: it works on ios and android<br> <fremy> una: but not on the web<br> <fremy> una: I tried to write this in houdini<br> <fremy> una: but it's not super straightforward because you need a background, a mask, etc...<br> <fremy> una: but since this feature is very common, I don't think the custom approach is very practical<br> <myles_> q+<br> <fremy> una: so I'd like to revisit the spec to reintroduce the corner-shape<br> <fremy> una: for instance, angled and rounds border are very important<br> <fremy> jensimmons: can somebody summarize what we have done in the past?<br> <fremy> leaverou: sure<br> <leaverou> https://drafts.csswg.org/css-backgrounds-4/#corner-shaping<br> <fremy> leaverou: what we have right now (pasted linke)<br> <fremy> leaverou: one of the reason this hasn't moved much is that it's trying to do too much and is scaring away implementers<br> <fremy> leaverou: and it turns out everytime people ask me about this, people want angled corners<br> <fremy> leaverou: so I think we could remove a lot of the complexity and keep most of the use cases<br> <una> https://material.io/design/shape/about-shape.html#shape-customization-tool<br> <fremy> una: (showing a couple of buttons, and some options like angle, distance, rounding...)<br> <bkardell_> q+<br> <fremy> una: now we have to implement with custom shapes, but that would be better as part of css, because we could reuse colors and not have to define the masking<br> <fremy> rachelandrew____: I concur a lot of people want this<br> <fremy> rachelandrew____: and asked me for it<br> <fremy> (we are talking about angled borders)<br> <fremy> AmeliaBR: the border should follow the shape<br> <jensimmons> q?<br> <fremy> myles_: what is the specific proposal?<br> <AmeliaBR> `corner-shape: round | angle`<br> <fremy> una: what is in the draft minus scoop and notch, and rename angle and bevel<br> <astearns> ack myles_<br> <fremy> myles_: so the proposal is to drop values?<br> <fremy> una: and rename one<br> <fremy> dbaron: two comments<br> <fremy> dbaron: one is that one of the difficult thing about adding things to the webplatform is that we have to articulate how these new things have to work with all the other things in this area of the platform<br> <fremy> dbaron: and it so happens that borders are one of the areas where we already have a lot of undefined corner cases<br> <fremy> dbaron: maybe the spec is better now, but we are not very interoperable now<br> <fremy> leaverou: didn't fantasai do a lot of work on this already?<br> <fremy> fantasai: yes, the cases we would introduce here are similar to the things we had to define for rounded corners<br> <fremy> fantasai: so globally I don't think this would be too undefined<br> <leaverou> q?<br> <leaverou> q+<br> <AmeliaBR> For rendering, this affects: drawing borders (dot/dash spacing, color or width changes at corners), clipping backgrounds, replaced content like images, and child content (if overflow is hidden), box shadow shape, hit testing.<br> <fremy> dbaron: but even then, there are so many weird things about borders, and each of these weird features have their own code paths<br> <fremy> dbaron: and even special codepaths for specific combinations<br> <fremy> dbaron: and I'm concerned about it<br> <astearns> ack dbaron<br> <fremy> astearns: for instance shape-outside, etc<br> <fremy> dbaron: and clip for instance<br> <fremy> fantasai: I think this would be manageable<br> <fremy> dbaron: an example I would want to mention is one time where we spent 30% of the time in rendering gmail in drawing border<br> <fremy> dbaron: and that is because border has a lot of cases, and all of them have to be fast<br> <fremy> myles: sure, but we are trying to drop values, so this is better now, right?<br> <astearns> ack bkardell_<br> <fremy> dbaron: well there was also encouragement to implement, right?<br> <fremy> myles: sure, encouragement received, but we could discuss the proposal<br> <fremy> bkardell_: you mentioned that houdini was difficult to use?<br> <fremy> bkardell_: could we have done anything better to make this easier, or is the problem just hard in general?<br> <dbaron> Example 1 in https://drafts.csswg.org/css-backgrounds-4/#the-border-color looks hard to do in reality...<br> <fremy> bkardell_: (asking because this has been around for a very long time, and didn't get traction, so it might never happen)<br> <fremy> una: I think the main reason I want to standardize is that this is very common<br> <fantasai> dbaron, that's not even what we're discussing, though<br> <fantasai> una: Houdini is for unique cases<br> <AmeliaBR> That's a separate issue, dbaron!<br> <fremy> una: houdini is great for custom things, but it's complex here, and this problem is common, so I think this should be a default provided feature<br> <fantasai> una: to get this right I have to mask the corners<br> <fremy> una: having to define both a background, a border, a mask, so in the end it's very heavy on the usage side<br> <fremy> una: in the end it works, but it's not great<br> <dbaron> I think it's not a separate issue, because we're talking about dropping two of the four values from a feature that was optimistically put in the spec without clear implementor interest<br> <fremy> iank_: also, you can't easily incorporate the clipping effect of the border-radius in various other properties, painting is just part of the story<br> <fantasai> iank: also need to handle hit-testing<br> <fremy> florian: note that the outline should follow corner-shape but no browser does<br> <astearns> ack leaverou<br> <fantasai> s/does/does, except sometimes for auto/<br> <fremy> bkardell_: but border does, so people sometimes use borders for outlines because they are so powerful<br> <fremy> leaverou: an interesting thing I was wondering is that maybe we could use border-radius to define the radius to have a nice fallback?<br> <AmeliaBR> s/note that/the spec notes that/<br> <fremy> fantasai: yes, but it's a worse name, and we can already use @supports<br> <fremy> leaverou: ah, true, then I guess we prefer to stick with the best name<br> <fremy> astearns: anything else on this topic?<br> <fremy> fantasai: we need a resolution to drop the two values<br> <fremy> astearns: yes, and I think it's a good idea<br> <AmeliaBR> s/we could use/we could use a new better name for/<br> <AmeliaBR> s/a nice fallback/fallback to sharp corners instead of to rounded corners/<br> <fremy> astearns: I however I want to point out that the border-radius took so long to implement that by the time it shipped people moved to other designs<br> <tantek> una: border radius is everywhere today<br> <fremy> astearns: so do we know that material design is not going to switch to another type of border by the time we ship?<br> <fremy> una: people still use border-radius a lot though<br> <fremy> fantasai: also, there are a lot of other cases where we need special shapes and polygons<br> <fremy> AmeliaBR: for instance parallelograms are useful, and difficult to make in css<br> <tantek> clip-path solves the BSG use-case: https://css-tricks.com/notched-boxes/<br> <fremy> astearns: ok, let's move to the resolution, does anyone object to that?<br> <fremy> RESOLVED: drop the less useful values, and rename as proposed in the issue<br> <fremy> astearns: anything else on this topic?<br> <fremy> una: no, thanks<br> <fremy> (discussion about implementer interest)<br> <fremy> iank_: that's a lot of work, and we didn't see enough use cases yet to change our prioritization, but we would be happy to adjust based on more data<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3457#issuecomment-499217243 using your GitHub account
Received on Wednesday, 5 June 2019 19:13:43 UTC