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