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

> From: Tab Atkins Jr. [mailto:jackalmage@gmail.com]
> Sent: Monday, December 06, 2010 5:29 PM
> To: Sylvain Galineau
> Cc: Simon Fraser; Rik Cabanier; Leif Arne Storset; Brad Kemper; www-style
> list
> Subject: Re: background-transform (Was: Re: [css3-images] Repeating
> oblique gradients)
> 
> On Mon, Dec 6, 2010 at 1:06 PM, Sylvain Galineau <sylvaing@microsoft.com>
> wrote:
> > 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.
> 
> Nothing concrete has been proposed, but the idea is pretty simple to
> imagine - something like "image-transform(<image>, <transform-list>)"
> would do the trick.

Actually, I wasn't thinking of a functional notation but yeah, same idea.

> 
> I was just saying that, so far, I haven't seen any particular use-cases
> for such a thing.  I don't doubt that they exist, but I'd rather not add
> anything to a spec that hasn't either convinced me of its usefulness or
> been pushed by browser vendors.

Well, we're a browser vendor :) It seems unlikely the WG will figure out 
whether it's useful and doable without talking about it. 

> 
> > 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>).
> 
> This seems like a straightforward application of CSS variables.  We're
> trying out a new experimental implementation of them now in Webkit.  I
> agree that, since we seem to be forming a functional language for image
> construction, we need some short way to refer to an image, so authors
> don't have to duplicate long functional expressions.

The analogy I had in mind was actually @font-face: bind a name to a resource 
and a set of relevant properties. Then use the name wherever a value of this 
type is accepted. 

Being able to use CSS properties - as opposed to a list of function 
arguments - sounds more expressive and readable. It might also fit with other 
scenarios you've brought up e.g. interopolating/transitioning between two images 
could be more natural for authors when they can specify the widths, heights and 
other properties they need on the start and end image and then just transition from 
one to the other. 

But I'm more interested in exploring adding a level of indirection than a particular 
syntax.

> 
> 
> > 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 ?
> 
> I'd probably be okay with a transformed image used in a background
> automagically altering the tiling grid appropriately.  I doubt it's useful
> to tile a transformed image as a rectangular image the size of the
> bounding box.  Or, if it is, perhaps adding a new bg-repeat keyword that
> triggers the changed behavior.
> 
> 
> > 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.
> 
> Heh, me neither.

Well, either we can defend background-transform as a one-off that doesn't set
a precedent for border-image transforms as well as other features past or 
future. Or now is a good time to brainstorm a more generalized construct.

Received on Tuesday, 7 December 2010 01:51:35 UTC