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

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 10 Aug 2011 19:21:17 -0700
Message-ID: <CAAWBYDB6aMKu+JYBagDGvgqtsVAM0UPjc+eWFHK4-WK159jqdg@mail.gmail.com>
To: Alan Gresley <alan@css-class.com>
Cc: www-style@w3.org
On Wed, Aug 10, 2011 at 6:48 PM, Alan Gresley <alan@css-class.com> wrote:
> 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);

I don't understand the significance of the transform to this case.  If
you prefer using a keyword to indicate the starting point rather than
the ending point, that seems independent of whether the element is
being rotated by a transform.  Is there something I'm missing, or is
this just a statement that you prefer indicating the starting-point?


>> 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?

Please read the "Gradient Magic" thread started a few weeks ago.  It
seems that the behavior described therein in manifestly better than
the previously-described behavior for corner-to-corner gradients.


>> 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.

Sorry, this was a little clearer in the call.

The idea is that an animation is rendered by referencing the start and
end state and the current completion percentage.  If the size of the
box changes, such that the start or end states would have been
different, the animation is changed accordingly at the next update.

This isn't specific to gradients; it's a general issue with
animations.  Run this example to see the effect in action:

<!DOCTYPE html>
<style>
div { height: 30px; }
#foo { -webkit-transition: width 1s linear; width: 50%; background: green;}
#bar { -webkit-transition: width 2s linear; width: 50%; background: blue;}
#foo:hover { width: 90%; }
#foo:hover > #bar { width: 10%; }
</style>
<div id=foo><div id=bar></div></div>


>> 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?

I'm referring to images in general, which cant' be
animated/transitioned currently.


>> 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.

Your statement doesn't make sense.  "0deg" and "top" have *never*
meant the same thing.  Right now, "to top" and "0deg" are the same,
but in the older definition (where keywords specified the starting
point), "0deg" and "bottom" were the same.

"0deg" has never meant "start at the top and go down", as you seem to
assume in your statement about the preferred rendering of your
example.  It originally meant "start at the left and go right right"
and now means "start at the bottom and go up".


>> 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?

I'm specifically talking about referring to corners of a box via
logical directions.  I think start/end are pretty easy to understand.
before/after don't show up 2.1, though.

In any case, it's not a huge deal to me.


>> RESOLVED: Publish next WD with 'to <keyword>' syntax
>
> But with 'to end'.

Yes.

~TJ
Received on Thursday, 11 August 2011 02:22:04 GMT

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