[css3-images] gradients keywords and logical (Re: [CSSWG] Minutes and Resolutions Telecon 2011-08-10)

On 11/08/2011 9:28 AM, fantasai wrote:

> TabAtkins: Other issue is gradient keywords, i've now set the keyword
> 'to' and either a side or corner
> TabAtkins: e.g. 'to bottom left'
> TabAtkins: Put keywords back and made corners magic
> Florian is happy with this too
> smfr: I think it's ok, but why not use 'from' and make the 'from'
> optional so we have compat with the old syntax?
> TabAtkins: Using 'from' rather than 'to' would give the opposite
> directionalitiy thing that confused people
> smfr: Only some people
> TabAtkins: Since we're changing behavior for corner to corner, so ...
> fantasai: I think this is also confusing, with 'to left' I'm not sure
> whether a fixed-length gradient is attached to the left or
> right edge -- I would guess left edge
> Florian: Think this is good enough


If I have this markup,

   <div><div>...</div></div>

and this CSS.

   div div {
     transform: rotate(45deg);
     transform-origin: top left;
     background: linear-gradient(keyword keyword, white, blue);
   }


On the rotated inner box, I want the gradient going from corner to 
corner beginning from the visual left with white and ending on the 
visual right with blue. I would expect to use these keywords.

  (since I already have _transform-origin: top left_).

     background: linear-gradient(bottom left, white, blue);


and not this.

     background: linear-gradient(to top right, white, blue);


Once you start rotating elements with transform origin, you can end up 
using keywords to indicate corners.


> fantasai: Another question is animating the gradients, given corners
> aren't equivalent to angle gradients anymore?


Which makes no sense.


> TabAtkins: They're still equivalent
> TabAtkins: It's just a different angle computation


Can you please explain this Tab? Can you please explain why current 
prefixed behavior should change for keywords?


> bradk: Does the spec take into account that changing the angle changes
> if the box size changes?
> TabAtkins: yes. More details to in css4-images -- I pushed animations
> out of L3


You seem to have some mental model but more details will appear in 
css4-images.


> bradk: How is it defined now?
> TabAtkins: Right now images aren't animatable at all, rules are pushed
> to L4


I believe Brad and talking about angle and keyword gradients, not 
images. BTW, is this image() that you are referring to Tab?


[snip]
> plinss: Back to keywords issue
> fantasai: Would like to push to WD and see if we get any comments


I'm formulating a true rational now that incorporate css3-color and 
ccs4-color so expect comments from me.


> bradk: I like what's happening in linear gradient, still trying to give
> full review to radial gradients
> bradk: Not ready for LC yet
>
> Florian: The default for linear gradients has been downward for a long
> time, which is now either 'to bottom' or '180deg'
> Florian: Usually default is 0deg or top
> TabAtkins: He's suggesting that we flip the default around they colors
> start at the bottom and go upward
> TabAtkins: I don't have a problem with this, but don't have a particular
> reason to change. It's been default for awhile
> bradk: Fallback is still reasonable, because we're changing the syntax
> fantasai: We're not changing that part of the syntax
> fantasai: I think the default should stay. I think from the top makes
> the most sense


I believe it makes sense for the default to be '0deg' and 'top' but not 
'0deg' and 'to bottom'. So in other words, this CSS,

     linear-gradient(white, blue)

will show white at the top and blue at the bottom as is currently seen 
in all UAs that support the modern syntax.


> bradk: Wouldn't changing it mess up prefixed versions?
> fantasai: dbaron already said he won't do that
> plinss: In general we're not going to not make a good change to a property
> because of prefixed versions
> plinss: If it doesn't matter much, sure, but in general don't want to
> consider prefixed versions
> Florian: Since there's no consensus to change, let's leave as-is
> smfr: Mark as an issue?
>
> smfr: Do we need direction keywords that are writing-mode-aware?
> Florian: And bidi-aware, too
> Florian: Should we add that to writing-modes?
> fantasai: No, belongs in the appropriate module. writing-modes only
> deals with CSS2.1 issues directly
> TabAtkins: Could add them. Although the keywords are a bit weird, e.g.
> 'to start before'.


Are margin-start, padding-start, or text-align: start confusing?


> TabAtkins: Would like to see some examples of this
> bradk: Gradient from black to white from top to bottom, and reversed-color
> headline at the top
> fantasai: Example of sidebar menu items with horizontal gradient that
> fades out towards the end edge. Would want that logical as well
> Florian: [something about writing modes dependency]
> TabAtkins: Don't believe I need any keywords from writing modes
> TabAtkins: Could maybe refer to 2.1
> <florian> Yes
> fantasai: Nothing in 2.1, but if it becomes an issue we could pull out
> a glossary from writing-modes and publish it as a WG Note or
> something
> RESOLVED: Add logical keywords to gradients
> RESOLVED: Publish next WD with 'to <keyword>' syntax


But with 'to end'.


<p>...</p>


p {
   text-align: start;
   background: linear-gradient(to end, white, blue);
}

or

p {
   text-align: end;
   background: linear-gradient(to start, white, blue);
}




-- 
Alan Gresley
http://css-3d.org/
http://css-class.com/

Received on Thursday, 11 August 2011 01:48:56 UTC