Re: generators in filters (or maybe even "anywhere there are images")

On Wed, Apr 20, 2011 at 12:12 PM, Dean Jackson <dino@apple.com> wrote:
> On 20/04/2011, at 11:44 AM, Tab Atkins Jr. wrote:
>> On Tue, Apr 19, 2011 at 6:14 PM, Dean Jackson <dino@apple.com> wrote:
>>> Then I was thinking that these generator effects are similar to other parts of CSS, in particular gradients. There have been some proposals in this area. For example:
>>>
>>> - WebKit's -webkit-canvas value, which allows an element to use a canvas element as an image in background, border, whatever.
>>> - Mozilla's -moz-element, which does the same but with the rendering of any element
>>>
>>> Examples of generators may be:
>>>
>>> - checkerboards
>>> - stripes
>>> - noise
>>> - star shines
>>>
>>> They don't sound too useful in isolation, but graphics artists may feel otherwise. Anyway, the important part of this message is the 3rd paragraph. I don't want to complicate the syntax or implementations. "SVG" filters provide the functionality, so it definitely isn't essential.
>>
>> Yup, these are just generated images, and should probably be defined
>> in the Image Values module.
>
> Excellent. Are you responsible for that spec? And will you take this on - whatever that means, maybe an email to www-style?

Yes, and yes.


>> Of the existing Filter primitives that do this, feFlood is already
>> doable with the image() function (just doing "image(blue)" produces a
>> pure-blue image, because it's the fallback color for an empty list of
>> image declarations).  feImage is done with the url() function.
>> feTurbulence is something we should add, as perlin noise is really
>> useful to add a bit of non-uniformity to designs (I've seen a lot of
>> recent stuff where a design is done just with gradients, but with a
>> noise image laid on top); it should probably be a perlinnoise()
>> function or something.
>
> I think noise() or turbulence() are good names. I don't see a need to be so exact unless we're going to add multiple algorithms.

Okay.


>> Stripes are already doable with linear gradients.  It turns out that
>> you can get a checkerboard with just two linear gradients combined
>> together <http://leaverou.me/css3patterns/>.
>
> I'd suggest a new value for this. Just because it is possible doesn't mean we should encourage it. Do you see a chessboard and think "oh, overlapping rotated repeating gradients with hard edges"?

I don't disagree; the patterns on that page are all pretty non-obvious
at first, until you realize that it's just (ab)using gradients to
build things out of right triangles.  The only real question is if
checkerboards are a useful enough image type to bless with syntax.
I'll bring this up in a separate thread.


>>  I dunno about
>> haloes/star shines, but I'm not averse to them if they're useful.
>
> It's not terribly common, but I can imagine people wanting to bling-up their site header with a little sunburst (which animates across the text as the drop shadow moves in sync). Or use <blink>.
>
> But I'm a big fan of starting small, especially if you know that you're not making enhancements hard to add at a later stage. So probably no need for this now.

Kk.  Yeah, new image types aren't hard from a spec standpoint.  It's
just a question of what's performant to generate with platform
libraries.

~TJ

Received on Wednesday, 20 April 2011 19:52:39 UTC