Border Curvature Proposal

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Border Curvature Proposal

Jacob Parker
Negative border radii, as commonly suggested, doesn’t really make sense. I’ve seen a suggestion to have border radii styles, including normal, inverted, and flat (just a clipped corner). I think these could be achieved using superellipses, and would be much more flexible.

Made a draft spec

https://github.com/jacobp100/css-border-curvature




Reply | Threaded
Open this post in threaded view
|

Re: Border Curvature Proposal

Sebastian Zartner-3
On 30 July 2015 at 21:28, Jacob Parker <[hidden email]> wrote:
> Negative border radii, as commonly suggested, doesn’t really make sense. I’ve seen a suggestion to have border radii styles, including normal, inverted, and flat (just a clipped corner). I think these could be achieved using superellipses, and would be much more flexible.
>
> Made a draft spec
>
> https://github.com/jacobp100/css-border-curvature

Note that the CSS Backgrounds and Borders Module Level 4 defines a
related property 'corner-shape', and issue 4[2] asking for
'cubic-bezier()' as value, which should cover your use case.

Sebastian

[1] https://drafts.csswg.org/css-backgrounds-4/#issue-05846e60

Reply | Threaded
Open this post in threaded view
|

Re: Border Curvature Proposal

Lea Verou-2
In reply to this post by Jacob Parker

> On Jul 30, 2015, at 22:28, Jacob Parker <[hidden email]> wrote:
>
> Negative border radii, as commonly suggested, doesn’t really make sense. I’ve seen a suggestion to have border radii styles, including normal, inverted, and flat (just a clipped corner). I think these could be achieved using superellipses, and would be much more flexible.
>
> Made a draft spec
>
> https://github.com/jacobp100/css-border-curvature

As Sebastian said, this is already planned for backgrounds-4 with a different syntax (corner-shape). However, it’s still useful to examine different options for this, as it’s still being worked on.

However, this proposal has several issues.

Firstly, `curvature` is a rather academic term that most users will have difficulty with. Simple words please!

Most importantly, while the solution proposed is mathematically elegant (love how corner-shape’s curve, bevel and scoop are all achievable just by varying n), I’m afraid its usability is very problematic: Most CSS authors have severe trouble even with middle school level math. Actually, even many *distinguished* CSS authors have trouble with middle school level math, as I realized during the tech review rounds of my book. With this proposal, you need to be able to *graph* the result of a relation to predict what the curve will look like! That’s way more than what most CSS authors are comfortable with. Sure, cubic bezier values have the same problem, but at least designers are more familiar with them empirically from vector drawing programs, are already used in other parts of CSS, and there are non-academic tools to assist working with them.

~Lea
Reply | Threaded
Open this post in threaded view
|

Re: Border Curvature Proposal

Una Kravets
I agree that using Bézier curves makes sense -- they're already implemented in other aspects of CSS and the repetition will only strengthen understanding and mastery. Why introduce a new concept when one already exists that could do the job well?

- Una

> On Aug 5, 2015, at 11:17 AM, Lea Verou <[hidden email]> wrote:
>
>
>> On Jul 30, 2015, at 22:28, Jacob Parker <[hidden email]> wrote:
>>
>> Negative border radii, as commonly suggested, doesn’t really make sense. I’ve seen a suggestion to have border radii styles, including normal, inverted, and flat (just a clipped corner). I think these could be achieved using superellipses, and would be much more flexible.
>>
>> Made a draft spec
>>
>> https://github.com/jacobp100/css-border-curvature
>
> As Sebastian said, this is already planned for backgrounds-4 with a different syntax (corner-shape). However, it’s still useful to examine different options for this, as it’s still being worked on.
>
> However, this proposal has several issues.
>
> Firstly, `curvature` is a rather academic term that most users will have difficulty with. Simple words please!
>
> Most importantly, while the solution proposed is mathematically elegant (love how corner-shape’s curve, bevel and scoop are all achievable just by varying n), I’m afraid its usability is very problematic: Most CSS authors have severe trouble even with middle school level math. Actually, even many *distinguished* CSS authors have trouble with middle school level math, as I realized during the tech review rounds of my book. With this proposal, you need to be able to *graph* the result of a relation to predict what the curve will look like! That’s way more than what most CSS authors are comfortable with. Sure, cubic bezier values have the same problem, but at least designers are more familiar with them empirically from vector drawing programs, are already used in other parts of CSS, and there are non-academic tools to assist working with them.
>
> ~Lea


Reply | Threaded
Open this post in threaded view
|

Re: Border Curvature Proposal

Robert O'Callahan-3
CSS border rendering is already insanely complex. Can we please not extend it any further and instead progress Custom Painting to allow users to do whatever effects they want?

Rob
--
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea lurpr  
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr  esn
Reply | Threaded
Open this post in threaded view
|

Re: Border Curvature Proposal

Brad Kemper

