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

> From: Tab Atkins Jr. [mailto:jackalmage@gmail.com]
> Sent: Monday, December 06, 2010 6:59 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 5:51 PM, Sylvain Galineau
> <sylvaing@microsoft.com> wrote:
> > From: Tab Atkins Jr. [mailto:jackalmage@gmail.com]
> >> On Mon, Dec 6, 2010 at 1:06 PM, Sylvain Galineau
> <sylvaing@microsoft.com>
> >> wrote:
> >> 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.
> 
> Oh, of course.  Do you think it's useful?  If so, would you mind
> dredging up some use-cases for transforming images in-place?

The apparent bias of the question is puzzling: 'dredging' ? Aren't we
talking about transforming background images in place ? Isn't that a 
use-case ? Assuming it is, why are backgrounds a special case ? 
Why is applying transforms to background images a use-case but not 
adding other styling effects to these same images e.g. if I want my 
background image to tile with some opacity and a thin border around it, 
why do I need to create a different image resource that includes those
effects ? 

It's not up to me to 'dredge up' use-cases. It's up to those who propose
background-transform to argue why the combination of background images
and transforms is such a special case it deserves its own dedicated
property. 

Again: I'm 100% in favor of allowing the transformation of background images. 
But I'd like to clearly understand why background images and not other image 
resources present and future ? And why only transforms and not other effects 
authors might well want to apply to background images as well ?

Note: thinking about this more I think Simon's point about the need to adjust
the image's bounding box applies everywhere you'd want to transform images in
place. (border-image, content property...)

> 
> 
> >> > 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.
> 
> Oh, hm, that does sound potentially useful.  Conceptually, we can
> pretend that we're setting properties on an <img> element or
> something, and then extracting the image back out to use elsewhere.
> That's a good argument for a specialized @rule.
> 
> While I don't think that *right now* there's sufficient use to define
> such a thing, if we decide that transforming images is useful, that
> would be enough for me to support defining this.

It's interesting that you're both in support of background-transform and
dubious about the utility of transforming images...I guess you agree 
the combination of background images and transforms is unique. If so, why ?

An image at-rule is nothing more than an alternate syntax for the image value 
type you've specified. So I'm not sure how one can push back on one on use-cases 
grounds without also pushing back on the other. The general set of use-cases 
is the same. With some potential practical benefits for an at-rule:

1. A bundle of properties is more readable for authors than a function with a 
bunch of parameters describing an image, transforms and other interesting properties.
2. Less error-prone: switching to a different asset or adjusting the parameters 
of a resource does not require fixing up a function everywhere it's been copied/pasted. 
(This is also pretty natural for tools and editors- cue Daniel)
3. Easier to extend: the WG and browser vendors can add support for new 
properties to the image rule without breaking backward compatibility. Older
browsers just ignore the properties they don't handle, as per usual vs. browsers
that expect at most n function arguments will choke on a value with n+1 arguments.
(At least that's how CSS functions have worked so far afaik).

I certainly understand this would require rewriting much the module and this is 
never appealing to an editor but that is also not a good-enough reason to say no; 
unless of course there were several implementations and real uptake on the web. But 
even then, at Editor's Draft state and at a time where vendor-prefixes are most 
definitely required we can still explore different models. 

At a minimum, it'll help clarify why the current one is better the way it is.

Received on Tuesday, 7 December 2010 16:55:52 UTC