1 Posted by Alexis Deveria on 23 March 2010 | Permalink

I was initially a fan of the generic prefix (-beta- or whatever), but not so sure any more. Here's a good recent www-style post by Robert O'Callahan, which highlights the problems with the concept:

http://lists.w3.org/Archives/Public/www-style/2010Mar/0317.html

2 Posted by Lars on 23 March 2010 | Permalink

I still do not see how -beta- would work for CSS-gradients, since the syntax for Mozilla and Webkit is very different.

And authors who start using -beta- for production sites - which they will do - will be really annoyed when implementations change. Introducing -beta- will mean that we will have an -alpha- soon and probably a -gamma- as well.

3 Posted by Ben Truyman on 23 March 2010 | Permalink

Whether it be "-beta-", "-x-", or "-lulz-" it doesn't solve the problem we bleeding edge developers require. Take a look the differing implementations of something like CSS gradients. Vendors should be allowed to experiment with these implementations. Apple lead much of the gradient implementation but it was horrid -- now Mozilla has provided a much cleaner alternative that might get included in the spec. If they bunched both implementations under the "-beta-" namespace, no developer would be able to use both implementations without some sort of conditional stylesheet for Webkit- and Mozilla-based browsers.

This is a annoyance that doesn't need solving.

4 Posted by Marco Jardim on 23 March 2010 | Permalink

I agree with the singular prefix for all browsers, however, there would have to be some mutual agreement between browser manufacturers where they agree which definition, and from which revision of the spec, they are using.

The problem with this solution, if it goes through, is that it means that at one point or another one browser manufacturer will want to update a definition and have to wait for the other browsers to choose to do so as well, thus the need for a browser-specific prefix reemerges.

5 Posted by Robin Gruyters on 23 March 2010 | Permalink

