Comments on: Should CSS vendor prefixes be nuked? Or just tweaked?

By: genericallyloud

genericallyloud — Wed, 24 Mar 2010 17:01:48 +0000

@Onderhond – leaving them out of official releases would make them pretty much useless. Even though they are not available exactly the same way, or on all browsers, people are finding real uses for this now in the wild. For example, when building apps for iphone or other mobile devices, or even just graceful degradation. Maybe everything but IE get a drop shadow. That doesn’t break the app, it just doesn’t look as pretty. Lacking support for IE is one thing. You can get pretty far depending on your audience with that. But expecting an end user to have a nightly is pretty extreme. You would really only be able to use is for playing around, which doesn’t help anyone.

By: BenGerrissen

BenGerrissen — Wed, 24 Mar 2010 10:28:18 +0000

Ok, after reading more on the subject (lots of responses all over the web), PPK’s real complaint is “CSS Standards and/or Implementation is going too slow”. Vendor prefixes are non-standard (duh) and mostly experimental, prefixes should remain and devs should use them at their own risk.

By: Onderhond

Onderhond — Wed, 24 Mar 2010 08:23:40 +0000

Leave in the vendor prefixes, but only in nightlies and unofficial releases. Putting them in official, ready to use for everyone releases is really screwing up css files now.

Leaving them out completely sounds even worse though, what with different syntaxes.

By: pjklaus

pjklaus — Tue, 23 Mar 2010 17:11:43 +0000

I agree with the stance that if you truly believe in standards, then don’t use non-standard CSS properties. They aren’t cross-browser compatible, so why use them at all if you are preaching standards?

I also agree that CSS inherently violates DRY, unless you are generating it dynamically or using a templating language for it. Talking about browser vendor prefixed properties violating DRY is then a moot point.

By: abickford

abickford — Tue, 23 Mar 2010 13:46:40 +0000

“If you don’t like prefixes, then wait until the implementation is stable before you use it. Problem solved.”
.
Exactly right. If you want to live on the bleeding edge then this is the price you pay. If you want stable, well defined and predictable results/APIs, stick to established standards. Know the consequences of your design choices and decide if the trade offs are worth it or not.

By: WillPeavy

WillPeavy — Tue, 23 Mar 2010 13:33:18 +0000

If you don’t like prefixes, then wait until the implementation is stable before you use it. Problem solved.

By: Syntaxis

Syntaxis — Tue, 23 Mar 2010 09:57:55 +0000

I’m in favor of removing the browser prefixes, but there should be a catch. As a webdeveloper you need to specify that you deliberately want to use a technology that is unfinished.
.
Why not start off your CSS-file with something like:
.
@experimental “true”;
.
Which results in the browser understanding that it should, in fact, use “-moz-box-shadow” where you specified “box-shadow”.
.
Alternatively, use this instead: @experimental “2010-03-23″; to specify that the browser should use the implementation of experimental rules at and before the date specified. That way it’ll always look the same until you either remove or update the timestamp.
.
But that’s all too late now anyway, so whatever. I’ll just keep using browser-specific stylesheets using @import, which only contain style definitions that use that browser’s unique prefix.

By: okonomiyaki3000

okonomiyaki3000 — Tue, 23 Mar 2010 04:56:25 +0000

@justinnt Transitions are not states but they do define how you get from one state to another. Think about it like this: there is a default transition, it is 0 seconds linear. We should be able to change that to anything we like.

I agree that we need more scriptable control over those kinds of things, maybe some events like onTransitionStart, onTransitionEnd, etc. But basically, as you said, when you need something like that, you can do it all in script. The question is, should you have to go to that trouble when all you want is to fade from one color to another? Having different ways to accomplish the same thing doesn’t hurt.

By: justinnt

justinnt — Tue, 23 Mar 2010 02:09:29 +0000

okonomiyaki: not sure what you mean. transitions are not states.
I’m not talking about purity, just utility :
while I do find myself using straight :hover,
whenever I want a css transition, I seem to want script hooks on it anyway, either on commencement, at each step or on callback,
and so I don’t bother declaring a css transition …

By: skippyK

skippyK — Tue, 23 Mar 2010 01:19:39 +0000

I’ve thought about this a lot, and I have to say, I think that vendor extensions definitely have to be at least tweaked. I think one of the most comprehensive solutions would be that “-vendor-propertyname” applies to all CSS properties and always overrides a generic “propertyname” for a rule with the same specificity. In other words, for any property, regardless of whether it’s experimental or a well established standard, “-vendor-” can target it. Ideally, this would be used rarely, in cases where one browser’s implementation differs from anothers.

However, that’s probably going to be abused, both by developers and by browser makers. Browser makers would just extend the “-vendor-” convention into “-vendor-version-”, “-vendor-version-renderingmode-”, etc. THen they’ll create make some property behave differently when applied via “-vendor-propertyname” vs. “propertyname”. And developers would use it to hack like crazy.

OK, so maybe just apply it to experimental features, knowing you can usually just use “propertyname” instead of “-vendor-propertyname”. That’s better, and the “-vendor-propertyname” still exists when browsers offer differing implementations.

