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