As I just posted in the previous blogpost (#c13688):

The problem here is when you use -beta- then you need to define standards for vendors to use the 'beta' properties. If you are already defining standards for -beta- why not implement these properties right away?

In this case i disagree with you and vendors need have their own property statement for testing purposes.

On the other hand, the question you could ask is should a developer be using these test properties anyway?

6 Posted by Andrew Hayward on 23 March 2010 | Permalink

I'm not quite sure what the point is of a single prefix for all vendors. So far as I can tell, the biggest problem with getting rid of vendor specific prefixes is that there is not guaranteed standard implementation for them.

I might be missing something, but other than not polluting the global namespace, what difference does it make whether i call something "-beta-property" or just "property"? I still don't know how any given browser is going to implement it.

When a general consensus is reached on a given property by implementors, then they could perhaps think about dropping the vendor-specific prefix, perhaps to a -beta, perhaps to nothing. But until they get to that point, they need to use individual prefixes to show that it's their version of that property.

7 Posted by Peter Gasston on 23 March 2010 | Permalink

-beta- is not a good idea; as already pointed out, CSS Gradients would immediately fall foul of this.

I would favour browser makers performing regular review of their prefixed properties and fully implementing any of them which are stable, and developers making sure they implement prefixed properties only with very careful consideration of the consequences.

8 Posted by Marty Alchin on 23 March 2010 | Permalink

I think we can all agree that vendor-specific prefixes make sense as long as implementations differ significantly, and that they should go away as soon as people agree. The trouble is, that's not an easy task. Who decides what constitutes "agreement"?

Do all browsers need to converge on a single syntax and behavior before the prefixes can go away? Do we limit it just to the "big" browsers? Does it need to be unanimous or just a majority? Do authors get a say in the decision?

Then there are the procedural questions.

How long do vendors have to experiment before we start to expect some agreement? How is that discussion handled? How long after an agreement is reached until browsers are expected to implement the agreed syntax/behavior? How do we handle inconsistent behavior that wasn't brought up during the initial phase (as Microsoft recently showed with its border-radius examples)? Do we need to reintroduce vendor prefixes while it's sorted out? Should vendor prefixes always be supported, even if the feature if the feature is supported without the prefix, to better support cases like that?

I agree that vendor prefixes have their warts, and that we need to wean ourselves off them sooner. But a lot needs answering before we can.

9 Posted by Ingo Chao on 23 March 2010 | Permalink

Reviewing working draft properties with vendor prefixes used /for production/ makes me feel that something important is missing in this discussion.

10 Posted by Thomas Broyer on 23 March 2010 | Permalink

I'm with Dion Almaer here [1]: let browsers recognize both -vendor-prefixed and unprefixed versions, with -vendor-prefixed taking precendence (or maybe just the stylesheet author should put the unprefixed property before the -vendor-prefixed ones). That way, if all browsers agree, you only need the unprefixed property. If one disagrees, then add a -vendor-prefixed property to target it specifically, others still using the unprefixed property.

[1] http://ajaxian.com/archives/should-css-vendor-prefixes-be-nuked-or-just-tweaked

11 Posted by Spudley on 23 March 2010 | Permalink

The purpose of the prefixed styles is for developers to try out up-coming features. They are NOT intended for production use. The fact that they are being used in production is the real issue here.

I believe the solution to this is for browsers to require a config setting to be switched on in order for any prefixed styles to be enabled.

This way, developers have a chance to try stuff out, but the temptation to put it into production is removed because most everyday users will have the flag switched off.

This solution also makes the whole discussion of -beta vs -vendor irrelevant.

12 Posted by Gonzo on 23 March 2010 | Permalink

I think the solution to the problem is in the hands of browser vendors. They must abandon prefixes as soon as there is agreement on the property syntax. No need to wait for the spec to become standard.

Web developers must not rely on browser-specific properties. We have to remember that they can change or disappear in the future.

I like the idea for a separate stylesheet with browser-specific declarations. The same way we maintain IE-only rules set, we can have enhancements-only stylesheet. I may give it a try.

13 Posted by Egor Kloos on 23 March 2010 | Permalink

I'm not a fan of prefixes, but it does work. Extra CSS sure, but it's not the end of the world. Border-radius is a good example why it does work and also why we don't want it. The webkit and gecko teams should eliminate that prefix as soon as posible.

I think this is where variable pre-parsers for CSS could be useful. We could then group 'experimental' code and then 'render' it to the browser. Or browsers could introduce a form of syntax referencing, like an alias, to an array of properties, selectors or even values. This way your could keep you css clean. Aliases have other issues like making style sheets harder to 'read' and debug. Also, you couldn't reliably use it for colors. Still, it would be a powerful tool.

14 Posted by Johan Jensen on 23 March 2010 | Permalink

As Lars (#2) and Ben Truyman (#3) says, it doesn't help anyone if every vendor use the -beta- or -x-prefix.
A much better solution would be to have a unique name or id referring to an implementation-idea.

For example, Mozilla could use -b220- for the gradients and then Opera could implement it the same way as Mozilla, and support the -b220- or they could go on and make one themself and call it -d850-

But that's just not friendly in any way, for the developer.

A much better way would be (as you suggested in the first post) letting Opera respond to -moz- if they have the same implementation as Mozilla has.
If they'd rather do it like Safari, they would support the -webkit-prefix – but ONLY for gradients.
So the vendor-prefix will be based on which vendor came up with the brilliant idea of implement the specs. :)

– Johan “Josso” Jensen

15 Posted by Michael Kozakewich on 23 March 2010 | Permalink

The problem is very real, especially for things like Border-Radius, but I think the degree to which they hold to these rules is what's causing it.

Back during the first implementations, I agree with the prefixes. -beta- might work, though developers shouldn't have to use the rules. It's meant for a few to test them out, so a couple repeated rules are fine.

At the point where where it enters wide usage (which may be determined by the working group), the spec is basically set and the browsers should be forced to either remove their prefix or add the actual rule in addition. (That's the magic bit, right there.)

This way, we won't get the flagrant usage errors, but the browsers are still free to change their implementations in the early stages.

16 Posted by Dan Peddle on 23 March 2010 | Permalink

Abuot replacing vendor prefixes with a generic - We'd still have issues from different implementations of features. The recent post on the IE blog is a good example, about rounded corners? However, there's not a great deal we can do as developers about the browser's individual behaviour.

With that in mind, some kind of generic prefix makes sense. At least, if we use "beta" we know pretty well what to expect.. !

If CSS capabilities could be queries in some kind of programmatic way too, it would be useful for removing another reason to do browser detection. Imagine if, for example, we could do something like..

if (browser.capabilities.css.borderRadius){//}

at some point during the initial load..? Then inject correct style sheets depending..?

Its a little horrible, but still, I think it would be useful, and would follow the concept of feature detection in JS.

17 Posted by Jake Archibald on 23 March 2010 | Permalink

-beta- works for me. The counter argument of "But what if webkit's -beta-whatever is different to gecko's -beta-whatever?" makes sense, but it's not a new problem.

-moz-whatever in Firefox 3.6 may be different to -moz-whatever in Firefox 3.7, that's what you get for using experimental not-yet-complete-or-standard features.

18 Posted by qFox on 23 March 2010 | Permalink

How about vendor prefixes if some property has not been specified by anything at all, and a beta prefix if the vendor is trying to follow an unfinished spec (css3, html5, whatever) and dropping the prefix when the spec finalizes and the vendor completes the implementation. beta prefixes could be considered optional (as in, if a coder uses it, it's ignored if the property is out of beta).

Of course, I have a feeling this is only adding another prefix for the sake of argument :)

19 Posted by Bill Thiede on 23 March 2010 | Permalink

I think a good solution for this sort of problem would be one that follows the pattern set out by OpenGL. You have vendor prefixes that are used in the early development of a feature, say NV, or ATI. As it matures, but is not defined by a standard, you can have multiple vendors agree on a definition and then it is designated EXT. After it has become more widely accepted, it can be fast tracked, and agreed upon by the 'Architecture Review Board' which gives it an ARB designation. This makes it standard across supporting implementations and makes it a likely candidate for the next release of the OpenGL standard.

Why wouldn't something similar work here? It would require the w3c to have an approval process that moved more quickly than the normal CSS standardization process, but that doesn't seem impossible.

20 Posted by Ben Darlow on 23 March 2010 | Permalink

So, if all browser makers have to use the same prefix, does this not mean that all browser makers have to collaborate on exactly what these as-yet-unspecified attributes are called or how they are formatted? In effect, all this would do is drag the spec drafting process out of the theoretical circles into the practical arena of browser makers trying out new features. Freedom from the politics of the W3C is one of the compelling reasons to implement functionality like this under vendor-specific namespaces, so I really can't see any potential positive to doing this, other than idealistic purity.

21 Posted by JanPietrzyk on 23 March 2010 | Permalink

I like the -beta- solution a lot, because it reroutes the pressure to implement stuff the right way to the vendors and to the W3C! I totaly agree that we shouln'd use any beta marked property in any project and of course we should'nt be using -vendor- today. But doing so is much easier for us than making a generall standard ,or a vendor wide agreement on behaviour or syntax, for anybody else.

If we want the web to be quicker and more generally adoptable, there needs to be a fix to css. -beta- is a good idea, lets see how long it takes till this breaks ;).

22 Posted by Ernst de Haan on 23 March 2010 | Permalink

Having only -beta- is probably too simplistic, since 2 browser developers could be working on similar properties (e.g. CSS shadows) and come out with conflicting implementations shortly after eachother.

However, it should also be possible for a browser developer to align with another browser developer, using the same extension format (to avoid a prefix flood).

Thirdly, it should be possible for a browser developer to change his mind and implement a different proposal.

Adding a number to the beta prefix would probably be sufficient to comply with all these use cases.

An example of what could happen, to make this more concrete:
(1) Opera comes out with a new "-beta0-box-skew" property.
(2) Apple decides to take a different route and chooses "-beta1-box-skew".
(3) Mozilla goes with the Opera-approach and also uses "-beta0-box-skew".
(4) A couple of browser vendors get together and decide that "-beta0-box-skew" is promoted to the standard, in which case "box-skew" is from then on considered a synonym for "-beta0-box-skew".
(5) The latter will be deprecated and support is removed at some point.

23 Posted by Kevin Dees on 23 March 2010 | Permalink

While I share the same concerns. I don't know that -beta- would be much better. I believe it would only encourage implementation to early in the proccess.

We don't need unfinished specs being used by browser makers because -beta- looks bad. We need to simply encourage vendors to move forward, like you are right now.

Just think about box-shadow.

"This module previously defined a ‘box-shadow’ property. This feature has been removed from this module for further discussion..."

Simply changing the rules doesn't always fix the problem, it can sometimes create new ones.

Developers are the solution not a different spec.

Keep up the good work PPK!

24 Posted by Martin on 23 March 2010 | Permalink

-beta-* is goof, but it doesn't solve the problem with different syntaxes. I propose the following:

-beta-*: vendor1(a b c), vendor2(a/b/x), a-b-c;

So in most cases you could simply use -beta-* and for the one or two browsers that use some other syntax you could use vendor1(...).

25 Posted by TNO on 23 March 2010 | Permalink

Experimental extensions are not vendor specific, they are browser specific. Perhaps standardization of conditional comments is the way to go. Something that can't be lied about like the way that the user agent is.

26 Posted by JanPietrzyk on 23 March 2010 | Permalink

@Kevin Dees

Could this really be the case in today browser-landscape? I don't think so because aside from Microsoft there is no dominating player, with the real interesst in profit out of the software itself. Webkit & Gecko are just tools for the big companies to bring rich content to devices or new services to consumers.

Besides, what developers do you mean? W3C-Spec Developers or Browserdevelopers or Webdevelopers? They play different roles and I think there is the underlying problem. Specs are too slow, browserdevelopers are lazy in some places and webdevelopers are too greedy implementing everything that comes across. This truely is wrong!

27 Posted by Milo on 23 March 2010 | Permalink

-beta- prefix considered harmful; sharing prefixes considered good

Different browsers having different syntax and semantics for the same -beta-whatever rule make a -beta- prefix a no-go. This is exactly why different browsers need different prefixes.

But if a browser, say Opera, decides to *exactly* copy the experimental CSS from another browser, say IE, then I see no harm in Opera supporting -ms-whatever. As long as they 100% match the syntax and semantics defined by MS for -ms-whatever, that is fine. (I doubt this will ever happen in practice though.)

The prefix is just namespacing. As long as you know what you're doing, it's fine to use an object from another namespace (-ms-). But having a namespace that will contain conflicting elements with the same name (-beta-) would be terrible.

28 Posted by Frans on 23 March 2010 | Permalink

I think point #4, removing prefixes if they're no longer required, is the most important. Other than that I'd say if prefixes bugs you, use a pre-processor. Pre-processors typically come with many more advantages than merely allowing you to deal with prefixes easier (in fact I'd argue that's one of their least useful properties).

For instance, you could write CSS along the lines of the following:

nav {
li {border-radius:/*whatever*/}
a {text-decoration:/*whatever*/}
}

This would then be automatically be translated to:

nav li {-moz-border-radius:/*whatever*/;-webkit-border-radius:/*whatever*/;border-radius:/*whatever*/}
nav a {text-decoration:/*whatever*/}

And let's not forget about the possibility of using variables so you can easily use the same color for texts and borders or some such. Or that if you write your colors in HSL (which I think it's easier), it could automatically translate it to RGB for compatibility purposes, either like color:#xxx;color:hsl() (more possible colors for supporting browsers on supporting monitors) or just as plain RGB.

Aside from some vendors being somewhat slow on removing prefixes on some properties (i.e. box-sizing) I don't think there's much of a problem.

29 Posted by Jethro Larson on 23 March 2010 | Permalink

I'm in favor of -beta-. I don't like extra stylesheets.

30 Posted by Tom Bigelajzen on 23 March 2010 | Permalink

Your idea of a unified -beta- prefix gave me an idea:

As many including you pointed out, a unified prefix takes the edge of different experimental implementations of different browser vendors.

I say, why not remove the prefixes altogether and use an @beta-[vendor]{} declaration to switch them on or off?

This way a vendor could also implement 2 versions of the same CSS rule, one currently solid and one experimental.

It will require us, the programmers, to write a bit more code but will ultimately clean up our CSS files, for exmple:

div{color:#fff;border-radius:8px}
@beta-moz{
div{border-radius:8px;}
}
@beta-webkit{
div{border-radius:8px;}
}

Further more, this can be extended to just switching on experimental mode for a specific browser, something like:

@beta-moz{use-experimental:true}

at the beginning of the code.

31 Posted by John A. Bilicki III on 23 March 2010 | Permalink

No, vendor prefixes are the best thing since sliced bread. A browser should *NOT* display incorrect rendering at all especially if a specification is not yet finished. However not all specifications are apt to greatly changing over time.

Microsoft and Opera using border-radius means they're absolutely sure that the specification will not change or at least change drastically enough that it would effect pages in the future from how they are rendered in their browsers today.

By using a vendor prefix a browser encourages people willing to take those risks to try out new technology. Additionally it's a great way to correctly determine the browser and it's version without resorting to looking at an easily spoofable user agent.

In the 29th version of my site I actually rely a lot on many vendor prefixes to correctly determine the browser and it's version which allows me to correctly serve CSS3 and patch style sheets fixing older browsers such as IE6/7 and enabling CSS3 features without spawning errors or warnings of any kind.

Your proposition essentially would be no different then removing all the vendor prefixes altogether and would only make it immensely difficult to have our cake and eat it too.

32 Posted by Erik on 23 March 2010 | Permalink

-beta- solves nothing and removes the whole purpose of vendor specific implementations: experimentation. Besides, sometimes it feels like all rules should have a beta-tag...especially with IE still around.

#11 has a good point, browsers should have vendor specific rules disabled by default so we are not tempted to deploy them on the interwebs and to put some more pressure on the w3c and the browser makers to finish the rules once and for all.

All vendor specific rules should be treated as beta regardless if it's called so or not. The only good thing with the -beta- prefix is the name because it reminds you of that fact. Maybe renaming the vendor rules to -beta-vendor- would be a good first step.

33 Posted by Robert Sherby on 23 March 2010 | Permalink

My own view is in favor of using browser specific stylesheets. They could be declared in the HTML as being vendor specific with a vendor= property on the script or link elements and could even be made to target specific browser versions using, for example, version="firefox 3.5". This would allow developers flexibility to target not only specific vendors, but to actually target specific implementations of an experimental property (with the caveat that browser vendors are not required to support old versions unless they want to).

Vendor specific stylesheets would also address another real problem with web development: Incompatible/Buggy implementations. Vendor stylesheets are a logical extension of using IE Conditional Comments to target custom CSS at IE6 and IE7, as has become a best practice for dealing with those browsers. While it is, admittedly, too late in the day for vendor stylesheets to help those browsers, even modern browsers may have buggy behavior in their properties which require special work to overcome.

As such, vendor specific stylesheets would seem to solve two problems at once; which strikes me as being fairly elegant.

34 Posted by Roland van Ipenburg on 24 March 2010 | Permalink

If it wasn't for those pesky inline style attributes we could have gotten away with a more generic and already available solution based on x- and vnd. prefixed MIME types for various style sheet dialects in combination with content negotiation on the HTTP level. But that would make it a bit more obvious some vendors might fork CSS and get going with something like for example text/vnd.mozstyle2 when W3C keeps moving to slow. Is that the revolution we're aiming for?

35 Posted by Robert on 24 March 2010 | Permalink

I like it how it is now. It'd piss me off more to have -beta-border-radius-topleft and -beta-border-top-left-radius in my CSS than -moz-border-radius-topleft and -webkit-top-left-radius.

I already use things like e = e || event; in my JavaScript. I'm used to coding around different implementations. I'm not used to the same implementations working vastly different.

I'm sure there are examples in JavaScript of the same implementation working vastly different, but I'm speaking from how I like things.

36 Posted by Jim Gay on 24 March 2010 | Permalink

I agree with Ben Truyman http://www.quirksmode.org/blog/archives/2010/03/css_vendor_pref_1.html#c13691
This is a problem that doesn't need solving.

A generic prefix might as well be immediate implementation and there would be absolutely no way to provide for different implementations, as many here have pointed out. When the speed of development of new features is measured in years there's not much to do but deal with it.

IE seems to have solved this with conditional comments.

37 Posted by Georgiy Ivankin on 24 March 2010 | Permalink

-beta- sounds fine, but in fact it can become just another (the fifth!) prefix to pollute our stylesheets.

I think the current situation with prefixes is rather reasonal, as it has been pointed out by Meyer, Snook, Hay and others. Maybe it's not vendors but W3C? What stops it from moving declarations that has de facto become the standard, say box-sizing, to Candidate Recommendation?

As for now I find the preprocessors the best solution. BTW, there are some already, e.g. http://css3please.com There's also a way to provide functionality like…

if (browser.capabilities.css.borderRadius){//}

…both in JS and CSS — see http://modernizr.com

38 Posted by Paul on 24 March 2010 | Permalink

What irritates me is that the focus lies on the browser prefix while the real problem is the speed in wich W3C releases there standaards.

The current system works fine. The developer is responsible for using css support that is not yet accepted. So creating complex and big css files is up to the developer.

As I said in a comment at snook.ca, don't take away the responsibility where it lies.

The fact remains that we want things quicker and faster than W3C accepts it as a standaard

39 Posted by Salva on 24 March 2010 | Permalink

This might be overdoing it, but I think the best solution would be to add some kind of reusable class declarations into CSS. This would solve other problems with CSS, appart from this one.

If I could just declare a:

$roundedBorders(a,b) {
-moz-whatever: a b;
-webkit-whatever: a a b b;
whatever: a b;
}

and then reuse them like:
#myDiv {
$roundedBorders: 12px 10px;
}

I wouldn't mind the prefix polution, as it would be reduced to a single location in my CSS, instead of constant references along it.
On the other hand, this solution is not related to the fact that prefixes, while a necesary evil, should be dropped as soon as there is a common implementation accross browsers (eg. box-sizing).

P.S. My proposed solution has been thought for about 10 seconds before I wrote it down, so take into account that it's just a proposal to start talking, not an exact description of how it should be done ;)

40 Posted by Constantine on 24 March 2010 | Permalink

The problem is not with prefixes, but rather with developers who use experimental syntax in production code.

Browsers should notify users about particular page using experimental functionality, and thus dispromote such irresponsible behaviour.

IE style yellow ribbon warning will be enough, imho.

"Notice: This site uses experimental syntax. Click here for details." - "18 CSS rules found: -moz-border-something: .. , .. , .. "

Also browsers should only notify user about THEIR OWN vendor prefixes, and do not show them for rules that they ignore. So Firefox will not show warning for -webkit-, but Chrome and Safari - will.

41 Posted by Gareth on 24 March 2010 | Permalink

It seems to me there are 2 problems that need solving:

1) Vendors need a way to implement new functionality that isn't standardised yet.

2) Authors don't want to have to include multiple vendor rules for cases where there should be a common syntax.