But let’s consider just nuking them for a second. Yeah, we’re forced into situations where differing implementations will compete. Yeah, that gives incredible power to the first vendor to implement a proposed extension. Yeah, it’s going to cause some headaches.

But it’s simple. It’s very simple. It cannot be abused. It forces browser vendors to communicate, to propose openly and early, to craft the most easily understood spec. And no one will ever have to go back and change their code because the “-vendor-propertyname” has been deprecated. It makes CSS easier to write and easier to read.

Frankly, I’m on board with all three solutions, they’re all better than the current situation. The only part that’s vitally important is that no developer should ever have to include a vendor prefix. But if I had to choose, then I’m going to side with simplicity. As much as the flexibility of the first two options appeals to me, the simplicity of the third option forces everyone to be as forward looking as possible, and that’s a good thing.

By: okonomiyaki3000

okonomiyaki3000 — Tue, 23 Mar 2010 00:53:24 +0000

@justinnt If states like :hover, :focus, etc. belong in CSS, then so do transitions.

Personally, I like the vendor prefixes. They aren’t perfect but there’s a lot more good in them than bad.

The real problem is CSS itself. It’s broken and it’s getting brokener. Look, rounded corners were popular but required a lot of extra little images so it was thrown into css. Drop shadows were popular but required a lot of extra little images so they were thrown into css. Gradients were popular but required some extra images so they were thrown into css. All of this seems good on the surface but what next? Every design element that becomes popular will be thrown into css? The comment boxes on this page have a little arrow pointing to the byline, let’s have a css property for that!

What is needed is a more sophisticated, systematic approach to these things. I’d like to see an Advanced Style Sheet language that’s closer to a programming language. If done right, it would have a lot more power and flexibility and not require vendors to toss in new junk to solve specific problems. Oh, and unlike CSS, ASS would be an acronym.

By: digitalmechanic

digitalmechanic — Mon, 22 Mar 2010 23:49:02 +0000

One can minimize DRY by not repeating yourself. First define good base classes ONCE.

.round_corners {
…
}

Once defined, why is it even still an issue. Allowing vendors to skirt around the issue of non-standard css properties in this manner is a good thing. This allows for experimentation and reduces collisions between vendors. Not every browser implements the standard the same way.

People adopting these custom NON-STANDARD properties into their work is risky. Always has been, will always be. What I want to know is when did people start thinking differently?

By: justinnt

justinnt — Mon, 22 Mar 2010 23:46:32 +0000

not convinced that transitions belong in CSS anyway …

By: genericallyloud

genericallyloud — Mon, 22 Mar 2010 21:42:21 +0000

@eyelidlessness – I guess it depends on what your requirements of a complete solution are. As long as all of the information required to output the separate styles is provided to the template engine (or can be derived from the inputs) there should never be the problem. For rules that are exactly the same, you would supply some pretty simple arguments, for very different rules, you might have to do a little more work, but likely less than doing them all out by hand.

By: fzammetti

fzammetti — Mon, 22 Mar 2010 21:05:39 +0000

The prefixes are an eyesore, a codesmell, plain and simple. They lead to redundancy, complexity and ultimately make things harder to maintain down the road. The article is largely correct in this regard.

However… are they *necessary* at the present time? Yes. Are they the best solution to a larger problem? Very likely. Would the world be better off without them? Probably not, assuming nothing else changed to compensate.

So long as they are always a transitional thing, meaning as the specifications solidify and get implemented by the vendors then they start to go away, then that’s not so bad IMO. I wish we didn’t even have to have that be the case, but it’s not really the end of the world either I’d say and does serve a purpose.

It’s kind of like paying taxes… nobody really likes it, but we *do* derive some benefit from it, so even though it’s distasteful to many, you do it and understand why. Same here. Now, if only taxes were transitional… and no death, does not count! LOL

By: Joeri

Joeri — Mon, 22 Mar 2010 20:07:23 +0000

I don’t much care, to be honest. So you repeat the same style a few different ways? So what? Aren’t we all gzipping our stylesheets anyway? I remain to be convinced by this article that there’s a genuine problem here, other than an aesthetic one.

By: CorporalMaxSterling

CorporalMaxSterling — Mon, 22 Mar 2010 19:52:09 +0000

please, please, please just agree on something already and stop making us write so much repetitive damn code!!!!

By: V1

V1 — Mon, 22 Mar 2010 19:47:00 +0000

I never thought this day would come.. But i actually agree on something that @ThomasHansen posted..
.
I think they prefixes should stay untill they are stable enough to be implemented as “standards”

By: MattCoz

MattCoz — Mon, 22 Mar 2010 18:30:39 +0000

The browser prefixes are a necessary evil, the real problem is that it’s taking so long to get these properties standardized.

By: iliad

iliad — Mon, 22 Mar 2010 18:16:37 +0000

As pointed out, things like border-radius and gradients are implemented differently on webkit and mozilla so they need the prefixes. (Incidentally, why the heck is it border radius and not corner radius?)

What does need to happen is for the W3C to move faster. Why the heck is it taking so long to standardize border-radius? Most normal browsers (read not IE) had them for years.
On top of that, given our obsession with gradients in our web design, hurrying up the gradient spec would do so much to lighten the image load of websites. But definitely go with mozilla’s implementation, webkit’s is twice as verbose and three times as confusing.