[css-backgrounds-4] Borders with cut corners

[peteroupc]

For your information and discussion.

I have noticed that in the Google Developer blog, an article recently published noted a gap in border support in the Web Platform. Namely, the Web Platform currently doesn't support borders with cut corners (as opposed to round or square corners), and the Material Design team is working on using the Houdini API, which is "not ready yet", to provide such borders.

However, I feel that supporting cut corners "natively", in addition to rounded corners, will give Web developers another option in designing their Web pages (not just for Material Design's purposes). Perhaps this can be implemented using additional CSS properties (e.g., cut-border-radius) that work analogously to border-radius.

[SebastianZ]

That is already defined in the Backgrounds and Borders 4 spec. as corner-shape: bevel;. (And there are even a few more corner shapes you can specify.)

Sebastian

[peteroupc]

Thanks for pointing that out. In that case, I find it strange that the article I cited didn't cite corner-shape: bevel or the other recent standardization efforts of the W3C with respect to CSS border styling, or whether the Material Design team was much aware of them.

[SebastianZ]

The main reason why the article doesn't mention corner-shape is probably that the Material Design team wanted to base their shape system on existing technology - and corner-shape is not implemented in any browser yet, unfortunately (and the specification even claims "not ready for implementation").

But it could also be that they didn't know about the standardization efforts. Luckily, I saw that the article does have a comment form below, so I mentioned it there.

Sebastian

[fantasai]

Yeah, css-backgrounds-4 isn't even FPWD, it's mostly just brainstorming and bits of resolutions with half-baked spec text... It needs a lot of work to grow up into a real spec. :)

[SelenIT]

Maybe something more flexible like allowing to use <basic-shape> values as border-image-source could simplify creating boxes with differently shaped corners without requiring tons of new keywords for each of them?

[bradkemper]

Don’t forget that you can use border-image to create whatever corners you like, and can use SVG for the image if you want. I’m not saying we shouldn’t have ‘corner-shape’, but ‘border-image’ is available and reliable already.

[bradkemper]

Sorry @SelenIT, I should have read your comment first. ‘polygon()’ and ‘path()’ for ‘border-image-source’ are interesting ideas. I’m not opposed, but you can almost get that now with SVG inside a data url.

[css-meeting-bot]

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

The full IRC log of that discussion

