Re: Property proxies / CSS setters

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

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

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

>
>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:33:53 UTC