W3C home > Mailing lists > Public > www-style@w3.org > February 2012

Re: Property proxies / CSS setters

From: Paul Bakaus <pbakaus@zynga.com>
Date: Thu, 9 Feb 2012 10:33:23 -0800
To: Simon Fraser <smfr@me.com>
CC: "www-style@w3.org" <www-style@w3.org>, Lea Verou <leaverou@gmail.com>
Message-ID: <CB59CF4E.15A31%pbakaus@zynga.com>
Hi Simon,

Am 09.02.12 19:20 schrieb "Simon Fraser" unter <smfr@me.com>:

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

This way, it's trivial to write a shim that abstracts away prefixes for

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

Interested in hearing how so. I am not aware of any.

>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
>> 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
>> 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
>> 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
>> 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
>> itself, ha). This would likely need a push from all browser vendors.
>> Feedback?
>> Thanks,
>> Paul
Received on Thursday, 9 February 2012 18:33:53 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:55 UTC