<fantasai> Topic: corner-shape use cases
<argyle> 🎉
<astearns> github: https://github.com//issues/3457
<fantasai> https://drafts.csswg.org/css-backgrounds-4/#corner-shaping
<fantasai> <br type=5min>
<fantasai> RESOLVED: Add Florian as editor of css-text-4
<fremy> ScribeNick: fremy
<fremy> una: corner-shape is something that google uses in the material design system
<fremy> una: it works on ios and android
<fremy> una: but not on the web
<fremy> una: I tried to write this in houdini
<fremy> una: but it's not super straightforward because you need a background, a mask, etc...
<fremy> una: but since this feature is very common, I don't think the custom approach is very practical
<myles_> q+
<fremy> una: so I'd like to revisit the spec to reintroduce the corner-shape
<fremy> una: for instance, angled and rounds border are very important
<fremy> jensimmons: can somebody summarize what we have done in the past?
<fremy> leaverou: sure
<leaverou> https://drafts.csswg.org/css-backgrounds-4/#corner-shaping
<fremy> leaverou: what we have right now (pasted linke)
<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
<fremy> leaverou: and it turns out everytime people ask me about this, people want angled corners
<fremy> leaverou: so I think we could remove a lot of the complexity and keep most of the use cases
<una> https://material.io/design/shape/about-shape.html#shape-customization-tool
<fremy> una: (showing a couple of buttons, and some options like angle, distance, rounding...)
<bkardell_> q+
<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
<fremy> rachelandrew____: I concur a lot of people want this
<fremy> rachelandrew____: and asked me for it
<fremy> (we are talking about angled borders)
<fremy> AmeliaBR: the border should follow the shape
<jensimmons> q?
<fremy> myles_: what is the specific proposal?
<AmeliaBR> `corner-shape: round | angle`
<fremy> una: what is in the draft minus scoop and notch, and rename angle and bevel
<astearns> ack myles_
<fremy> myles_: so the proposal is to drop values?
<fremy> una: and rename one
<fremy> dbaron: two comments
<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
<fremy> dbaron: and it so happens that borders are one of the areas where we already have a lot of undefined corner cases
<fremy> dbaron: maybe the spec is better now, but we are not very interoperable now
<fremy> leaverou: didn't fantasai do a lot of work on this already?
<fremy> fantasai: yes, the cases we would introduce here are similar to the things we had to define for rounded corners
<fremy> fantasai: so globally I don't think this would be too undefined
<leaverou> q?
<leaverou> q+
<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.
<fremy> dbaron: but even then, there are so many weird things about borders, and each of these weird features have their own code paths
<fremy> dbaron: and even special codepaths for specific combinations
<fremy> dbaron: and I'm concerned about it
<astearns> ack dbaron
<fremy> astearns: for instance shape-outside, etc
<fremy> dbaron: and clip for instance
<fremy> fantasai: I think this would be manageable
<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
<fremy> dbaron: and that is because border has a lot of cases, and all of them have to be fast
<fremy> myles: sure, but we are trying to drop values, so this is better now, right?
<astearns> ack bkardell_
<fremy> dbaron: well there was also encouragement to implement, right?
<fremy> myles: sure, encouragement received, but we could discuss the proposal
<fremy> bkardell_: you mentioned that houdini was difficult to use?
<fremy> bkardell_: could we have done anything better to make this easier, or is the problem just hard in general?
<dbaron> Example 1 in https://drafts.csswg.org/css-backgrounds-4/#the-border-color looks hard to do in reality...
<fremy> bkardell_: (asking because this has been around for a very long time, and didn't get traction, so it might never happen)
<fremy> una: I think the main reason I want to standardize is that this is very common
<fantasai> dbaron, that's not even what we're discussing, though
<fantasai> una: Houdini is for unique cases
<AmeliaBR> That's a separate issue, dbaron!
<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
<fantasai> una: to get this right I have to mask the corners
<fremy> una: having to define both a background, a border, a mask, so in the end it's very heavy on the usage side
<fremy> una: in the end it works, but it's not great
<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
<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
<fantasai> iank: also need to handle hit-testing
<fremy> florian: note that the outline should follow corner-shape but no browser does
<astearns> ack leaverou
<fantasai> s/does/does, except sometimes for auto/
<fremy> bkardell_: but border does, so people sometimes use borders for outlines because they are so powerful
<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?
<AmeliaBR> s/note that/the spec notes that/
<fremy> fantasai: yes, but it's a worse name, and we can already use @supports
<fremy> leaverou: ah, true, then I guess we prefer to stick with the best name
<fremy> astearns: anything else on this topic?
<fremy> fantasai: we need a resolution to drop the two values
<fremy> astearns: yes, and I think it's a good idea
<AmeliaBR> s/we could use/we could use a new better name for/
<AmeliaBR> s/a nice fallback/fallback to sharp corners instead of to rounded corners/
<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
<tantek> una: border radius is everywhere today
<fremy> astearns: so do we know that material design is not going to switch to another type of border by the time we ship?
<fremy> una: people still use border-radius a lot though
<fremy> fantasai: also, there are a lot of other cases where we need special shapes and polygons
<fremy> AmeliaBR: for instance parallelograms are useful, and difficult to make in css
<tantek> clip-path solves the BSG use-case: https://css-tricks.com/notched-boxes/
<fremy> astearns: ok, let's move to the resolution, does anyone object to that?
<fremy> RESOLVED: drop the less useful values, and rename as proposed in the issue
<fremy> astearns: anything else on this topic?
<fremy> una: no, thanks
<fremy> (discussion about implementer interest)
<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

[fantasai]

corner-shape: [ round | angle ]{1, 4} edited in.

[yisibl]

Why was notch/scoop deleted? I think they are very useful.

https://css-houdini.rocks/corner-shape/