-
Notifications
You must be signed in to change notification settings - Fork 659
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[css-background-4] Replace corner-shape
with property that just does angled corners + rounding
#8591
Comments
I really like this proposal! Also, I think I need to mention one case which could be one of the most common, and which also falls in line with a lot of the recent work on popovers and stuff (html modals/popovers, anchor positioning) — the popovers' tip/arrows. So it would be really awesome to also have this in our toolbox. Here is what I mean when trying the https://projects.verou.me/corner-shape/ Basically, most current implementations of the tips/arrows are either using the border hack, or using a rotated item, or masks, while using something like a |
This seems like a lot of added complexity for a fairly niche style. Clip-path with Then, the missing feature would be to create a border that follows the clipped shape, or to create that shape without actually clipping child overflow. So, my suggestion would be to create a (Complication: which border-width & style? The shape wouldn't necessarily have 4 sides, but the browser would still need to handle a mix of border styles! Maybe: divide up the border box into triangles created by diagonal lines and stroke the sections of the border-shape that fall in each triangle according to that border style.) For rounding corners after bevelling, I'd be happy to see a single corner-radius parameter added to the polygon function, for all of the places where the function is used: clip-path, shape outside, offset-path, maybe one day SVG. Or maybe two corner-radius parameters, one for convex corners and one for concave. (Long term, I'd also like to get an accepted syntax for combining percentages, unit-lengths, and calc/math function with SVG path notation, so you could get all sorts of shapes! But polygons with slightly rounded corners is a nice, simple solution to many use cases.) Benefits of replacing
Downside:
|
I disagree that it is niche. Perhaps actual beveled corners are niche, but the kinds of polygons one can create with this are all over the web. #6980 has several use cases.
It looks like this is basically my earlier |
Only because the spec encourages elegant transitions in style and width as the border goes around the corner! If we accept that fancy borders with different width/colour/styles on each side are edge cases & it's OK to have hard stop changes, then my suggestion of clipping the stroke shape to the box diagonals is easy enough to implement. |
For which I created a separate issue because it goes way beyond corner shapes.
@AmeliaBR @LeaVerou Are the transitions between borders the reason implementers are reluctant to implement corner shapes? Or is it the missing specification regarding those transitions in Level 4? Or is it something else? I assume the implementation of bevel shapes in combination with different widths, colors and styles is much easier than for rounded corners. And those are implemented more or less interoperably for so many years now. Regarding the two suggested approaches, I think Lea's idea is easier for authors to use in general. Though I wouldn't actually throw away the idea of the general Picking up the examples from above, this could look like: corner-shape: bevel(50%); /* diamond */
corner-shape: edge edge bevel(100%); /* triangle top left */
corner-shape: bevel(50%) bevel(50%) 0 0 / bevel(100%); Though those examples are rather edge cases, anyway. More common cases would be something like
I'd rather stay with The implementation complexity can be reduced by restricting the values of Sebastian |
You would need to ask implementers :)
Yeah, I'm not convinced that's an advantage :)
Note that you can get elliptical radii with a single |
So in general, I agree with adding an additional property to work with border-radius, and it taking some form of angle hinting, but I'm going to throw out a crazy idea here: Using cubic bezier function to draw the radius, with Default value would be 0deg, and Downside is that you can't perfectly represent a circle with cubic-bezier. |
@SYwaves using |
Right, elliptical radii probably aren't expected in combination with bevels or other corner shapes. So giving this a little more thought, I now tend to agree with you that it might be better to introduce a separate property for that.
@tabatkins, @smfr, @emilio What needs to happen to get some attention for this feature? Sebastian |
I'm not the expert on the graphics-side of I think at least from the CSS / layout side the current Anyways this doesn't look too hard to implement, specially if it's built on top of border-radius as it is on the current backgrounds-4 spec. But it doesn't seem to be in the "trivial-ish" camp either. I'd have to defer to @lsalzman / @mstange / @jrmuizel / @glennw / @kdashg for actual graphics-knowledge. My guess is that this is probably not technically hard to do, just some / a bunch of work to make fast. |
@emilio Thank you for the detailed feedback! Just to be clear, as I understand you, you'd prefer the currently specified Sebastian |
@LeaVerou I see. If that's the case, is it not easier to extend another property rather than working around current implementation of I suppose that's just shifting the issue elsewhere, but I think the need to draw arbitrary shapes isn't exactly isolated to just the bounding box and |
Opened "standards positions" github issues for 'corner-shape' with Mozilla and Webkit just to try and get this on folks radar. Mozilla has a response, nothing yet from WebKit: Mozilla: mozilla/standards-positions#823 |
I'm playing with
|
#6980 (comment) has a mixed-corner-treatment example. |
|
No, the "indent" type corners ( |
In particular, the diagonally opposite corners might intersect. The existing radius-clamping rules do indeed prevent adjacent corners from intersecting. See, for example: .box {
width: 100px; height: 100px;
border-radius: 100px 0 100px 0;
border: thin solid;
corner-shape: scoop;
}
|
At this point, it's very clear that there is little implementor interest for
corner-shape
as it's currently specified. It has been in the spec for over a decade, so this is unlikely to change.However, looking at the
corner-shape
use cases in #6980, I am observing these things:a) The vast majority just need
bevel
(angled) corners.scoop
andnotch
are rather rare and niche enough that I think are fine being delegated to CSS shapes or border-image.b) Quite frequently, these angled corners also require rounding, which the current syntax does not actually do.
Therefore, the current design of
corner-shape
which treatsborder-radius
as a fallback with the same radius, won't work (and there has been feedback that this is a worse fallback than nothing at all for most use cases).Angled corners
Instead, I propose a
corner-angle
property (name TBB) which only does angled corners.It takes the same syntax as
border-radius
, with keywords for common cases, such as:diamond
=50% 50% 50% 50%
triangle top left
=0 0 100%
(+ keywords for all four corners)triangle top
=50% 50% 0 0 / 100%
(+ keywords for all four sides)Brainstorming for property name:
corner-angle
corner-cutout
cutout-size
bevel-radius
corner-size
angled-corners
cutout-corner-size
Angle rounding
It seems that rounding is essential to satisfy the use cases in the real world, otherwise authors will still resort to images.
border-radius
could work together with the new property to add rounding to the angles generated. This has the advantage of re-using an existing property, but it has some pretty major disadvantages:First,
border-radius
is designed to specify rounding for 1-4 corners, whereas this syntax can create up to 8 angles:So, how would we map
border-radius
's four corners to these eight? We could map it to pairs (e.g.border-radius
for top left corner rounds both 1 and 2 above), but that's pretty weird. But the primary problem is pointless complexity and wasted implementation effort to make any possibleborder-radius
value work with these polygons, when the vast majority of use cases just needs a single radius. Personally, I have not seen single a single use case that requires more than that.So perhaps we need a separate property (
angle-radius
?) that just takes a single<length>
. Though it is a bit weird that this basically becomes a subset ofborder-radius
whencorner-angle
isinitial
.Other considerations
Whatever syntax we go with, we should make sure it allows combining regular
border-radius
with this, e.g. it should allow having two angled corners (with or without rounding) plus two rounded corners (with the full power ofborder-radius
).cc @fantasai @SebastianZ
The text was updated successfully, but these errors were encountered: