Re: Property proxies / CSS setters

Less typing for authors is a pretty big win and one of the causes of the
current snafu. It shouldn't be *harder* for authors to do the right thing.
Preprocessors and other tools help. Specifically, I hope my project,
Compass, has helped keep devs sane and adhering to best practices over the
last couple years. But such tools shouldn't be considered anything more
than a stop-gap solution to deal with the fact that incompatibilities will
_always_ exist.

If you missed it on twitter, I wrote a blog post on this subject:
http://chriseppstein.github.com/blog/2012/02/08/standardizing-incompatibilities/


On Thu, Feb 9, 2012 at 10:20 AM, Simon Fraser <smfr@me.com> wrote:

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