W3C home > Mailing lists > Public > www-style@w3.org > October 2013

Re: [css-shapes] Positioning <basic-shapes> summary, v2

From: Alan Stearns <stearns@adobe.com>
Date: Tue, 29 Oct 2013 18:54:55 -0700
To: fantasai <fantasai.lists@inkedblade.net>, "www-style@w3.org" <www-style@w3.org>
Message-ID: <CE95B266.149D8%stearns@adobe.com>
On 10/29/13 6:22 PM, "fantasai" <fantasai.lists@inkedblade.net> wrote:

>On 10/29/2013 06:10 PM, Alan Stearns wrote:
>> On 10/29/13 5:51 PM, "fantasai" <fantasai.lists@inkedblade.net> wrote:
>>> While I'm sympathetic to the scheduling concerns, I think it's more
>>> responsible for us to hold up the specs for an extra month or two
>>> to resolve these issues to provide the best feature design for authors,
>>> than to increase the amount of syntactic options and backwards-
>>> compatibility concerns they have to juggle just because we wanted to
>>> ship Masking a few weeks earlier.
>> I agree, but that's why I listed this one last. The more important thing
>> is whether we accommodate both SVG and CSS syntax and percentage
>> interpretation at the cost of some duplication, or if we decide to only
>> include CSS syntax.
>If we could allow for positioning conventions in a way that
>syntactically made it obvious why you should use one version
>vs. the other, I'd be happy with that. For example rectangle()
>and inset() both create rectangles, but inset() indicates by
>its name in what way it's different from rectangle().
>In the proposal you have right now, there's no clue why there
>are two very different syntaxes and that the difference is
>in how percentages are handled.
>The result is two inexplicably different syntaxes for doing
>pretty much the same thing, plus a lack of clue in what way
>they are functionally different.

That's a fair point. I was thinking the 'at' keyword was a sufficient
marker, but that's obviously just because I've been following www-style
for the past few years. The radiant gradient discussion is indelibly
seared into my memory.

Perhaps the current set of functions (aside from inset) could add 'svg-'
to the name? That would allow rectangle(), circle() and ellipse() to use
the CSS conventions once we've worked out the details. You're probably
going to reply that svg-circle() and svg-ellipse() are silly duplications,
but I still think there's value in having a consistent set of x,y
functions for those that like that sort of thing.


Received on Wednesday, 30 October 2013 01:55:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:51:03 UTC