Re: CSS Variables

On 9 February 2011 17:37, Sylvain Galineau <sylvaing@microsoft.com> wrote:
>
> So what I am missing is that these do not make it into public releases,
> Betas and other bits generally downloaded by large populations so that
> web authors cannot rely on them in their pages ?
>
> In the case of IE, Previews are actually downloaded by large samples
> but I'd assume they qualify since they have no chrome and really
> targeted at developers. What would be the vehicle for Firefox ?

For IE, would Microsoft's HTML5 labs (
http://html5labs.interoperabilitybridges.com/ ) initiative not be a
better place to put such experimental and exploratory work, if
possible? That way it could be run separately from the actual IE
release track. The developer previews seem more suited to work that is
an implementation of a stable standard, that is planned to go into a
release. Whereas, variables are far from that point at the moment.

Having read what you said in your other reply to this thread, I'm
slightly confused. You seem to be in favour of some kind of explicit
opt-in within the stylesheet for experimental features, but then you
point out that this hasn't prevented vendor prefixed properties from
becoming adopted in mainstream CSS development.

Speaking as an author, I'll be blunt about a few points: Vendor
prefixes actually help and encourage me to use experimental properties
for real development, because they provide me with an easy way to
target each browser, even when they have incompatible implementations.
Furthermore, athough a vendor prefixed property is theoretically
subject to future change, in practice it doesn't seem to happen much,
and even then will only have an effect when the next major release of
a browser arrives. Since no sane web developer contracts to develop a
site that will work in future browser releases, all such a change does
is create further (paid) work for the developer when compatibility
changes are required.

Commercial web development is as much an arms race as browser
development. We are under constant pressure to win work and to deliver
ever more complex, interactive and attractive sites to meet customer
requirement, and we use the tools available to us to do so. While we
do understand that experimental features are not intended for
production use, the fact is that they deliver things we need, and over
the past decade the progress of these features to stability has been,
and remains, far too slow to make waiting an option. Surely the most
notorious example is border-radius, which afaik first showed up in a
spec back in 2002, and nine years later said spec has not progress
past Last Call. Is it any wonder that in the intervening time web
developers gave up waiting and started using the prefixed versions in
anger?

Ensuring experimental properties remain in development versions and
hidden behind flags will, in my opinion, be far more likely to prevent
them being used on real sites, because it will make it very difficult
for them to reach the kind of critical mass of adoption that makes
using them viable, something that vendor prefixes do nothing to
prevent. But what will really help to avoid this situation is if
browser vendors ensure that features do not linger for years in
unfinished states, but are instead progressed in a timely fashion to
completion and standardisation.

Jon

Received on Wednesday, 9 February 2011 22:21:09 UTC