Prefixed

Published 2012-02-20 17:21 by Leif Halvard Silli.

Here is to prefix …

A list apart issue 344 discusses vendor prefixes:

Lea’s — dare I say moralist — approach includes an explanation of — on one side — properties that are prefixed because vendors and W3C are experimenting (read: W3C spec is under way). And — on the other side — properties that are prefixed because a vendor in solitude is experimenting (read: no W3C spec is on the horizon). As she says: Not every prefixed feature is proprietary. This way, she in fact legitimizes Mozilla’s approach. Her primary reason for not using prefixes is that it encourages vendors — currently Apple — to create more and more new properties.

Tantek’s problem, OTOH, is Lea’s first category: Those properterties that are standard, but which authors nevertheless write as -webkit-foo. Given how Web developers behave, when a feature has been specced, it should be harmless for other vendors to support e.g. -webkit-foo. After all, in that case, the meaning of -webkit-foo and foo would be the same.

CSS 2.1

Tantek gets asked: With so many evangelizing the right thing, why has it been insufficient? But amongst his theories about the why, there is one hyphothesis missing: «CSS it self».

Because, the CSS 2.1 W3C Reccomendation talks about Vendor-specific extensions.

Note the language: An extension — isn’t that something other than a beta version? In the mouth of most, I bet it is.

So why say -vendor-foo:bar; if the intention, in the end, is to be able to do foo:bar;?

Microsoft as an example

Since Microsoft started to make browsers again, they have understood that they need to become standard. And so, when Microsoft released IE8, they made a point of saying that, CSS Expressions … has ended … for standards-compliance … reasons.. Which means that Microsoft have moved from behavior:url(foo); to -ms-behavior:url(foo);.

A giant step!

But irony aside: Clearly, this sends the message that prefixing is good — it is even standard! A standardized way of being non-standard.

So yes: CSS itself sends a double message.

Ideas — 3 of them

1) Introduce the CSS validator on the scene

Lea posed the question: How do I detect whether a certain feature is proprietary? Her answer to the problem: Dedication and Google Search …

The — obvious — thing to ask: Would it not have been better to be able to use the CSS validator?

But as long as the W3C CSS validator only says “Invalid!” — whether you do -vendor-standard or -vendor-nonStandard, the CSS validator is of no help.

There are many ways the CSS validator could have been used creatively — I’ll spare you for my ideas till another time. But just one example: Isn’t it obvios that the validator too should “know” about -vendor-bord-radius if e.g. Mozilla knows it too? I said “know” — it doesn’t need to completely bless it.

2) Don’t prefix standard track properties

As told above, how useful is to prefix properties that are on a standard track? End that.

3) OK to support -anotherVendor-standardFeature.

So, this is not my idea. I just want to say that Mozillas approach, as described by Tantek, probably is wise. But remember to use the validator to keep track of what this way becomes (semi-)valid.

blog comments powered by Disqus

|