W3C home > Mailing lists > Public > www-style@w3.org > August 2011

Re: [css3-images] Resolving on gradient issues

From: Brad Kemper <brad.kemper@gmail.com>
Date: Thu, 4 Aug 2011 13:52:45 -0700
Message-Id: <C23B151C-A4C7-40DF-B793-5CBF55D47B1B@gmail.com>
Cc: Brian Manthos <brianman@microsoft.com>, fantasai <fantasai.lists@inkedblade.net>, www-style list <www-style@w3.org>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
On Aug 4, 2011, at 1:19 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:

> On Thu, Aug 4, 2011 at 12:43 PM, Brian Manthos <brianman@microsoft.com> wrote:
>> Brad Kemper:
>>> Then if the only reason to hold it back is because of the keyword
>>> disagreement, then I will be much happier to just accept the
>>> silly-sounding "downward rightward" syntax for corners, and
>>> just privately shake my head in disappointment every time I
>>> have to type it.
>> 
>> Though I'd prefer to just remove the ward suffice (going back to my original proposal), I can live with that.
>> 
>> Also I'd prefer "[leftward | rightward] || [downward | upward]" be the order in the grammar for serialization reasons.  But that can wait for another day.
>> 
>> If you ask me two weeks from now (i.e. we haven't moved on), I might withdraw my consent though.
>> 
>> What are the editors thoughts on this compromise?
> 
> I'm fairly against having "downward rightward" be a thing.  That's
> ugly and bad.  I would greatly prefer "top left to bottom right",
> despite it being a little longer.  Or "toward bottom right", whatever.

While I'd prefer "from top left", I could certainly live with "toward bottom right", and agree that it sounds better than the "wards" varieties. So if we do that, we REALLY don't need "wards" varieties for just the horizontal and vertical directions. "toward top" would work better in that case. 

PS. "to" should be enough instead "towards". It is just as clear and involves much less typing. 

> I would prefer to not address magic corner gradients at all right now.
> I believe the issues are more subtle than you guys are letting on,

I don't. 

> and could use more thought to make sure they work well and cleanly.  I
> mean, we went from "this is how corner gradients work" to "omg, *that*
> is how corner gradients work" over the course of, like, a day.  

Yes. The evidence was graphic and very convincing. 

> How do
> we know there aren't more things we might want to do?  For example,
> going back to explicitly defining the startpoint and endpoint of the
> gradient-line.  

I don't see the connection. We have something very simple and straightforward for creating a corner-to-corner gradient, unrelated to the syntax used. The newer result is always better than the old result. That doesn't mean we need to complicate the syntax to allow rarely-if-ever needed other ways of specifying endpoints. 

> As well, there are two distinct and very different
> ways of achieving the magic corner gradient that I know of (adjust the
> angle, or do the entire thing in objectBoundingBox coords scale).  

I don't know what that second one is. Just picking the better angle to accompany corner-to-corner syntax is a good win, without further complications. 

> I
> would like time to evaluate which is actually best.
> 
> I do not want to hold up unprefixing current gradients while I resolve
> the above.

I would rather you didn't shunt corner-to-corner (or side to side) syntax into a separate multi-year spec writing/approval process, when there is a good, useful solution now. I'd rather wait a week or two (or months even) for you to think it through, if that's what you need. 
Received on Thursday, 4 August 2011 20:53:22 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:43 GMT