Now, vendor prefixes work absolutely fine as a way of saying "this is *our* implementation of a feature" and as we've seen with gradients this can produce multiple syntaxes for a single feature.

However, *once there is a draft standard*, and thereford a unified syntax, there could certainly be a switch to a -beta-* prefix.

This would seem to result in the best compromise:

- Anyone can test or use a browser's experimental functionality with the vendor prefixes, with all of the risks that entails.

- More conservative developers can stick with -beta-* prefixes knowing at least that a consistant syntax is available - although the behaviour is still not guaranteed stable.

Suggestions like -vendor-beta and adding new CSS syntax seem to miss the point, or at least they don't make clear what point they are actually trying to fix.

42 Posted by Gareth on 24 March 2010 | Permalink

In fact, reading back I see that I'm actually agreeing with comments #18 and #19 - don't know why I didn't spot that at the time

43 Posted by Jadet on 24 March 2010 | Permalink

Sounds more like PPK is blaiming vendor prefixes for standards not getting finished quick enough. That's probably his real problem since I have yet to see a serious argument against the vendor prefixes.

We can't do without them, they give each vendor room to implement unfinished standards without causing conflicts with other vendors.

Yes, you'll have to use a bit more code while the standard isn't finished. If you think that's a serious problem better start rethink why vendor prefixes are there in the first place.

