RE: background-transform (Was: Re: [css3-images] Repeating oblique gradients)

I didn't think there had been a proposal either. But without one I don't expect much arguments for/against so I assumed Tab implied something had been proposed without getting much traction.

I was actually

>From: Simon Fraser [mailto:smfr@me.com] 
>Sent: Sunday, December 05, 2010 10:26 PM
>To: Sylvain Galineau
>Cc: Tab Atkins Jr.; Rik Cabanier; Leif Arne Storset; Brad Kemper; www-style list
>Subject: Re: background-transform (Was: Re: [css3-images] Repeating oblique gradients)

>On Sun, Dec 5, 2010 at 5:32 PM, Sylvain Galineau
><sylvaing@microsoft.com> wrote:
>>>I don't mind proposing a syntax but as it seems obvious - to me
>>>at least - I assume it has been considered before. I'm mostly
>>>curious as to why we're not considering this. Or why not now ?

>>I haven't seen sufficient argument as of yet for including it.  I can
>>be convinced, of course, with some assurance that it would be
>>implemented.

>>>Can you link to the relevant proposal and the feedback ?

>I don't believe there has been a concrete proposal. I presume you are thinking of something like a functional notation for images, >like:

>  alpha(url(foo.png), 50%); // make the image 50% transparent
>or
>  transformed-image(url(foo.png), rotate(45deg)); // rotate the image

I didn't think there had been a proposal either. But without one I don't expect much arguments for/against so I assumed Tab implied something had been proposed without getting much traction.

I was actually thinking of an at-rule which maps a name/ident to an image URL and properties that should be applied to this image when the name is referenced e.g. transforms, opacity, width/height...Then background-image, border-image, cursor-image et al. could just use image(<ident>).

>I think there's a significant different between this something like background-transform: I see background-transform as affecting >the background image tiling grid. I would assume that the bounds of an image described as

>  transformed-image(url(foo.png), rotate(45deg));

>would be the bounding box of the rotated image, but this would not affect the orientation of the tiling grid, so you'd end up with >a diamond grid here.

That sounds fine. But I'm not sure whether/how transforms affect the image size used for background tiling implies the transform needs to be specified through a dedicated background transform property ? Or do we expect that would be true for backgrounds only ?

>>Duplicating properties of interest for images across background, 
>>border images and every other feature that accepts an image URL 
>>seems to be the kind of redundancy a module named 'Image Values' 
>>would be written to address. 

>I agree, but I don't see too much harm in new properties which share values with existing ones; that's better than a new property >with a whole new set of values to learn.

If one can demonstrate that :
1) background images are a special case that needs its own duplicated transform property, and/or 
2) that it is not useful/too difficult to generalize image references so that image resources can be styled once and referenced across a stylesheet without repeating properties or functional expressions...

...then I might agree this seems reasonable. But it'd be helpful to at least have the conversation imo. Until then it seems we might be discussing the need for a border-image transform property a year from now and I'd rather not do that.

Received on Monday, 6 December 2010 21:06:44 UTC