Re: Vendor Prefix solutions

On 02-10 16:54, Matthew Wilcox wrote:
> That doesn't solve the problem vendors are trying to address: poor web
> developers only using one vendor prefix, meaning all the other
> browsers (which are capable of the same function) don't get .


This problem cannot be solved by vendor prefixes. This can be done essentially
only: 1) using preprocessors; 2) speeding up W3C standarization process.

And actually this crazy expieration prefixes idea helps both of this
ways. It also helps indirectly by improving web developers knowledge
(because many webdevelopers just do not know this prefixes are
experimental, they think they will not introduce any problems now or in
the future - but by introducing dates into prefixes, they will ask
themself "What will happen after 2013 with this prefix?")

How it will help preprocessors? Currently preprocessors can have
problems with generating for example gradients, or other nasty features,
because semantics or syntax, sometimes differs slightly beetween user
agents and vendor prefixes. By introducing from-to dates, we effectivly
are introducing versioning scheme, which allows preprocessors (and
documentation, tutorial writers) to use exactly what is needed. It
allows smooth transitioning if new incompatible changes needs to be
introduced, or constensus on syntax/semantics which is different than
previous needs to happen. It also helps not makeing mess, by only
allowing single change in a year. By having way for smooth transitioning
we can write tools (validators, preprocesors, converters) which will
essentially transition features automatically. It also allows other
vendors to implement others vendor prefixes (sic!), slightly more safely
than currently!

It is crazy and radical, and one may think nothing changes, but I think
o psychological and maintaince level it changes many things.

For example after -webkit-2010-2012-box-shadow is going to expire we have multiple options:
  - prolonge webkits prefix, -webkit-2012-2015-box-shadow
  - end standarization and introdue box-shadow
  - introduce working drafs, as w3c-wd-2012-2015-box-shadow, which would be safe to be implemented
    by any user agent. Even if 2015 passes, and in beetween we end
    standarizing it, browsers, tools, preprocessors, documentation can
    relativly safely refer to old proprty without unambigouty,
    and developers will know they should check more recent tutorials
    or see what changed in standard since 2015, if it is say 2017.
  - do nothing, and drop idea, and introduce W3C own way of doing same
    functionality, or agree it is not needed.


In some sense, it solves problem by making more problems. Now developers
needs to know better when to use prefixes, and this actually can make
mitigate source of the problem.

Regards,
Witek

> 
> On 10 February 2012 13:05, Witold Baryluk <baryluk@smp.if.uj.edu.pl> wrote:
> > On 02-10 08:19, Matthew Wilcox wrote:
> >> I agree with all of you that vendor-prefix from our perspective is
> >> fine and there's no *technical* problem.
> >>
> >> However the world isn't made of responsible web developers, those are
> >> rare. So the feature is being abused - to the point where vendors are
> >> about to implement -webkit- support in all browsers. That's the point
> >> they feel pushed to. If that happens, standards fail.
> >>
> >> So the problem is "how do we stop the abuse"?
> >
> > I have a rather radical idea.
> >
> > How about introducing into prefixes their expiration?
> >
> >
> > -webkit-2010-2012-box-shadow
> >
> > Which means it is valid from 2010 to 2012, and maybe few months more,
> > but not anymore. If for some important reasons in this time
> > standarization process doesn't finished, a w3C will vote for prolonging
> > this expiration up to next 5 years.
> >
> > Any vendor could introduce their own ranges, but no longer than 2 years.
> > This will make pressure on all parties: developers wanting to use this
> > features (they will clearly see expiration date), W3C, and other
> > standarization parties to do something, and vendors to work harder on
> > standarization. If for some reason standarization fails, a W3C needs to
> > admit that and prolonge a prefix for few more years.
> >
> > I know it still hard to enforce on vendors, but may be possible.
> >
> > There could be for example a separate clause for internal devices, like
> > e-book readers, or intrantes, which could use own prefixes indefinitly
> > (or with older versions of User Agents).
> >
> > Regards,
> > Witek
> >
> > --
> > Witold Baryluk
> 

-- 
Witold Baryluk
JID: witold.baryluk // jabster.pl

Received on Saturday, 11 February 2012 18:19:04 UTC