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

Re: Property proxies / CSS setters

From: Simon Fraser <smfr@me.com>
Date: Thu, 09 Feb 2012 19:20:27 +0100
Cc: "www-style@w3.org" <www-style@w3.org>, Lea Verou <leaverou@gmail.com>
Message-id: <B42BA08B-B335-48B7-9D73-10C94ABC66FD@me.com>
To: Paul Bakaus <pbakaus@zynga.com>
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.


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

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