Re: Property proxies / CSS setters

I could probably live with mixins too, only issue I have with those is that mixins abstract away too much of the ability to look at code and say "oh yeah, this is why it performed so badly".

Von: Chris Eppstein <chris@eppsteins.net<mailto:chris@eppsteins.net>>
Datum: Thu, 9 Feb 2012 09:32:19 -0800
An: Paul Bakaus <pbakaus@zynga.com<mailto:pbakaus@zynga.com>>
Cc: "www-style@w3.org<mailto:www-style@w3.org>" <www-style@w3.org<mailto:www-style@w3.org>>, Lea Verou <leaverou@gmail.com<mailto:leaverou@gmail.com>>
Betreff: Re: Property proxies / CSS setters

Why not just have mixins?

Chris

On Thu, Feb 9, 2012 at 8:47 AM, Paul Bakaus <pbakaus@zynga.com<mailto:pbakaus@zynga.com>> wrote:
Hi everybody,

There's been a lot of heat again regarding vendor prefixes, and this email
serves as a proposal to get rid of the problem - but not of vendor
prefixes - once and for all.

I am proposing the addition of something I am calling CSS property
proxies, or alternatively, CSS setters. The basic idea is to have CSS
track a property (i.e. "transform") and define how it should behave for
that property. This is in some way a little similar to the mixin concept,
but more restricted to the actual property.

Actual Syntax could look similar like this, allowing a property to proxy
to more than one properties:

@proxy transform(a b c) {
       -webkit-transform: @all;
}

By default, you would use pseudo variables passed through (space separated
from the original), but there would be a special keyword (like the @all)
above that simply forwards the whole thing.

Or, if this looks too much like mixins, something like this might work as
well:

@proxy transform(a b c) -webkit-transform(a b c)

This is obviously all not fully fledged out (not sure how to make it
generic enough to be able to pass through any args), but a quick Twitter
exchange round got a lot of people excited, so I want to open discussion
here to understand if something similar has ever been proposed, and if
there's potential. With very few lines of code, library authors could
build CSS with this that gets rid of the vendor problem, and can be
upgraded at any time - therefore, it doesn't destroy the purpose of
prefixes.

Thinking forward, the only way to implement this in a sane fashion is to
implement this very feature *without* vendor prefixes, as notable
exception to other upcoming CSS features (or it would destroy its purposes
itself, ha). This would likely need a push from all browser vendors.

Feedback?

Thanks,
Paul