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

On Tue, Dec 7, 2010 at 8:55 AM, Sylvain Galineau <sylvaing@microsoft.com> wrote:
> From: Tab Atkins Jr. [mailto:jackalmage@gmail.com]
>> 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' ?

Apologies for the wording; the bias is only apparent, not actual.  I'm
a disinterested observer here.


> 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 ?

No, transforming background images in-place isn't a use-case, it's a
feature request.  It needs use-cases to justify adding it to a spec,
which so far haven't been given.  Transforming general images in-place
is similar.


> 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...)

Sorry, I didn't mean to single you out.  You just seemed particularly
interested in the ability, and I happened to be responding directly to
you, so I asked for use-cases.


> 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 ?

You misinterpret me.  I'm potentially interested in transforming
images.  I'm undecided on whether this is something solely applicable
to background images or if it should be usable on all images.
Further, I'm potentially interested in your idea for an @-rule
notation to make complex image modifications easier to read and write,
including things like transforming images.

These are all separate, and all require use-cases to justify.
However, if applying transforms to general images is useful, that
constitutes a strong argument to me that we should pursue your idea
for an @-rule for image modifications.


> 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.

Agreed.


> 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)

Agreed, though this case is also solved by just using CSS Variables.


> 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 find this line of argument pretty interesting.


> 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.

"I'd have to rewrite parts of the spec" is extremely low on my list of
concerns.  I basically adopt HTML's priority levels, and "ease of spec
writing" is below even "theoretical purity".

~TJ

Received on Wednesday, 8 December 2010 02:23:24 UTC