Re: [css3-images] Summary of recent gradient issues

Welcome aboard Divya.


On 18/06/2011 3:34 AM, Brian Manthos wrote:
> On 18/06/2011 2:15 AM, Brad Kemper wrote:
>> On Jun 17, 2011, at 7:02 AM, divya manian wrote:

> I'm not clear who's saying which in the original mail, perhaps we
> need a W3C spec for e-mail applications.


This is what I have also been trying to suggest to you Brian. BTW, I 
have restored the correct depth in the thread so you know who said what.


> I'll try to address the assertions generally.
>
>
>>> I also think CSS authors are familiar by now of the top, right,
>>> bottom, left keywords. This intuitively suggests the beginning
>>> position.
>
> You're welcome to that position.  I disagree.


Fantasai has suggested feedback from authors (this goes back to 2007). I 
have been one of a few authors who have dared to express an opinion on 
this list many times over and I am one of a few authors who has a very 
good understanding and comprehension of CSS and the CSS spec which has 
allowed me to have survived for so long (4 years and counting).

Maybe it is time for those in the CSS WG and implementers to step back 
and give people who have authored CSS a chance. Especially since this 
whole thread is about changing angle values in linear-gradient so they 
work gracefully with transition and animation.

This is Divya's first post on this list. I hope that the response 
(welcoming) she has received doesn't make her hesitate in providing 
future feedback.

On a side thread [1] to this one, it was via Tab's feedback that I was 
to really understand how gradients with both keywords and angles work 
(which was counter to my expectations). I have initially seen them as 
working much like dimensionless SVG but now I know that gradients only 
work on one course or path.


> For linear gradients,
> the three key elements are color stops and {start, stop} locations.
> The current syntax (WD, ED 1.08, and ED 1.07) choose to omit either
> the start or stop location.  In the absence of that, an "almost as
> expressive" alternative is to treat the two key elements as color
> stops and direction.


This is where you wrong. Stop see this as something heading in a 
direction. The _from_ here _to_ there is along a course or path. See the 
beginning of such a path as an initial point from where to begin since 
this works with so many other CSS properties and values. Please remember 
that linear-gradient has to work in vertical writing mode. CJK and 
Mongolian has logical left at the visual top of the viewpoint and 
logical right at the visual bottom of the viewport. This means that any 
angle or keyword(s) in a linear-gradient are rotated by 90 degrees 
clockwise in vertical writing mode. The start (left) and ends (right) 
points of a linear-gradient go from the visual top to the visual bottom 
of the viewport or a box.


> As an expression of direction, the keyword
> syntax prior to 1.08 is opposite that of the angle syntax in
> expressing direction -- fixed in ED 1.08 version.
>
>>> Using the 'to' keyword would beg the question, why there is no
>>> equivalent 'to' keywords elsewhere in CSS (also should there be a
>>> 'from'?).
>
> Perhaps this is an oversight, perhaps it's because gradients
> represent some new concept.
>
> Perhaps it's because the "to" keyword is imbedded in abbreviations
> such as "LTR" and "RTL".
> http://dev.w3.org/csswg/css3-writing-modes/#direction
>
> If you prefer the "precedent must be correct" approach to design,
> then perhaps we should use the following: LTR RTL TTB BTT etc.


No. These are both indicative of both inline base direction and block 
flow progression.


>>> I think it introduces additional complexity that could be avoided.
>
> Apparently it can't be avoided, because there are enough people that
> prefer "to right" over "rightwards" or "right" (as end point).


Who are these people? I believe the overall consensus _from authors_ was 
that the keyword indicated the start point. On what horizon does the sun 
rise. Most people would say from the east. On what course or path does 
the sun appear to travel in? Most people would say westward.


>>> In my view, this:
>>>
>>> linear-gradient(top left indianred, 50%
>>> midnightblue, right mistyrose); would be something that would be
>>> understandable, given we make similar assumptions of default
>>> keyword values for background-position
>>> http://dev.w3.org/csswg/css3-background/#the-background-position
>
> Once again, the position argument returns.


And this is one argument that I haven't even had time to raise.


> Unless you are expressing
> two positions, you haven't expressed a direction.


There is no direction. These are positions of offset. Anyway, for a 
background-image to begin from the top left corner and goes to center 
would require the animation of two values.

  background position: 0% 0%  --->  background position: 50% 50%


> So the argument
> that you can omit one and be clear is incorrect.


That doesn't make sense to me. A change of angle in linear-gradient is 
rotation on the z-axis. Only one value has to be changed.


>>> linear-gradient(top left indianred, 50% midnightblue, right
>>> mistyrose);
>
> This seems cumbersome because you now have two places to spec start
> and stop locations and there's now a blending with stop location and
> end point.
>
> This is a bit more acceptable in my book: linear-gradient(top left,
> indianred, 50% midnightblue, mistyrose, right);
>
> But it's not quite there, because it's introducing a new case that
> the spec currently doesn't deal with "top left to right".  Avoiding
> that for now you get... linear-gradient(top left, indianred, 50%
> midnightblue, mistyrose, bottom right); or linear-gradient(top,
> indianred, 50% midnightblue, bottom); and prior discussion on this
> thread had (to my recollection) pushed back on the "specifying both
> start and end point" as cumbersome.


I think this would be a use case for rotate background tile which Brad 
and I have requested. I mentioned it last night in another part of this 
thread [1].

It would work somewhat in this manner.

<!doctype html>

<style type="text/css">
#box {
   width: 200px;
   height: 200px;
   overflow:hidden;
   border: 10px solid #777;
}
#box div {
   background: -webkit-linear-gradient(0deg, indianred, midnightblue 
110px, mistyrose 220px, red 221px, mistyrose 222px);
   background: -moz-linear-gradient(0deg, indianred, midnightblue 110px, 
mistyrose 220px, red 221px, mistyrose 222px);
   width: 300px;
   height: 300px;
   margin-left: -40px;
   margin-top: -30px;
   -webkit-transform: rotate(26deg);
   -moz-transform: rotate(26deg);
}
</style>

<div id="box"><div></div></div>


(this is where Brad's reply begins)

>> Another example is 'vertical-align:top' versus
>> 'vertical-align:5px'. With the unit measurements, it is understood
>> to be "from the baseline". With the keywords, it is essentially
>> "from the edge described by the keyword" (as in linear-gradient
>> working draft). I've never heard of this causing even the slightest
>> confusion, and I rather have consistency with these than to try to
>> build in some sort of new link between the starting alignment
>> keyword and the unit measurements.
>>
>> Far more confusing is trying to understand the difference between
>> 'vertical-align:top' vs. 'vertical-align:text-top'. If you can
>> learn that, then you can also learn that 'left' is a starting
>> position for linear-gradient and not an end position.
>
> My interpretation: "Weird, confusing stuff happens in other parts of
> CSS, so that should be precedent for doing more of it."


What? Please no. I get my x and y axis often confused since margin and 
padding shorthand with two values are revered from background-position, 
etc. with two values.

>
> I disagree completely.


To the weirdness? You have lost me here Brian.


[1] http://lists.w3.org/Archives/Public/www-style/2011Jun/0454.html



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

Received on Saturday, 18 June 2011 02:48:34 UTC