44 Posted by Frans on 25 March 2010 | Permalink

@Jadet:

That's what I was thinking but failed to state explicitly. Anne put it best imho: http://annevankesteren.nl/2010/03/css-vendor-prefix

45 Posted by Sander Aarts on 25 March 2010 | Permalink

I think Ingo Chao (#9) has a very good point: http://www.quirksmode.org/blog/archives/2010/03/css_vendor_pref_1.html#c13697

46 Posted by Dave on 26 March 2010 | Permalink

The Robert O'Callahan post you link to highlights the actual problem: the amount of time between the feature becoming functional and the standard becoming CR.

Pretty much every alternate plan for vendor prefixes, a general prefix, etc, seems horribly inelegant...because that's not the solution. The solution is to reduce the time before CR.

47 Posted by Clinton on 27 March 2010 | Permalink

I can't beleive it's taken so long for people to realise the problems with the continuing lack of standard and these prefixes. Vendors are still competing for developers attentions by intoducing cool/handy features. Unbelievable. Part of this is pushing CSS forward ie the ideas certain vendors have with regards to what CSS can/should do, but with the lack of standards through all browsers I really don't know why people get their backs up about IE6 so much when we have pressing issues like this to contend with.

48 Posted by Nux on 27 March 2010 | Permalink

I agree with PPK - there should be some generic prefix, whether it would be -beta- or -exp- (as in "experimental") or whatever.

Currently I should use:
something-new: blah;
-o-something-new: blah;
-ms-something-new: blah;
-moz-something-new: blah;
-icab-something-new: blah;
-khtml-something-new: blah;
-webkit-something-new: blah;

Hell it even looks kinda nice but COME ON! Even this would be shorter:
something-new: blah;
-IKnowThisIsToBeStandardInSomeFuture-something-new: blah;

Surely there are some specific uses of some attributes that might change, but then they will also change even if I use:
-webkit-something-new: blah1 blah2;
because Apple might decide that "blah2 blah1" is a more appropriate order of values.

I don't think vendor specific prefixes should go away, but all of them should also work with a generic prefix.

Again, there are some things that might change in the specs, but some won't. E.g.:
* I can't imagine border-radius: 5px; would ever work differently (though border-radius: 5px 8px; might)
* I can't imagine column-count: 3; would ever work differently.
* I can't imagine transition-duration: 4s; would ever work differently (though "transition" syntax might change significantly).

49 Posted by Aristotle Pagaltzis on 28 March 2010 | Permalink

I agree with Robert O'Callahan's analysis. The only problem with vendor prefixes is that vendors don't prune them soon enough. As soon as the spec for a directive has settled and the browser has implemented it, it should start recognising the non-prefixed property and prepare to drop support for the prefixed one.

50 Posted by Axel Berger on 28 March 2010 | Permalink

I disagree with one of your points: If one vendor decides to copy another's experimental property verbatim, I think it is a good, and not as you state a bad, idea, to do it with the first's vendor prefix. As you pointed out in your examples: why add another set of lines for no gain at all? Only use another prefix for another, slightly different, implementation.

That said Tim Berners-Lee invented HTML to enable grown-up people to read worth-while sensible texts and documents. It is you developers with your bleeding-edge nonsense that have made half the web illegible and half (fortunately not the other half) unuseable. My pages have been called "boring" (layout, not content) and in my eyes that's a good thing.

With one half of developers using dark and highly structured backgrounds making it impossible to read anything and thus forcing me to turn them off - a feature offered by ALL browsers right there in the menu, they know why! - and the other half hiding important content in background images, the time when the web was a useful and useable medium is over, for the time being at least.

51 Posted by Miles Browloski on 14 April 2010 | Permalink

Yeah, with all due respect PPK, I think you were way off the mark with your previous article about vendor prefixes.

There's still something way wrong in this standardization process though.

Progress is moving way too slowly...