> On Aug 5, 2015, at 3:45 PM, Robert O'Callahan <[hidden email]> wrote:
>
> CSS border rendering is already insanely complex. Can we please not extend it any further and instead progress Custom Painting to allow users to do whatever effects they want?

Funny; I think a lot of us authors consider existing border capabilities to be pretty rudimentary, regardless of implementor complexities. That's not a criticism, just the lay of the land right now. Besides lack of corner shape control beyond rounding, there is no control over dashes and dots (shape/length/spacing), no multiple-border support, no border-offset, no images-along-a-border-path, and only 3x3 border images (no 5x5, 5x3, etc.).

What is Custom Painting?



Reply | Threaded
Open this post in threaded view
|

Re: Border Curvature Proposal

Robert O'Callahan-3
On Fri, Aug 7, 2015 at 10:03 AM, Brad Kemper <[hidden email]> wrote:
> On Aug 5, 2015, at 3:45 PM, Robert O'Callahan <[hidden email]> wrote:
>
> CSS border rendering is already insanely complex. Can we please not extend it any further and instead progress Custom Painting to allow users to do whatever effects they want?

Funny; I think a lot of us authors consider existing border capabilities to be pretty rudimentary, regardless of implementor complexities. That's not a criticism, just the lay of the land right now. Besides lack of corner shape control beyond rounding, there is no control over dashes and dots (shape/length/spacing), no multiple-border support, no border-offset, no images-along-a-border-path, and only 3x3 border images (no 5x5, 5x3, etc.).

Individually those might be OK features. Combine them all, along with the existing features, and that's when things get nightmarish.

Right now you can have a border corner that's elliptical, with different inner and outer widths on each side, with dots on one side and dashes on another, with different colors on each side (one or both of which may be transparent, making pixels receiving contributions from both sides very interesting). Getting that to render nicely is already extremely challenging. You want to be able to have all that plus a different shape,  control the shape, spacing and length of dashes and dots, and do all that with multiple (nested I assume) borders. For interop the results of that mess should be clearly defined in the spec (even the current borders aren't), and implemented correctly and efficiently in all browsers.

Draft a spec for all that, make a reference implementation that covers *all* cases, and then let's talk.

Rob
--
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea lurpr  
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr  esn
Reply | Threaded
Open this post in threaded view
|

Re: Border Curvature Proposal

Ian Kilpatrick
In reply to this post by Brad Kemper
What is Custom Painting?


Allows an author to paint an element post-layout based on style and layout changes.

This with custom properties & values (https://drafts.css-houdini.org/css-properties-values-api/) makes it possible to create a high fidelity (and performant) polyfill.
Reply | Threaded
Open this post in threaded view
|

Re: Border Curvature Proposal

Brad Kemper
In reply to this post by Robert O'Callahan-3



On Aug 6, 2015, at 3:31 PM, Robert O'Callahan <[hidden email]> wrote:

On Fri, Aug 7, 2015 at 10:03 AM, Brad Kemper <[hidden email]> wrote:
> On Aug 5, 2015, at 3:45 PM, Robert O'Callahan <[hidden email]> wrote:
>
> CSS border rendering is already insanely complex. Can we please not extend it any further and instead progress Custom Painting to allow users to do whatever effects they want?

Funny; I think a lot of us authors consider existing border capabilities to be pretty rudimentary, regardless of implementor complexities. That's not a criticism, just the lay of the land right now. Besides lack of corner shape control beyond rounding, there is no control over dashes and dots (shape/length/spacing), no multiple-border support, no border-offset, no images-along-a-border-path, and only 3x3 border images (no 5x5, 5x3, etc.).

Individually those might be OK features. Combine them all, along with the existing features, and that's when things get nightmarish.

Right now you can have a border corner that's elliptical, with different inner and outer widths on each side, with dots on one side and dashes on another, with different colors on each side (one or both of which may be transparent, making pixels receiving contributions from both sides very interesting). Getting that to render nicely is already extremely challenging. You want to be able to have all that plus a different shape,  control the shape, spacing and length of dashes and dots, and do all that with multiple (nested I assume) borders.

Stacked in the z axis, like backgrounds, would be my preference. Border-offset would allow it to look nested when you want that. So would thicker borders in the back, thinner in the front, if the colors were opaque. 

For interop the results of that mess should be clearly defined in the spec (even the current borders aren't), and implemented correctly and efficiently in all browsers.

Yeah, I totally agree with that. 

Draft a spec for all that, make a reference implementation that covers *all* cases, and then let's talk.

Yeah, I'd love to. I have stuff in my head, doing thought experiments on some of the details; just haven't had time to write it down. 

I don't think I could make a reference implementation myself, but who knows? Maybe eventually I could take a stab at a polyfill, especially if the Houdini stuff is ready by the time I start cracking down on it. 


Rob
--
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea lurpr  
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr  esn