- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 03 Aug 2022 18:56:48 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Border Radius Spread`. <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: Border Radius Spread<br> <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/7103<br> <TabAtkins> fantasai: I think we should have demos before we discuss this<br> <TabAtkins> Rossen_: oriol made those an hour ago<br> <TabAtkins> oriol: you can see a comparison of the different algos<br> <TabAtkins> oriol: i didn't find an algo that works perfectly for all<br> <TabAtkins> oriol: but maybe i'm leaning towards the last one in the demo<br> <bramus> https://people.igalia.com/obrufau/testcases/shadow-radius/<br> <TabAtkins> oriol: [demos]<br> <TabAtkins> oriol: first is no polyfill at all, browser does different things<br> <TabAtkins> oriol: this is chromium<br> <TabAtkins> oriol: here's current spec, where a ciruclar element is a non-ciruclar shadow'<br> <TabAtkins> oriol: here's another showing that same, with an ellipse<br> <TabAtkins> oriol: another algo is ot increase radius by spread<br> <TabAtkins> oriol: similar to firefox, but ff has a special case for 0 radius that isn't continuous<br> <TabAtkins> oriol: otherwise i'd say it's not a bad algo<br> <TabAtkins> oriol: there are some variant algos that take the border radius, express it as a percentage, then apply the same % to the shadow<br> <TabAtkins> oriol: good in some cases, but in this ellipse case it gets flat edges<br> <TabAtkins> oriol: using the maximum axis improves some cases but not all<br> <TabAtkins> oriol: ellipse is still flat<br> <TabAtkins> oriol: then my original proposal is each % is taken independently per axis<br> <Rossen_> q?<br> <TabAtkins> oriol: this works good i'd say, but has problem shown in this long roundrect,<br> <TabAtkins> oriol: where the shadow gets an elliptical corner when the original element was circular corner<br> <TabAtkins> oriol: so final variant, finds %s in each axis, then tries to, for each corner, if the radius has changed its aspect ratio relative to the element, it tries to increase one component to hit the same aspect-ratio<br> <TabAtkins> oriol: with the limitation that it prevents the radius from going to [???]<br> <TabAtkins> oriol: we have a restriction that the x component of top-left and top-right radius shouldn't exceed the width; the spec has an adjustment for that<br> <TabAtkins> oriol: so the constraint we apply here is we increase one component to restore the aspect ratio, without breaking this constraint<br> <TabAtkins> oriol: I think this is the best I could find<br> <TabAtkins> oriol: 0 radius gives square shadow, 1px gives mostly-square shadow<br> <TabAtkins> oriol: circle and ellipse are still pretty round<br> <lea> would be nice if one could input their own dimension/spread/radius values to see the result with the different algorithms<br> <TabAtkins> oriol: circular corners stay circular on the shadow even with long rects<br> <TabAtkins> oriol: in this example (a "cup" shape) the shadow looks like it becomes thinner, but it is the same arc in both the shape and the shadow<br> <TabAtkins> oriol: So this is the best idea I could find<br> <TabAtkins> oriol: if people want to play with this they can look at the source, it's a standalone page<br> <TabAtkins> oriol: [explains how to modify the demo]<br> <TabAtkins> Rossen_: fantastic, thansk fo rputting in the time for this<br> <lea> but yes, so great to have a demo! thanks oriol!<br> <TabAtkins> dbaron: I was looking at the cases where you said your preferred algo wasn't great<br> <TabAtkins> dbaron: I agree it's not that great, like the 3rd fro mthe end case<br> <TabAtkins> dbaron: it seems what the algo is doing wrong is producing too large a radius<br> <TabAtkins> dbaron: don't know why<br> <TabAtkins> dbaron: the problem there is the radius we're ending up with seems larger than it should be<br> <TabAtkins> oriol: both arcs are circular<br> <TabAtkins> oriol: inner element has border-radius of 39/39<br> <TabAtkins> oriol: shadow has border radius of 107/107<br> <TabAtkins> oriol: so x and y components are equal<br> <Rossen_> a/fo rputting/for putting/<br> <TabAtkins> oriol: almost no radius in the top left, and the shadow similarly has almost no radius there<br> <vmpstr> q+<br> <Rossen_> ack dbaron<br> <Rossen_> ack fantasai<br> <TabAtkins> fantasai: last time we discussed this i wanted to ask if it's posibble alternative...<br> <TabAtkins> fantasai: we have a formula in the spec, and the original proposal that's to use the same %s<br> <TabAtkins> fantasai: so, should we decide which formula to use based on whether the original radius was expressed in lengths or %s?<br> <TabAtkins> fantasai: so if you have oval that's 50%, the spread would also be 50%<br> <TabAtkins> fantasai: whereas if it was 200px/100px, we'd use the old formula<br> <vmpstr> q-<br> <TabAtkins> fantasai: So rather than just doing math on the absolute value, carry over the initial intent<br> <TabAtkins> fantasai: looking at these tests, the ones that look bad in the old formula are the ones where the length of the straight part of the border are 0 or close<br> <TabAtkins> fantasai: whereas the bad ones for %s are where the straight side is pretty long<br> <TabAtkins> fantasai: so we could have two different formulas, using one when the straight side is 0 or the other when large<br> <TabAtkins> fantasai: and between the two for some distance, such as radius = straight side to 0, we interpolate the formulas<br> <TabAtkins> oriol: re: the first thing, choosing the algo depending on whether the author specified length or %<br> <TabAtkins> oriol: I didn't consider that<br> <TabAtkins> oriol: issue is you can get the same shape in either way<br> <TabAtkins> oriol: seems strange to have two equivalent shapes for th eleemnet can produce different shadows<br> <Rossen_> q<br> <TabAtkins> fantasai: yeah but consider i have an element that's short, and the border-radius makes a semicircle, i might want that becuase i want a pillshaped box<br> <lea> q?<br> <lea> q+<br> <TabAtkins> fantasai: *or* it might be a consequence of this box being short, and i have a set of boxes with rounded corners and straight sides, so i'd prefer the shadow generally to have straight sides<br> <TabAtkins> fantasai: dunno if it's a great idea. authors might not think about their intent, and isntead just shove in numbers that get a result<br> <TabAtkins> oriol: could be a possibility<br> <TabAtkins> oriol: didn't consider it, to have it differentiate would have to [missed]<br> <TabAtkins> oriol: re: the other thing about combining algos<br> <TabAtkins> oriol: you were mentioning the old algo, what browsers used to do and firefox still does<br> <TabAtkins> fantasai: my understanding is chrome updated to current spec and realized there were problems<br> <TabAtkins> fantasai: the cases that work poorly are those where you want to get a round shape<br> <TabAtkins> fantasai: in those %s work great<br> <TabAtkins> fantasai: but they work bad for rounded corners on a rectangular shape, that's where current spec works well<br> <TabAtkins> fantasai: so using both formulas and interpolating might be a way to get good results in more cases<br> <TabAtkins> oriol: but then how do you do this interpolation?<br> <TabAtkins> fantasai: you look at the straight side, if it's 0 you use % formula. if it's longer than the radius, use the old formula. between those two, you do linear interp<br> <TabAtkins> lea: not super confident since this is the first time iv'e seen this<br> <TabAtkins> lea: but looking thru these algos<br> <TabAtkins> lea: as an author, anything with a % produces surprising results in some cases<br> <TabAtkins> lea: the one that produces th eleast surprise, to me at least, is to increase radius by spread<br> <TabAtkins> lea: except that it produces round from 0 radius<br> <TabAtkins> lea: this was chrome's behavior before they changed?<br> <TabAtkins> oriol: yes, firefox has a discontinuity at 0<br> <TabAtkins> lea: so maybe bc i was used to previous behavior, this makes sense to me<br> <TabAtkins> lea: is discontinuity acceptable?<br> <TabAtkins> oriol: another possibility is adding another initial value like "none" which keeps the shadow straight<br> <emilio> q+<br> <TabAtkins> fantasai: if you think about this in terms of being a drop shadow, instaed of a way to get a rounded corner outline, th eresults of "increase radius by spread" the results are clearly pretty unreasonable<br> <TabAtkins> fantasai: If you switch to current spec it looks a little more like an actual shadow<br> <TabAtkins> fantasai: the problem with current spec is the case with circles and ovals<br> <TabAtkins> lea: so you're proposing neither of these<br> <TabAtkins> fantasai: I'm proposing using current spec for first three cases, % of side in the next two, and some interp in the rest<br> <TabAtkins> fantasai: so formula i'm suggesting would be... 5th and 6th case would be current spec<br> <TabAtkins> fantasai: 7th case would get you a combo, one axis would use each<br> <TabAtkins> fantasai: second to last would be %<br> <TabAtkins> lea: I think it's hard to picture how it looks<br> <Rossen_> q<br> <TabAtkins> fantasai: yeah i can code it up<br> <TabAtkins> lea: I think we should definitely avoid that if you ahve a fully curved shape, the sahdow should have any straight edges<br> <TabAtkins> fantasai: right, that's the issue we're trying to solve<br> <TabAtkins> emilio: the othe rplace where this pops up is outlines<br> <TabAtkins> emilio: do you propose to change both?<br> <TabAtkins> fantasai: both seems reasonable<br> <Rossen_> ack emilio<br> <TabAtkins> emilio: you're right that firefox's behavior for second case doesn't make sense for shadows, but i think it makes sense for an outline<br> <TabAtkins> TabAtkins: right i think outline is like a border<br> <TabAtkins> emilio: so right now outline works like a border<br> <TabAtkins> fantasai: so there's a discontinuity at zero<br> <TabAtkins> Rossen_: spec has a cubic interpolation<br> <TabAtkins> fantasai: been in spec for a long time, chrome just implemented it and discovered problems<br> <TabAtkins> fantasai: so i think using whateer we end up for spread readius would probably look good, but i think having continuous behavior generally is also pretty good<br> <TabAtkins> fantasai: so might want to use same for both<br> <Rossen_> ack dbaron<br> <TabAtkins> dbaron: first to emilio, i'm in favor of having a single algo in CSS for expanding a rounded rect<br> <TabAtkins> dbaron: that is the direction i was pushing when i code-reviewed the patch that led to this in the first place<br> <emilio> +1 to have a single algorithm<br> <TabAtkins> dbaron: I'd like us to be consistent in inflation<br> <TabAtkins> dbaron: the othe rpoint about inflating rounded rects, is you always start fro mthe border edge and do a single inflation<br> <TabAtkins> dbaron: you never do it from another algo<br> <TabAtkins> dbaron: because inflate(10)+inflate(10) might be different than inflate(20), and certainly inflate(10)+inflate(-10) is definitely not the identity<br> <TabAtkins> dbaron: can avoid problems by starting from the border edge always<br> <fantasai> DBaron Principle of Rounded Rectangle Flation<br> <TabAtkins> dbaron: one reason to keep these consistent is people might have both at the same time<br> <TabAtkins> dbaron: if outline and shadow use different algos, that'll look bad<br> <TabAtkins> dbaron: i think we'll be okay with a single algo<br> <Rossen_> q<br> <TabAtkins> dbaron: looking thru oriol's demos, i think the best results generally come from option 2 or 3<br> <TabAtkins> dbaron: while i understand the goal was to find the right compromise between 2 and 3, i think the % options din't really work out<br> <TabAtkins> dbaron: i think the goal should be to find the right way to compromise between those two<br> <TabAtkins> dbaron: there's also the 2-variant that is what browsers did before, which has the 0 discontinuity<br> <TabAtkins> dbaron: so maybe a comp between 2v and 3<br> <fantasai> TabAtkins: next steps, code up fantasai's idea<br> <fantasai> TabAtkins: anyone with other ideas, put them in the demo as well<br> <fantasai> TabAtkins: revisit in 2 weeks to decide?<br> <TabAtkins> Rossen_: again, thanks to oriol for the demo<br> <emilio> oriol++<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7103#issuecomment-1204355391 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 3 August 2022 18:56:50 UTC