- 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