3 ms·
To me, the article comes across as a bit of an uninformed rant. > I hope it does kill the W3C and CSS Working Group standardization process. To this, I have t
by lwhi 15y ago
To me, the article comes across as a bit of an uninformed rant.
> I hope it does kill the W3C and CSS Working Group standardization process.
To this, I have to ask "Mr Curtis - are you _CRAZY_?"(!)
Do you not realise that it's taken over 12 years to say good bye to IE6. Have you not had the pleasure of battling with the ramifications of a browser that doesn't play by the rules?
--
There are some understandable reasons for not making use of vendor prefixes.
The article that Dustin Curtis links to makes some valid points about the dangers of continuing to use vendor prefixes. A similar line of thinking is presented here [1]
The alternative to using vendor tags isn't to stop using the features - it's to simply drop the vendor prefixes and use the property names from the (non-ratified) CSS specifications before they're fully approved.
For all it's failings, the W3C does a grand job. Negotiations take time. Best we don't throw our toys out of the pram.
--
[1] http://www.quirksmode.org/blog/archives/2010/03/css_vendor_pref.html http://www.quirksmode.org/blog/archives/2010/03/css_vendor_p....
- tptacek 15y agoI think you're misinformed by what "the rules" are. W3C standards are not, in fact, an innovation speed limit. Vendors are free to implement whatever they'd like. The only way a vendor should be encumbered by the W3C is that if they choose to implement a feature, they should also support the W3C incarnation of that feature. That's it, full stop. The problem with IE6 isn't that it did extra things. It's that it did a variety of things (some extra, some not) badly, and then Microsoft refused to bring it into compliance. That's not a problem we have with Webkit. So what are you saying when you try to tar Webkit with the IE brush? How familiar are you with the development process behind Webkit?
- lwhi 15y agoIf you read the article referenced, you'd realise that web-kit isn't being picked on. The concept of using vendor-prefixes is being questioned. I'm not tarring webkit with an IE brush. I'm stating that without the W3C or similar body to set standards, we would in a far worse situation. The article spectacularly misses the point.
- tptacek 15y agoDo you have something to say about vendor prefixes? That's what we're talking about. I'm not particularly concerned about what particular blue ribbons we affix to the W3C. They're great. Now what?
- lwhi 15y agoThese links [1][2] provide some reasoning behind not using vendor extensions. The second is referenced in the article we're commenting on. I find it difficult to understand why much vitriol needs to be expended. [1] http://www.quirksmode.org/blog/archives/2010/03/css_vendor_pref.html http://www.quirksmode.org/blog/archives/2010/03/css_vendor_p... [2] http://www.glazman.org/weblog/dotclear/index.php?post/2012/02/09/CALL-FOR-ACTION:-THE-OPEN-WEB-NEEDS-YOU-NOW http://www.glazman.org/weblog/dotclear/index.php?post/2012/0...
- chc 15y agoThat QuirksMode article you posted includes an update acknowledging that it's wrong. I think the stance in the newer post it links to is more reasonable, though I'm still not sure it's all the way there.
- lwhi 15y agoThe article provides a summary of potential problems with vendor prefixes, which still stands. The author acknowledged that his suggested solution was wrong. See the redux [1] (which is actually mentioned in the article) for alternative solutions. My main concern is that the dcurt.is article misses the point entirely. [1] http://www.quirksmode.org/blog/archives/2010/03/css_vendor_pref_1.html http://www.quirksmode.org/blog/archives/2010/03/css_vendor_p...