[shadowflit]

As an outsider looking in, it seems like the whole prefix thing is approaching the problem from the wrong direction.

Why do we have prefixes at all? Well, because developers want to start using new features before they've been fully standardized. Fine, understandable.

Browser developers make browser specific prefixes available, because you can't expect all browsers to roll out the same new features on the same day. Ok, that's one approach, but I can think of two others.

1) Don't wait for the entire standard to be formalized before expecting it to be implemented. A rolling standard approval process, if you will. It's basically what we have now where new features become available far ahead of the full standard, except prefixes won't be necessary because everyone will implement stuff on a rolling basis. That might be a little demanding of browser developers though, which leads to option 2...

2) Best effort evaluation iff you choose to use non-standardized features. Sort of how python lets you import from future, declare somewhere that you're using non-standardized features. After that, the browser switches to best effort mode, and just throws out any attributes it doesn't understand. When running in a dev environment mode, all these errors would show up, so you can see why things aren't behaving as intended if you're using an unimplemented feature.

[jballanc]

If only it were this simple. The problem is that not only are these implementations not formalized, but also there is often dispute over how they should be standardized. Border radius, for example, is "-webkit-border-bottom-right-radius" in Webkit but "-moz-border-radius-bottomright" in Firefox. If you look at competing ideas for standardizing things like gradients, you'll find even more disagreement. This is why prefixes are needed.

[zalew]

Wouldn't naming conventions solve the problem? f.ex. -{vendor}-{object}-{property}-{positions vertical-horizontal}-{additional}: {some-value-syntax-also}

In the end, everyone would just drop the prefix. Generating parsing it would be also way easier.

[joahua]

The idea behind vendor prefixes is that they are implementations of ideas before conventions have been established. When two vendors implement something simultaneously but pre-spec, it's hard to tell which one will end up being canonical.

Your general convention is probably good, but in 5 years time when n parameters have ended up in your {additional} parameter, people will ask why that, too, doesn't follow a convention. The answer is definitionally that the convention doesn't exist yet, and the vendor prefix is a step on the way to establishing one.

[zalew]

I don't know if it's really a big deal to set up a general convention, and when new features appear, just discuss it with W3C and/or other vendors, and use it. These are the minor kinds of problems that can be solved in theory with a few emails and in practice with a 2 months thread on a discussion board (but still better than a mess)

[jballanc]

But it isn't a mess. Finalized names are selected as part of the standardization process. That's exactly what TFA was saying: the standardization process works, but web developers are being exceptionally lazy.

What you're asking for is that the browser engineers should wait until part of the standardization process is done (the naming) before they start on implementation, only to potentially have to rewrite things once a finalized name is selected. Not going to happen.

[throwaway64]

a process that takes 11 years and counting to finalize the properties of a rounded border isnt a mess, its a disaster.

[batista]

The problem is those are BS differences that in the end don't matter much.

border-bottom-right-radius vs border-radius-bottomright, please.

Either use some consistent way of naming as you do with other properties, or just pick a f*n name and use it.

If it was some real competing ideas on the RENDERING of the visual effect defined by the property, I could understand, but the mere name of css properties is not the place to be creative. Just discuss it for 1 hour with other vendors, come to a name and USE IT.

[jballanc]

If you honestly believe that a naming dispute could be resolved in 1 hour, then I'd wager you haven't been programming very long. As the famous saying goes -- "The two hardest things in programming are: naming, cache invalidation, and off-by-one errors."

This was just the quickest/most famous/easiest example I could think of. The other I referenced is more subtle. For gradients before standardization, Firefox included the type of gradient in the property definition, "background: -moz-linear-gradient(...)", whereas Webkit made it a parameter to the function, "background: -webkit-gradient(linear, ...)".

[alextgordon]

It could be resolved in one hour. It could be resolved by a coin toss for god's sake. Heads: webkit's syntax. Tails: mozilla's syntax. Done.

The problem is that neither vendor is willing to solve it in one hour. They want to get their own way. It's simply arrogance.

[jballanc]

"Never attribute to malice..."

Webkit Dev (speaking to Webkit Program Manager) -- Hey! I've figured out a way we can give divs rounded corners.

Webkit PM -- That's cool, what do you call it?

Webkit Dev -- Well, for the bottom right it's "border-bottom-right-radius"

Webkit PM -- Cool.

<some time later...>

Webkit PM (to Webkit Dev) -- Hey! I just got off the phone with Firefox PM. He says they've also developed a way to give divs rounded corners.

Webkit Dev -- That's cool! I guess it was a needed feature.

Webkit PM -- Yeah...only problem is the name. They decided to call theirs "border-radius-bottomright".

Webkit Dev -- Oh.

Webkit PM -- Sooo, yeah. If you could just change that name.

Webkit Dev -- But we already GM'd the build with that name in it. To change it we'll have to back out of the GM, requalify the build, change the documentation, send out new seeds, redo internationalization, send it back to QA, and declare a new GM. That will push out the release by 3 weeks, and besides, I have 20 bugs in my current backlog that are completely unrelated to border radii. How important is this?

Webkit PM -- Oh...not that important I guess...

[tomjen3]

Sorry but no. I have been alive long enough to know that you always assume malice. Especially with big companies.