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

On Thursday 2009-08-20 11:57 -0500, Tab Atkins Jr. wrote:
> On Thu, Aug 20, 2009 at 11:11 AM, Simon Fraser<smfr@me.com> wrote:
> > 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.

I wouldn't mistake convergence of a small number of people for
convergence.

The more you write, the fewer people will read it.  This is as you
should expect.  I have completely lost track of the discussion
because there have been too many messages in it for me to keep up
with (and large numbers of messages with too much quoted material).

However, I'll take this as an opportunity to give my thoughts on the
current document.  (It would be really nice if the current version
I'm commenting on were archived somewhere, though, so that this
discussion would make sense when people read it later.)


I don't like the use of '/' as a delimiter; it feels to me that if
you're writing something like:
  a / b, c, d
the natural grouping of that syntax is:
  (a / b), c, d
whereas in this draft it means:
  a / (b, c, d)
I'd prefer replacing the '/' with ',' over the current syntax,
though I'd also be open to better alternatives.


I don't know why you chose the default starting point for <angle>
without <bg-position> to be one of the box's corners.  This leads to
asymmetric results for both 'inside' and 'outside'.  Why not say
that the gradient line is symmetric around the center of the
background positioning area, at the given angle.  For inside, the
length of the gradient line would be the length that touches the
edges of the background positioning area.  For outside, the length
of the gradient line would be the longest length such that the
perpendiculars to the ends of the gradient line intersect the
corners of the background positioning area.  (Longest because there
are shorter such lengths, but they intersect the wrong corners.)

Given that, I'm not sure what the use case is for <bg-position>
<angle>.  I think it makes more sense to use an angle with zero
points or two than it does with one.  (Using an angle with two
points would follow the same rules as using it for zero, except
using the rectangle formed by those two points instead of the
background positioning area.)

But I suspect I may have missed something in all those messages I
haven't read; feel free to point me to the relevant use cases (or,
even better, add an example to the document showing why the current
approach is better).


I also fear that the syntax may be too compact and thus unreadable,
but I'm also not sure that there are any alternatives that I prefer.


The proposal also needs to address radial gradients at some point.

-David

-- 
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/

Received on Thursday, 20 August 2009 17:25:53 UTC