Boris Zbarsky wrote:
> Vladimir Vukicevic wrote:
>> * Is preserving some ability to still do gradients using images on
>> non-Gecko browsers worthwhile?
>
> Yes. In fact, I'm a little concerned about exposing this to non-chrome
> code in general if we suspect that this will never get interoperably
> implemented; having content depending on Gecko-only features is really
> not something we should be trying to encourage, imo. If we _do_
> introduce such features (and I agree that there is a very compelling use
> case for gradients), I think we should make it possible to use them in
> ways that degrade gracefully.
Ok, I agree.
> I looked at the www-style archives briefly, and one proposal that seems
> to have been made is allowing something like:
>
> gradient(...)
>
> as a value for <color>. I'm not sure how happy we can make the syntax,
> but if we did something like that, then:
>
> * Gradient clearly replaces the background color.
> * Fallback is easy:
>
> background: url(image.png);
> background: gradient(....);
Yep, that would work; syntax might be ugly, if we want to support the
full expression, but for simple use something like:
background: none gradient(horizontal red green blue);
seems pretty sane to me. If we want to introduce more () into the
parsing, the complex version doesn't have to be too bad:
background: none gradient(line(50%,40%,30%,50%) stop(red,0.2) green
stop(blue,0.8));
Or even line(50% 40% 30% 20px) to get rid of the commas; stop() is
optional, and if not specified a color name is assumed to lie midway
between the two points on either side. Within stop() the offset is
specified as a number where 0.0 is the point specified by the top and
left coordinates, and 1.0 is at the point specified by the bottom and
right coordinaes. The offset is optional, stop(green) would be the same
as just "green". Offsets less than 0 are considered to be from the
top-left point away from the bottom-right; greater than 1 are from the
bottom-right point away from top-left (that is, the points define a
line, and the offset determines a point along that line where + is
moving from top-left to bottom-right).
How's that sound?
> * Gradients are not a priori limited to backgrounds (though I'm not sure
> how easy it would be to do them with text, etc, so we may want to only
> parse it for background-color).
Yeah, we can do them with text with cairo, but I think that's a more
complicated beast as far as getting the right bits to the right spot
goes; I don't really want to tackle that now. The only reason why I'm
bringing this up for backgrounds is that it would be trivial to
implement the rendering portion, as long as we can come up with a way to
specify the necessary arguments.
I don't know how this would interact with dbaron's css-vg proposal; that
proposal looks quite sane, but it's also significantly more complex than
I want to bite off for 1.9. If we were to implement a gradient() (or
-moz-gradient() or something), would that mesh acceptably with the
css-vg proposal should we implement something like that in the future?
The syntax for gradient() could become the syntax for the gradient
property of a fill, maybe.
- Vlad
_______________________________________________
dev-tech-layout mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-layout
