Re: [CSS3] Some thoughts about functions, notation and gradient().

On Thu, Aug 20, 2009 at 11:11 AM, Simon Fraser<smfr@me.com> wrote:
> On Aug 19, 2009, at 9:19 AM, Andrew Fedoniouk wrote:
>
>> Brad Kemper wrote:
>>>
>>> On Aug 18, 2009, at 11:28 PM, Andrew Fedoniouk wrote:
>>>>
>>>> background-color: linear-gradient(
>>>>                    start:0% 0%,
>>>>                    stop: 100% 100%,
>>>>                    color-stop: 0% white,
>>>>                    color-stop: 50% red ,
>>>>                    color-stop: 100% blue );
>>>
>>> I think that is way too verbose.
>>
>> But human readable and machine parse-able.
>>
>> Proposed syntaxes I've seen so far in linear-gradient() are
>> not readable (that is subjective of course) and not
>> unambiguously parseable.
>>
>> That use of '/' as a some kind of separator with absolutely non-clear
>> grammatic nature is very bad.
>
> I'm strongly in favor of the more verbose, but much more human-readable form
> above. Compared to that, the current suggestions, like:
>
> linear-gradient(30px center / 50% / green -50%, wheat -30%, wheat 30%, green
> 50%)
>
> seem like complete voodoo.

I agree, but note that the syntax you highlight was a wild suggestion
thrown out by Elmore this morning.  We hit on a possible place that
could use some special syntax attention, and this is one suggestion.
Not one I favor (as I explained in my email on the gradient thread),
but still.

> In these days of auto-completing editors and authoring tools, conciseness
> isn't necessarily the primary concern. I'm much rather have a syntax that I
> can type without having to look it up, and can quickly visually scan without
> having to count slashes.

I like the idea of named arguments as an alternate syntax for CSS.
You'd have to go back and define what the names are of all the
arguments in existing modules, but it wouldn't be overly hard.

> This gradient discussion has gone on a long time, and it feels like there's
> is premature convergence onto a very non human-friendly syntax. It's time to
> step back, summarize the conversation, and boil the proposals down to a few
> contenders.

If you're mistaking the syntax highlighted above as something we're
converging on, then you're somewhat mistaken.  The current syntax of
my proposal can be found at http://www.xanthir.com/x/4bhipd.  I think
it's very stable, but I might add in something to address the cases
we're looking at right now of symmetric gradients, so that it gets a
lot easier and less error-prone to specify them.

The only major alternate proposals are the current shipped
implementation in Webkit, the current nightly implementation in Gecko,
LDB's proposal, and some modifications to my proposal from Brad.  You
can get information on the Webkit and Gecko versions from the web.
Brad's proposed changes are the following:

1. For angles, drop the bg-position and the inside/outside.  Leave
only the angle.
2. For the other construction, drop the bg-positions, and specify just
a side or a corner.
3. Add a second slash into the color-stop list, such that anything
that comes after this second slash measures from the end rather than
the beginning.

LDB's proposal was to incorporate the start/stop point into the
color-stop list, so the first and last color-stops had a full
<bg-position>, and the middle stops just had a length/percentage.
This syntax has some definite advantages in simplicity (nothin' but
stops!), but it loses on its inability to specify an angle and have
the end-point determined implicitly.  (The proposal from Christopher
to add in an angle to the end stop I find produces a very confusing
syntax.)

Every other alternate idea has either been generally rejected, or
incorporated into my draft in some form.

~TJ

Received on Thursday, 20 August 2009 16:58:40 UTC