Re: [css3 images] WD gradients review notes

On Thu, Sep 8, 2011 at 1:09 PM, Brian Manthos <brianman@microsoft.com> wrote:
> http://www.w3.org/TR/css3-images/#gradients
>
> No major issues.
>
>
> 5.2.1, prose in the “Color-stops are placed…” paragraph
> # Negative distances are allowed in a radial gradient and work
> # the same as in linear gradients with respect to setting the color
> # of the gradient-line, but colors before the starting-point of the
> # gradient-line are not displayed.
>
> A. I think of them as “locations” not “distances”.  I’m not married to it,
> but I find the term “distances” confusing in this context.

I was never very happy with that word either, but my brain wouldn't
cough up anything better.  "locations" it is.

> B. My interpretation of this phrasing suggests that “negative distances” in
> a linear gradient *are* displayed.  I’d like to see an example where that is
> the case.

The way that 0% and 100% points are calculated on a gradient, you
never see anything beyond them currently.

However, future work will give the possibility.
"background-repeat:extend" is a proposal for B&B4 for displaying the
parts of images that fall outside the concrete image size, which will
let you see the colors beyond 0% and 100%.  The way I'm expecting to
spec gradient transitions will also expose slightly outside the bounds
sometimes.  (Shane Stephens has done work on this, and currently the
best-looking transition we can produce involves transitioning the
angle and length of the gradient-line directly, rather than just
transitioning the angle and letting the length be calculated
automatically from it.)


> 5.4, Example XX
> This example is inconsistent in the number of equal signs between pre and
> post “fixed-up” examples.  That’s not an inconsistency worth quibbling
> about.  But, upon noticing that I hit upon another thought…
>
> C. Consider replacing  “==” and “===” with “=1=>”, “=2=>”, “=3=>”, “=12=>”,
> “=13=>”, “=123=>”, and “=23=>” to explicitly indicate which rule(s) were
> involved in the conversion.

Good suggestion!


> 5.4, Example XX
> # 4. linear-gradient(red -50px, white, blue)
> #   ===
> #   linear-gradient(red -50px, white calc(-25px + 50%), blue 100%)
>
> D. This is the first and only reference to calc() within the context of
> gradients in the entire module.  I’m fuzzy on whether we consider the
> examples normative or not.  Either way, it would be good to be explicit
> somewhere in the module regarding how calc() percentages should behave.

The examples simply show the result of *manually* applying the fixup
rules (as stated in the example's introductory text).  However, I can
put in an explanatory note that authors may not observer that value in
browsers, as it will already be resolved into px when they retrieve it
from getComputedStyle().

The definition of calc() seems explicit in how percentages are treated
already - it's the same as however a bare percentage would be treated
in that context.


> My understanding is that gradient calc percentages resolve as follows …
> D1. <color-stop> (all 4 flavors): percentages resolve relative to the length
> of the gradient-line (segment)
> D2. <angle> (both linear flavors): percentages invalid
> D3. <position> (both radial flavors): match background-position behavior
> D4. <length> (both radial flavors): the same as <percentage>
> D5. <percentage> (both radial flavors): the same as without the calc()
> wrapper

Yes.  In all of those, calc(5%) is identical to 5%.


> 5.4, first Note
> # For example, the rule ‘background-image: linear-gradient(red, yellow
> 100px, blue 50%)’
> # would work as expected as long as the background area is at least 200px
> tall.
>
> E. I find the phrasing “as expected” confusing here, rather than helpful.
> If implemented correctly by the UA, everything should work “as expected”.
> Recommend replacing “work as expected” with “require no fix-up”.

Sounds good.

~TJ

Received on Thursday, 8 September 2011 21:29:52 UTC