Re: [css3-images] Resolving on gradient issues

On Aug 4, 2011, at 10:37 AM, Brian Manthos <brianman@microsoft.com> wrote:

> I think we've got general agreement that the "magic" rendering is better than the WD rendering.  As such, when corner-gradients-via-keywords is reborn we should probably shift to that -- probably for CSS4.

I see no reason to delay, if that plus words-to-use-for-keywords is the only thing holding up diagonal gradients. 

> The syntax of corner-gradients-via-keywords was troubling enough that Tab recommend @ the F2F that we push the whole topic to CSS4 rather than begin another round of syntax discussions on the topic.  The general murmur in the room seemed to grudgingly agree, IMO.

A little bit of murmuring does not equal a resolution. I would have voted against such a resolution if it had come to a vote then. I see no reason to delay. Putting of the keyword for diagonals situation until later just makes it less likely to ever get reasonable keywords for that, because it just means that Tab can pick words that don't have to work well in combination with each other, which is exactly what he did. Do we really think that we can't get good enough keywords in the time it takes to get to CR, but that we are going to get better result by avoiding the problem until after the 'wards' keywords can no longer be changed? That's a screwy way to try to achieve acceptable results. Sounds more like process manipulation to me. 

> I didn't code up the rendering adjustment discussed for 3 reasons: (a) IE10's prefixed corner-to-corner currently matches the February WD rather than some hybrid draft, (b) not committing coding resources to theories as opposed to official spec changes,

OK. I thought I heard something different. 

> and (c) as per the above it's likely pushed to CSS4 as part of moving CSS3 Gradients to CR.

I don't know how likely that is. Tab announced his desire to do that, there was some murmuring, and then the conversation shifted. 

> A, B, and C noted -- it's fortunately a fairly straightforward algorithm when/if we do opt for it (in CSS4?).

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. 

> Side-note: The cover/contain description aligns with what I was saying a few weeks ago about how the current radial syntax allows for closest/farthest side/corner (where two of them map to cover and contain) but linear doesn't offer such options.

I didn't want to get into that yet, but mist of the actual samples I've looked at on the Web of radial-gradient use do not bother with any keyword at all. They just use the default and start in with a color stop list. And typically the last stop is less than 100% if it is not intended to extend outside the box, and background size and position are used heavily. 


> Upward/Downward vs. Up/Down discussion - I have no strong opinion, except to say this is part of the reason why I argued that "left" is also a direction and thus "left" meaning "go away from left" is backwards and troubling.  

I think that are understood by everyone on this point.

Received on Thursday, 4 August 2011 19:31:05 UTC