- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 3 Oct 2013 14:03:53 -0700
- To: Alan Stearns <stearns@adobe.com>
- Cc: fantasai <fantasai.lists@inkedblade.net>, "www-style@w3.org" <www-style@w3.org>
On Thu, Oct 3, 2013 at 1:26 PM, Alan Stearns <stearns@adobe.com> wrote: > Needing to add this keyword is the most compelling argument for me for not > changing the <basic-shape> arguments. I remember how long and furiously we > argued over 'at', and I'm not looking forward to arguing over what to use > here. Optimizing for spec-author comfort isn't the right choice. :/ > Has there been previous discussion that I've missed about adding > border-radius to the border shorthand? Wouldn't that require the same > keyword as we're discussing here? Not that I know of. But yes, we'd need something like this keyword to disambiguate. > And given that border-radius has > additional functionality we haven't yet allowed for shapes, I think we'd > need to do something like this to be consistent: > > rectangle( <size>? [ at <position> ]? [ radii <radius>{1,4} [/ > <radius>{1,4} ]?] ) Hm, there's a conflict here between hewing close to SVG and matching up with CSS. I'm not sure which way makes more sense. > I'm liking the simpler rectangle() syntax more, the more I look at this. I > agree that the above gives more expressive power, but I'd rather define a > path() function to allow defining more complex shapes directly than > bashing a rounded-corner rectangle into shape. Well, that would just give us SVG's path syntax, right? That would provide different functionality. (I haven't decided on my own opinion yet.) ~TJ
Received on Thursday, 3 October 2013 21:04:39 UTC