Re: Property proxies / CSS setters

Could you explain how this helps with any of the main issues with prefixes?

I don't see any benefits other than less typing for authors, which can
be achieved in other ways already.

Simon

On Feb 9, 2012, at 5:47 PM, Paul Bakaus 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
> 
> 
>

Received on Thursday, 9 February 2012 18:21:28 UTC