The Browser Wars never ended
February 15, 2012 11:01 AM Subscribe
Is Webkit, the web browser engine used by Safari and Chrome, turning into IE6? Concern is growing that reliance on proprietry CSS features marked by vendor prefixes could be breaking the web.
Vendor prefixes and their discontents, by MeFi's own Dylan Wilbanks.
posted by Artw at 11:07 AM on February 15, 2012 [3 favorites]
posted by Artw at 11:07 AM on February 15, 2012 [3 favorites]
"other browsers will start supporting/implementing themselves the -webkit-* prefix, turning one single implementation into a new world-wide standard. It will turn a market share into a de facto standard, a single implementation into a world-wide monopoly. Again. It will kill our standardization process. That's not a question of if, that's a question of when."
I'm failing to see a problem here. If W3C and the other browser makers had their shit together, they'd have either gotten those features into the standard, or they'd have implemented them already.
I don't have any problem with webkit dominating the market place because A: It's open source and B: It's the best rendering engine.
posted by empath at 11:08 AM on February 15, 2012 [3 favorites]
I'm failing to see a problem here. If W3C and the other browser makers had their shit together, they'd have either gotten those features into the standard, or they'd have implemented them already.
I don't have any problem with webkit dominating the market place because A: It's open source and B: It's the best rendering engine.
posted by empath at 11:08 AM on February 15, 2012 [3 favorites]
Aw, come on, that's not fair. Just make everybody use Webkit browsers and then the problem is solved!
posted by kmz at 11:09 AM on February 15, 2012 [1 favorite]
posted by kmz at 11:09 AM on February 15, 2012 [1 favorite]
Especially if we're talking about Apple, which has far more power to bring in developers who don't care about following standards as long as it looks good on Apple products.
Apple doesn't own webkit.
posted by empath at 11:09 AM on February 15, 2012 [1 favorite]
Apple doesn't own webkit.
posted by empath at 11:09 AM on February 15, 2012 [1 favorite]
(well, I guess technically they do, but it's open source and anybody can use it.)
posted by empath at 11:11 AM on February 15, 2012
posted by empath at 11:11 AM on February 15, 2012
I'm not saying they own webkit, I'm saying that they could help push development of web technologies so everything css needs -webkit extensions to not look and feel like garbage.
posted by mcstayinskool at 11:12 AM on February 15, 2012
posted by mcstayinskool at 11:12 AM on February 15, 2012
Daniel Glazman (born 1967) is a JavaScript programmer, best known for his work on Mozilla's Editor and Composer components and Nvu, a standalone version of the Mozilla Composer... During 2000 he also worked at Amazon.fr and Halogen before joining Netscape Communications Corporation to work on Mozilla's CSS rendering, Editor and Composer.
Well, he certainly sounds unbiased. I'm sure this has nothing to do with this.
posted by entropicamericana at 11:12 AM on February 15, 2012 [1 favorite]
Well, he certainly sounds unbiased. I'm sure this has nothing to do with this.
posted by entropicamericana at 11:12 AM on February 15, 2012 [1 favorite]
empath: "I'm failing to see a problem here. If W3C and the other browser makers had their shit together, they'd have either gotten those features into the standard, or they'd have implemented them already."You can say this about any of the features that IE offered that were half-assed implemented. See MS's Msxml2.XMLHTTP. See webkit's original proprietary implementation of gradients: it was a bit of a cock-up and turned out to be very hard to use correctly. Look at the early webfont implementations that still hang around.
The standardization process is designed to catch those "oh, we never thought of that," and if you fail to take the time to think it out, you end up with a low-quality monoculture. Standards are too slow and no-standards are too crappy. The right solution isn't to simply a de facto chucking of the standards process, but some middle ground.
posted by introp at 11:14 AM on February 15, 2012 [4 favorites]
TBH I'm not that madly keen on Mozilla's insistence that what web standards really need is a requirement for an in-browser implementation of OpenGL either.
posted by Artw at 11:15 AM on February 15, 2012
posted by Artw at 11:15 AM on February 15, 2012
I'm not convinced at all that standards bodies arguing in committees produces innovation in a way that is better in the long run than popular vendors putting out their own stuff and letting their competition copy them to stay compatible. I seriously doubt that things like AJAX and most of the innovations that have evolved in web design could have been thought up ahead of time to be included in a standards document. Standards for the web should be about codifying things that are already implemented and widely adopted, not for handcuffing browser developers and web developers so that they can't use anything that isn't already in the standard. Otherwise you have perfectly stable standards that go nowhere and get abandoned for competing technologies that have room to add new features easily.
posted by burnmp3s at 11:17 AM on February 15, 2012 [6 favorites]
posted by burnmp3s at 11:17 AM on February 15, 2012 [6 favorites]
I should say that on further reflection I think this is less of a big deal than I originally thought. The -moz* -webkit*, etc. extensions have been there for quite some time, and a direct comparison to IE6 is probably not quite fair. Especially because IE6 did so much to grind innovation to a halt due to the impossibility of making cross-browser websites.
I don't care what browser or OS or <insert product here> anyone uses, but I do care if they are driven to not having a choice. That's something I think worthy of being concerned and vigilant about.
posted by mcstayinskool at 11:17 AM on February 15, 2012 [1 favorite]
I don't care what browser or OS or <insert product here> anyone uses, but I do care if they are driven to not having a choice. That's something I think worthy of being concerned and vigilant about.
posted by mcstayinskool at 11:17 AM on February 15, 2012 [1 favorite]
popular vendors putting out their own stuff and letting their competition copy them to stay compatible
Please destroy U.S. Software Patent law, and then we can discuss that possibility.
posted by mcstayinskool at 11:19 AM on February 15, 2012 [1 favorite]
Please destroy U.S. Software Patent law, and then we can discuss that possibility.
posted by mcstayinskool at 11:19 AM on February 15, 2012 [1 favorite]
I would submit that any situation that results in messages like "This site is designed only to work in ____________" are bad no matter what ___________ is.
posted by Artw at 11:19 AM on February 15, 2012 [12 favorites]
posted by Artw at 11:19 AM on February 15, 2012 [12 favorites]
Yeah, the problems with IE back in the IE-dominant days were that it sucked, was closed, broke things that worked, and was the dominant browser not on its own merits but because M$* was able to leverage their de-facto OS monopoly into browsers.
Safari / Chrome aren't nearly the same thing (although I do think Apple should allow non-webkit browsers on iOS if they haven't.)
* Retro!
posted by gauche at 11:21 AM on February 15, 2012
Safari / Chrome aren't nearly the same thing (although I do think Apple should allow non-webkit browsers on iOS if they haven't.)
* Retro!
posted by gauche at 11:21 AM on February 15, 2012
You can say this about any of the features that IE offered that were half-assed implemented. See MS's Msxml2.XMLHTTPMicrosoft's features were implemented using MS-centric technologies whereas WebKit's CSS features are created to be a cross-platform and cross-browser standard. I.e. the W3C could never take MS's features and make them a standard, but they can easily take the WebKit syntax as the new standard.
E.g. look at how IE6 implements transparency: filter: progid:DXImageTransform.Microsoft.AlphaImageLoader(src="..images/overlay.png", sizingMethod="scale");
Compare this to all the transition, tranformation and layout features that WebKit has added. Not a single 'Apple' specific name or base technology in the specification.
posted by flif at 11:22 AM on February 15, 2012 [2 favorites]
The big problem that web developers had with IE6 wasn't so much that it was non-standard, but that it was awful. People are using these webkit-specific features because they *look cool*. People had the opposite problem with IE.
All software, web-based or otherwise, has always been designed to work in specific environments. Some of those environments are more restrictive than others. "Works only in IE6" is pretty restrictive. "Works only in HTML5-capable browsers" is less so, but it still doesn't include everybody (like, say, IE6 users). Developers have to make a call on what they want to support when they start building software, and most of these decisions, in the real world, are based on what platforms the majority of paying customers are using.
Whatever environment you're targeting as a developer, you're leaving out somebody. I work on browser extensions for Chrome and Safari. Guess what -- they only work in webkit. Yes. I know. They're supposed to.
posted by tylerkaraszewski at 11:28 AM on February 15, 2012 [2 favorites]
All software, web-based or otherwise, has always been designed to work in specific environments. Some of those environments are more restrictive than others. "Works only in IE6" is pretty restrictive. "Works only in HTML5-capable browsers" is less so, but it still doesn't include everybody (like, say, IE6 users). Developers have to make a call on what they want to support when they start building software, and most of these decisions, in the real world, are based on what platforms the majority of paying customers are using.
Whatever environment you're targeting as a developer, you're leaving out somebody. I work on browser extensions for Chrome and Safari. Guess what -- they only work in webkit. Yes. I know. They're supposed to.
posted by tylerkaraszewski at 11:28 AM on February 15, 2012 [2 favorites]
Daniel Glazman (born 1967) is a JavaScript programmer, best known for his work on Mozilla's Editor and Composer components and Nvu, a standalone version of the Mozilla Composer... During 2000 he also worked at Amazon.fr and Halogen before joining Netscape Communications Corporation to work on Mozilla's CSS rendering, Editor and Composer.
I'm curious to learn how Mozilla expects WebKit to be more standards-compliant, when Safari and Chrome pass standards tests with full marks, while Mozilla Firefox does not (and by choice).
posted by Blazecock Pileon at 11:35 AM on February 15, 2012 [4 favorites]
I'm curious to learn how Mozilla expects WebKit to be more standards-compliant, when Safari and Chrome pass standards tests with full marks, while Mozilla Firefox does not (and by choice).
posted by Blazecock Pileon at 11:35 AM on February 15, 2012 [4 favorites]
The right solution isn't to simply a de facto chucking of the standards process, but some middle ground.
There is no middle ground. You either wait and implement the standards, or you do something else which will certainly not be standard compliant and will probably be incompatible with anyone else doing something in the same space.
And, waiting for CSS3? I'd actually bet on us finding a cure for cancer before CSS3 is a finished standard. Yes, we should propose a standard for new features, but if W3C's backlog is that deep, I won't need that feature by the time it is actually a standard.
I'd love to have a standards compliant web, but for fuck's sake, CSS2 was declared a standard in 1997, and CSS3 started in 1998, and it is **nowhere near done**. There are over 50 modules published by W3C, and exactly three of them are Recommended Standards -- Selectors, Namespaces, Color.
I used to be the biggest advocate of standard compliance, but they're not actually publishing useful standards. How can I be compliant with 3/50ths of a standard?
You need to have a standard, that works, and is *published* so people can build to it and expect to work. Since W3C is clearly incapable of doing so, I cannot see why anyone would wait for them anymore. I know standards writing is like herding cats, but CSS3 is beyond Duke Nukem vaporware. Hell, the SMTP standard has been updated vastly more recently (RFC 5321, in 2008.)
So, I don't blame Webkit and others for going vendor specific. Indeed, what I'd be doing is going exclusively that, and if W3C doesn't like that, tell them you'd be happy to implement CSS3 when they actually publish it.
posted by eriko at 11:38 AM on February 15, 2012 [4 favorites]
There is no middle ground. You either wait and implement the standards, or you do something else which will certainly not be standard compliant and will probably be incompatible with anyone else doing something in the same space.
And, waiting for CSS3? I'd actually bet on us finding a cure for cancer before CSS3 is a finished standard. Yes, we should propose a standard for new features, but if W3C's backlog is that deep, I won't need that feature by the time it is actually a standard.
I'd love to have a standards compliant web, but for fuck's sake, CSS2 was declared a standard in 1997, and CSS3 started in 1998, and it is **nowhere near done**. There are over 50 modules published by W3C, and exactly three of them are Recommended Standards -- Selectors, Namespaces, Color.
I used to be the biggest advocate of standard compliance, but they're not actually publishing useful standards. How can I be compliant with 3/50ths of a standard?
You need to have a standard, that works, and is *published* so people can build to it and expect to work. Since W3C is clearly incapable of doing so, I cannot see why anyone would wait for them anymore. I know standards writing is like herding cats, but CSS3 is beyond Duke Nukem vaporware. Hell, the SMTP standard has been updated vastly more recently (RFC 5321, in 2008.)
So, I don't blame Webkit and others for going vendor specific. Indeed, what I'd be doing is going exclusively that, and if W3C doesn't like that, tell them you'd be happy to implement CSS3 when they actually publish it.
posted by eriko at 11:38 AM on February 15, 2012 [4 favorites]
The big difference between IE6 and Webkit is that most web devs these rely, in whole or in part, on a wide selection of really good Javascript toolkits to achieve cross-platform nirvana. Web devs aren't enshrining webkits vendor extensions; the toolkits are hiding them behind decent APIs. Deprecate the vendor extensions, the toolkits follow, and the guys actually writing CSS don't notice.
Seriously, the quality of CSS and Javascript toolkits these days is such that anyone interviewing for a web dev position needs to be able to talk competently on the differences between them, lest you look like an app programmer who scoffs at using C because assembler was good enough for his grampy, and it's good enough for him!
posted by fatbird at 11:41 AM on February 15, 2012 [1 favorite]
Seriously, the quality of CSS and Javascript toolkits these days is such that anyone interviewing for a web dev position needs to be able to talk competently on the differences between them, lest you look like an app programmer who scoffs at using C because assembler was good enough for his grampy, and it's good enough for him!
posted by fatbird at 11:41 AM on February 15, 2012 [1 favorite]
IE6 is less than 1% of marketshare, isn't it? Why would anyone be wasting money trying to cover such a small segment of the population? If they are locked down by their corporate network, chances are they aren't a profit center anyways, unless you are marketing your website to corporations that need a new IT department.
I'm curious to learn how Mozilla expects WebKit to be more standards-compliant, when Safari and Chrome pass standards tests with full marks, while Mozilla Firefox does not (and by choice).
Exactly. Let the standards body define standards, and let vendors get there any way they like, or break everything if they want to. With the rise of jQuery and jQuery mobile, I prefer using a framework anyway, and letting a team of übernerrds handle the hard stuff.
posted by deanklear at 11:43 AM on February 15, 2012
I'm curious to learn how Mozilla expects WebKit to be more standards-compliant, when Safari and Chrome pass standards tests with full marks, while Mozilla Firefox does not (and by choice).
Exactly. Let the standards body define standards, and let vendors get there any way they like, or break everything if they want to. With the rise of jQuery and jQuery mobile, I prefer using a framework anyway, and letting a team of übernerrds handle the hard stuff.
posted by deanklear at 11:43 AM on February 15, 2012
Artw: "I would submit that any situation that results in messages like "This site is designed only to work in ____________" are bad no matter what ___________ is."
This website is designed only to work in universes where spacetime is a differentiable manifold.
posted by idiopath at 11:45 AM on February 15, 2012 [1 favorite]
This website is designed only to work in universes where spacetime is a differentiable manifold.
posted by idiopath at 11:45 AM on February 15, 2012 [1 favorite]
It's a false dichotomy, though. If the W3C is too slow, make another "standards" body. WHATWG, for all its hairy warts, is a great example of this.
If you cede the requirement for strong community standards, you end up with the biggest player making the rules. You might as well drop the "-webkit" prefix and just call it the base name, because it will become the de facto standard. Maybe that doesn't seem so bad for something like a drop shadow, but functionality follows close behind and that's a slippery slope. We've already been down that path a dozen times on the web. (See most recently: HTML5 video H.264 vs. free codecs. The disagreements in committee bodies are real and, some large portion of the time, founded on real practical concerns.)
posted by introp at 11:45 AM on February 15, 2012 [1 favorite]
If you cede the requirement for strong community standards, you end up with the biggest player making the rules. You might as well drop the "-webkit" prefix and just call it the base name, because it will become the de facto standard. Maybe that doesn't seem so bad for something like a drop shadow, but functionality follows close behind and that's a slippery slope. We've already been down that path a dozen times on the web. (See most recently: HTML5 video H.264 vs. free codecs. The disagreements in committee bodies are real and, some large portion of the time, founded on real practical concerns.)
posted by introp at 11:45 AM on February 15, 2012 [1 favorite]
It seems pretty simple to me, if what you want to design requires that you use these kinds of prefixes and there's just no other way to implement your desires, then you have two options.
1) You can do it now, the wrong way, and YOU OWN THAT MISTAKE brother. Do not complain about browsers, because you, the developer, are responsible for making this decision. Nobody is forcing you to do this.
2) You can admit to yourself that the web simply doesn't support that desire yet. So what? Go back to the drawing board and figure out a more inventive way to make do with what tools you do have. If that's totally impossible, well, square peg round hole.
I'm sorry, but bad web development is the fault of developers. It's possible to accomplish an awful lot on the web without resorting to sniffing, conditional crap, and a million and one "tricks of the trade" that rely on various software eccentricities. Is it harder to do things the right way? Does it take longer? Might you have to patiently explain this to, or even fight with, a designer or project manager?
YES. Welcome to being a web developer. Sack up or get out.
posted by trackofalljades at 11:47 AM on February 15, 2012 [2 favorites]
1) You can do it now, the wrong way, and YOU OWN THAT MISTAKE brother. Do not complain about browsers, because you, the developer, are responsible for making this decision. Nobody is forcing you to do this.
2) You can admit to yourself that the web simply doesn't support that desire yet. So what? Go back to the drawing board and figure out a more inventive way to make do with what tools you do have. If that's totally impossible, well, square peg round hole.
I'm sorry, but bad web development is the fault of developers. It's possible to accomplish an awful lot on the web without resorting to sniffing, conditional crap, and a million and one "tricks of the trade" that rely on various software eccentricities. Is it harder to do things the right way? Does it take longer? Might you have to patiently explain this to, or even fight with, a designer or project manager?
YES. Welcome to being a web developer. Sack up or get out.
posted by trackofalljades at 11:47 AM on February 15, 2012 [2 favorites]
This argument? Again? When I read Lea's article yesterday I cringed, not because I don't disagree with her general argument, but the sentiment that we had to wait how many years for CSS2? How many years until CSS3? So then what do I call something that works in the majority of browsers and gracefully degrades elsewhere? How am I supposed to continue to hone my craft and promote myself if I can't actually call these features CSS?
There are enough tools out there that allow designers to write the standard/generic property and then have it kick out the appropriate vendor prefixes that I really don't think this is an issue anymore. We've gone back and forth and back and forth, and without competition and pushing the envelope, shit doesn't get done. Those of us who spend our livelihoods designing and developing for the web, those of us who thrive on the best user experiences and means to convey data rely on these features and use them to promote them as best practices not only amongst other designers but the standards community as well. If you're a part of any of the mailing lists, you can see what a cluster it all is and how backwards some of the thinking can be. It's frequent that I hear someone raging about how a certain feature is totally pointless, when I'd been looking for that exact thing for years.
In all aspects of life, you are limited to certain features depending on your choices. The web is an experimental medium, and if we're not experimenting, we're sitting stagnant in a pool of dated standards and an ugly internet governed by what sometimes seems like a group of people who aren't even in this gig anymore.
posted by june made him a gemini at 11:48 AM on February 15, 2012 [2 favorites]
There are enough tools out there that allow designers to write the standard/generic property and then have it kick out the appropriate vendor prefixes that I really don't think this is an issue anymore. We've gone back and forth and back and forth, and without competition and pushing the envelope, shit doesn't get done. Those of us who spend our livelihoods designing and developing for the web, those of us who thrive on the best user experiences and means to convey data rely on these features and use them to promote them as best practices not only amongst other designers but the standards community as well. If you're a part of any of the mailing lists, you can see what a cluster it all is and how backwards some of the thinking can be. It's frequent that I hear someone raging about how a certain feature is totally pointless, when I'd been looking for that exact thing for years.
In all aspects of life, you are limited to certain features depending on your choices. The web is an experimental medium, and if we're not experimenting, we're sitting stagnant in a pool of dated standards and an ugly internet governed by what sometimes seems like a group of people who aren't even in this gig anymore.
posted by june made him a gemini at 11:48 AM on February 15, 2012 [2 favorites]
This is political nonsense. Full disclosure: Glazman is the co-chairman for the W3C, the group that writes web standards. The W3C of course disapproves of non-W3C-approved CSS properties.
Today's Webkit is nothing like IE6. IE6 had limited support for the CSS standard of its day. Webkit has excellent support for the standard. It also has its own experimental CSS properties, things that Webkit developers think might be nice to try out, but that aren't part of the standard.
It shouldn't matter. If your website only works with the Webkit experimental CSS properties, you should fire your web developers. Modern websites should degrade gracefully. There is plenty of room for browser vendors to experiment. Progressive enhancement is standard practice for web developers today and allows us to have all the nice things that older browsers don't support.
Basically, this is a non-story. Glazman is echoing the political position of his organization: "don't do anything outside the standards, which we control".
posted by deathpanels at 11:50 AM on February 15, 2012 [8 favorites]
Today's Webkit is nothing like IE6. IE6 had limited support for the CSS standard of its day. Webkit has excellent support for the standard. It also has its own experimental CSS properties, things that Webkit developers think might be nice to try out, but that aren't part of the standard.
It shouldn't matter. If your website only works with the Webkit experimental CSS properties, you should fire your web developers. Modern websites should degrade gracefully. There is plenty of room for browser vendors to experiment. Progressive enhancement is standard practice for web developers today and allows us to have all the nice things that older browsers don't support.
Basically, this is a non-story. Glazman is echoing the political position of his organization: "don't do anything outside the standards, which we control".
posted by deathpanels at 11:50 AM on February 15, 2012 [8 favorites]
WHATWG, for all its hairy warts, is a great example of this.
Pff. WHATWG is basically a vendor for T-Shirts that say "USE ALL THE SHINY THINGS!" and that's about it.
posted by Artw at 11:52 AM on February 15, 2012 [1 favorite]
Pff. WHATWG is basically a vendor for T-Shirts that say "USE ALL THE SHINY THINGS!" and that's about it.
posted by Artw at 11:52 AM on February 15, 2012 [1 favorite]
1. I actually don't mind the vendor prefixes (now that I'm used to them). It introduces some granularity. Mozilla adopting webkit is a mistake, I think.
2. Contrary to what was said above, webkit is the worst engine in my opinion. It does webfonts pretty badly. Although I test in every browser, I use Firefox exclusively personally. Opera's engine (Presto) displays the most gorgeously of them all, though.
posted by Benny Andajetz at 11:53 AM on February 15, 2012 [1 favorite]
2. Contrary to what was said above, webkit is the worst engine in my opinion. It does webfonts pretty badly. Although I test in every browser, I use Firefox exclusively personally. Opera's engine (Presto) displays the most gorgeously of them all, though.
posted by Benny Andajetz at 11:53 AM on February 15, 2012 [1 favorite]
I have totally given up on having valid CSS anymore, though.
posted by Benny Andajetz at 11:55 AM on February 15, 2012
posted by Benny Andajetz at 11:55 AM on February 15, 2012
I'm not convinced at all that standards bodies arguing in committees produces innovation in a way that is better in the long run than popular vendors putting out their own stuff and letting their competition copy them to stay compatible.Generally speaking, innovation is not what standards are for.
Standards for the web should be about codifying things that are already implemented and widely adopted, not for handcuffing browser developers and web developers so that they can't use anything that isn't already in the standard.The question here is what “widely adopted” means. Vendor prefixes are intended to address this by making it possible for different developers to approach problems in their own ways before nagging the standards committees. Border-radius is an excellent example, where the -moz-, -webkit- and -o- versions all converged on a shared syntax that was adopted as a single “border-radius” property.
The stupid thing about this whole debate is that it’s only really an issue because Mozilla is flustered about people selecting the Webkit-specific properties for their sites, and Mozilla is responding by making their browser respond to someone else’s vendor prefixes. Webkit might be moving a little quickly for everyone else but I think their extension ideas are fundamentally in good faith with regard to the standards process. Mozilla is letting themselves get pushed around for no good reason, and letting their fear show.
Daniel Glazman’s suggested approach is the right one and I think it’s being misunderstood in this thread: Mozilla’s response should be to ensure that every -webkit- property they want to support works as a -moz- property, and then target web developers with a search/replace campaign showing how easy it is to add the additional property, while at the same time working with the W3C to ensure that the prefixed properties are suitable for adoption as non-prefixed standards.
Web developers who complain about having to put in three or four different prefixed rules for a single property are whiners, IMHO. We’re in a time of rapid evolution, and as a site designer you need to do that one bit of extra work to address a heterogenous environment.
Or, what trackofalljades said.
posted by migurski at 11:55 AM on February 15, 2012
I've found Safari incredibly unstable in Mac OS X Lion, creased every day, crashed on restart, etc. It improved once I installed AdBlock, Ghostery, FlashBlock, and JavaScript Blacklist.
posted by jeffburdges at 11:56 AM on February 15, 2012 [2 favorites]
posted by jeffburdges at 11:56 AM on February 15, 2012 [2 favorites]
To be clear, Firefox, IE and Opera also support these features. In most cases, the -webkit properties being used have -moz, -ms and -o prefix equivalents for use in the respective browsers. Popular CSS 3 features like border-radius, transforms, gradients and animations work in all modern browsers. Developers simply need to add those three additional lines of code to make their websites compatible with Firefox, IE and Opera. But they aren’t doing that.
That the problem lies with web developers, not the browsers, led Glazman, to put out a call for action, asking web developers to “stop designing web sites for WebKit only, in particular when adding support for other browsers is only a matter of adding a few extra prefixed CSS properties.”
webkit isnt breaking the web you are
posted by zeoslap at 11:57 AM on February 15, 2012 [5 favorites]
That the problem lies with web developers, not the browsers, led Glazman, to put out a call for action, asking web developers to “stop designing web sites for WebKit only, in particular when adding support for other browsers is only a matter of adding a few extra prefixed CSS properties.”
webkit isnt breaking the web you are
posted by zeoslap at 11:57 AM on February 15, 2012 [5 favorites]
webkit isnt breaking the web you are
Agreed. I assume those who believe this is at all like the IE6 (and before) debacle weren't doing CSS then. It was a fucking nightmare getting cross-browser pages that didn't look like they'd been designed 5 years before. Javascript was even worse, in those dark days before decent, widespread libraries.
Today, even it you're too lazy to make your pages look exactly the same in all browsers, it's easy as pie to just optimize for 1 browser and degrade gracefully on the others.
The IE6 days are over, and -- thankfully -- aren't coming back.
tl;dr: Kids today whine about everything.
posted by coolguymichael at 12:11 PM on February 15, 2012 [2 favorites]
Agreed. I assume those who believe this is at all like the IE6 (and before) debacle weren't doing CSS then. It was a fucking nightmare getting cross-browser pages that didn't look like they'd been designed 5 years before. Javascript was even worse, in those dark days before decent, widespread libraries.
Today, even it you're too lazy to make your pages look exactly the same in all browsers, it's easy as pie to just optimize for 1 browser and degrade gracefully on the others.
The IE6 days are over, and -- thankfully -- aren't coming back.
tl;dr: Kids today whine about everything.
posted by coolguymichael at 12:11 PM on February 15, 2012 [2 favorites]
That's it, I'm finally learning how to use
<mutter>kids ... telnet ..... lawn ..... in my day ...... lawn ..... port 80 ... kids</mutter>
posted by benito.strauss at 12:13 PM on February 15, 2012 [2 favorites]
lynx.<mutter>kids ... telnet ..... lawn ..... in my day ...... lawn ..... port 80 ... kids</mutter>
posted by benito.strauss at 12:13 PM on February 15, 2012 [2 favorites]
The best rebuttal I've seen to this ridiculous argument about WebKit breaking the web is from Dustin Curtis.
The reality today is that web technology is currently being advanced by Google (via Chrome, V8, and WebKit) and Mozilla via Firefox. IE is struggling to keep up and Safari's out there reminding us you have to work around old bugs in WebKit. I'm pretty OK with that state of affairs.
posted by Nelson at 12:20 PM on February 15, 2012 [2 favorites]
That "HTML5" has taken six years to become a "standard recommendation" (it is still not an approved, official W3C standard, and won't be until at least 2014) is a huge disservice to the evolution of the internet.See also WHATWG, the original group that formed in 2004 to work around the completely useless W3C organization. Without them there'd be no HTML5.
The reality today is that web technology is currently being advanced by Google (via Chrome, V8, and WebKit) and Mozilla via Firefox. IE is struggling to keep up and Safari's out there reminding us you have to work around old bugs in WebKit. I'm pretty OK with that state of affairs.
posted by Nelson at 12:20 PM on February 15, 2012 [2 favorites]
See most recently: HTML5 video H.264 vs. free codecs. The disagreements in committee bodies are real and, some large portion of the time, founded on real practical concerns
The fact that in 2012 people are still arguing about how to implement something as basic as embedding a video in a HTML page is a good example of how backwards it is to expect a standards committee to do a good job driving innovation. Imagine if web developers had just sat on their hands and waited for an HTML video tag to be supported in every web browser before using video on websites. Flash became the dominant way to show video on the web because the HTML standard didn't support it and developers had to figure out a way to get video working on the web outside of the standard. If straying from the standards is "breaking the web," then pretty much every major part of HTML that exists today is the result of somebody breaking the web to add a new feature. This goes all the way back to things as basic as the img tag, it became a web standard because someone shipped code that implemented it, not because there was a consensus between everyone to implement it that way.
posted by burnmp3s at 12:23 PM on February 15, 2012
The fact that in 2012 people are still arguing about how to implement something as basic as embedding a video in a HTML page is a good example of how backwards it is to expect a standards committee to do a good job driving innovation. Imagine if web developers had just sat on their hands and waited for an HTML video tag to be supported in every web browser before using video on websites. Flash became the dominant way to show video on the web because the HTML standard didn't support it and developers had to figure out a way to get video working on the web outside of the standard. If straying from the standards is "breaking the web," then pretty much every major part of HTML that exists today is the result of somebody breaking the web to add a new feature. This goes all the way back to things as basic as the img tag, it became a web standard because someone shipped code that implemented it, not because there was a consensus between everyone to implement it that way.
posted by burnmp3s at 12:23 PM on February 15, 2012
I only use -amaya- and -lynx- extensions.
posted by kmz at 12:23 PM on February 15, 2012 [4 favorites]
posted by kmz at 12:23 PM on February 15, 2012 [4 favorites]
Guys, the link isn't loading on my MSN WebTV. Can anybody post a transcript here?
posted by Threeway Handshake at 12:32 PM on February 15, 2012 [2 favorites]
posted by Threeway Handshake at 12:32 PM on February 15, 2012 [2 favorites]
Mostly agree with zeoslap's link (I came in here to post it) -- the main problem here is developers who've decided "The Web" means a small set of their favored browsers.
As far as I'm concerned, if you're not spending at least a little bit of time thinking about at least basic support for older and limited browsers (including not just IE6 but circa 2004 Series 40 Nokia Phones, WebTV, and Lynx), then you're probably doing it wrong. And if you're only using webkit prefixes, you're definitely doing it wrong.
I'm sympathetic to the argument that prefixes are creating something of a problem, though. The intention was good, but what we've ended up with makes it inconvenient and somewhat annoying to do the right thing. There's got to be a better scheme.
If nothing else, I think things would probably be better if for every `-vendor-css-property` the corresponding `css-property` was *at least* aliased to it. That'd let vendors experiment without making developers type so much. If the property wasn't supported elsewhere, it'd be ignored. If it's supported *differently* elsewhere -- or if, in the end when CSS3 actually finalizes, the spec says something different for some reason (as happened with Microsoft and clip if I recall) -- the vendor prefixes let devs get specific about which implementation.
Or if we can't bring ourselves to implement something so final and bold as `property` before it's finalized, at least a common `-draft-property` mapping to each `-vendor-property` could help.
posted by weston at 12:37 PM on February 15, 2012 [1 favorite]
As far as I'm concerned, if you're not spending at least a little bit of time thinking about at least basic support for older and limited browsers (including not just IE6 but circa 2004 Series 40 Nokia Phones, WebTV, and Lynx), then you're probably doing it wrong. And if you're only using webkit prefixes, you're definitely doing it wrong.
I'm sympathetic to the argument that prefixes are creating something of a problem, though. The intention was good, but what we've ended up with makes it inconvenient and somewhat annoying to do the right thing. There's got to be a better scheme.
If nothing else, I think things would probably be better if for every `-vendor-css-property` the corresponding `css-property` was *at least* aliased to it. That'd let vendors experiment without making developers type so much. If the property wasn't supported elsewhere, it'd be ignored. If it's supported *differently* elsewhere -- or if, in the end when CSS3 actually finalizes, the spec says something different for some reason (as happened with Microsoft and clip if I recall) -- the vendor prefixes let devs get specific about which implementation.
Or if we can't bring ourselves to implement something so final and bold as `property` before it's finalized, at least a common `-draft-property` mapping to each `-vendor-property` could help.
posted by weston at 12:37 PM on February 15, 2012 [1 favorite]
Apologies if it's already been mentioned, but quirksmode weighs in on the issue here.
posted by juv3nal at 1:00 PM on February 15, 2012 [3 favorites]
posted by juv3nal at 1:00 PM on February 15, 2012 [3 favorites]
From quirksmode...
What’s important to note here is that the problem is with the prefixes, and not with web developers. If standards make web developers’ lives much harder, web developers ignore standards. This was true back in 1998, it’s still true today.
Vendor prefixes are the most developer-hostile solution imaginable. The vendor prefix idea was flawed from the start by putting the full brunt of namespace management on web developers.
...nails it.
They add a mess of vendor prefixes on top of the dogs' dinner of partial implementation that the CSS standards already are, then get surprised it doesn't turn out so well? Couldn't have seen that coming...
Standards organizations will always be behind the market - they should be. Their job is to formalize what already exists, not invent technologies from whole cloth, as if they could do that better than the industry. That's why CSS is a horrible technology. I had to laugh when Crockford descibed those who defend it as behaving like an abused spouse "...but you just don't understand it like I do..."
Short of a complete re-write so it follows some kind of logic derivable by mortals and encapsulates some kind of object-oriented behavior, what quirksmode suggests is the next best thing, I'd say.
posted by normy at 1:26 PM on February 15, 2012 [2 favorites]
What’s important to note here is that the problem is with the prefixes, and not with web developers. If standards make web developers’ lives much harder, web developers ignore standards. This was true back in 1998, it’s still true today.
Vendor prefixes are the most developer-hostile solution imaginable. The vendor prefix idea was flawed from the start by putting the full brunt of namespace management on web developers.
...nails it.
They add a mess of vendor prefixes on top of the dogs' dinner of partial implementation that the CSS standards already are, then get surprised it doesn't turn out so well? Couldn't have seen that coming...
Standards organizations will always be behind the market - they should be. Their job is to formalize what already exists, not invent technologies from whole cloth, as if they could do that better than the industry. That's why CSS is a horrible technology. I had to laugh when Crockford descibed those who defend it as behaving like an abused spouse "...but you just don't understand it like I do..."
Short of a complete re-write so it follows some kind of logic derivable by mortals and encapsulates some kind of object-oriented behavior, what quirksmode suggests is the next best thing, I'd say.
posted by normy at 1:26 PM on February 15, 2012 [2 favorites]
Vendor prefixes and their discontents, by MeFi's own Dylan Wilbanks.
THIS GUY IS A TOTAL IDIOT HE DOESN'T KNOW WHAT HE'S TALKING ABOUT wait that's me.
The one thing I didn't say in my blog post was that I want vendor prefixes to stay vendor prefixes as much as possible. I really don't like the -beta prefix idea -- I'd really rather let each browser render things in their own way, warts and all, so if there's disagreement we can compare and say "I like -o-soft-serve-ice-cream-flavor for determining ice cream flavor because it's less cumbersome and more extensible than -webkit-ice-cream-flavor-soft-serve."
The real problem with Webkit was that Apple openly promoted their vendor-specific CSS early and often. I remember an Apple guy telling me at an iPhone training way back in 2007 to use the -webkit specific stuff. And as Apple built up their almost untouchable market share they've continued to push them in their documentation.
Someone upthread said something about "in absence of standards the largest market share dictates the rules." I'd argue that even WITH standards Apple is essentially dictating the present and future of the web. So we either need to accelerate the standards process -- and end up with the WHATWG fiasco (where you have a dictator unilaterally declaring the rules in a partial vacuum) -- or we need to improve the innovation iteration process. But so long as Apple and Microsoft and Google all have no skin in the standards game other than sending their people to meetings to fight over meaningless quibbles like this -webkit fiasco, we may well be stuck with a continual tension between vendors, dictators running off doing their thing, and the occasional step forward from the W3C. In other words, the status quo right now.
posted by dw at 1:31 PM on February 15, 2012 [3 favorites]
THIS GUY IS A TOTAL IDIOT HE DOESN'T KNOW WHAT HE'S TALKING ABOUT wait that's me.
The one thing I didn't say in my blog post was that I want vendor prefixes to stay vendor prefixes as much as possible. I really don't like the -beta prefix idea -- I'd really rather let each browser render things in their own way, warts and all, so if there's disagreement we can compare and say "I like -o-soft-serve-ice-cream-flavor for determining ice cream flavor because it's less cumbersome and more extensible than -webkit-ice-cream-flavor-soft-serve."
The real problem with Webkit was that Apple openly promoted their vendor-specific CSS early and often. I remember an Apple guy telling me at an iPhone training way back in 2007 to use the -webkit specific stuff. And as Apple built up their almost untouchable market share they've continued to push them in their documentation.
Someone upthread said something about "in absence of standards the largest market share dictates the rules." I'd argue that even WITH standards Apple is essentially dictating the present and future of the web. So we either need to accelerate the standards process -- and end up with the WHATWG fiasco (where you have a dictator unilaterally declaring the rules in a partial vacuum) -- or we need to improve the innovation iteration process. But so long as Apple and Microsoft and Google all have no skin in the standards game other than sending their people to meetings to fight over meaningless quibbles like this -webkit fiasco, we may well be stuck with a continual tension between vendors, dictators running off doing their thing, and the occasional step forward from the W3C. In other words, the status quo right now.
posted by dw at 1:31 PM on February 15, 2012 [3 favorites]
Funny to see this here today. I was just reading a few opinions on this this morning.
Here's mine:
An aside: I'm seeing a lot of complaints mixed into this discussion about how the W3C won't adopt individual develoeprs' pet features into CSS. The core issue here is that the W3C are dragging their feet to adopt standards for CSS properties that are already very obviously destined to become an integral part of the web in the very near future (especially simple stuff like gradients, box rounding, etc). However, this is being muddled by the dissatisfaction of some developers that CSS is not being turned into a turing-complete language. Admittedly, it'd be nice to be able to define constants for reuse within a stylesheet, although I'm sympathetic toward the argument that we should CSS simple. Let's debate one issue at a time. As much as I love job security, we're hurtling toward the web language bloat singularity... posted by schmod at 1:58 PM on February 15, 2012 [1 favorite]
Here's mine:
- The W3C has indeed been dragging its feet. This isn't necessarily a bad thing, as you sort of want a group like the W3C to be overly cautious and conservative. (Although it sure doesn't forgive all of their sins)
- However, we still want to be able to use bleeding-edge features, preferably ones that gracefully degrade on older browsers. We also want these features to be forward compatible with the final standard once it's been ratified. We want things to work today, and to be elegant tomorrow. In practice, this is kind of tricky.
- I do think that developers can safely use these new extensions without too much of a kludge. CSS preprocessors/compilers can add vendor-specific prefixes (and official W3C properties) to stylesheets, while various JavaScript polyfills are available to translate the bleeding-edge CSS properties into a format that the browser can understand at runtime.
- I would cautiously surmise that the current best practice is to:
- Write CSS stylesheets without vendor-specific prefixes. You want your .CSS files to be legal, compliant CSS. CSS preprocessors and compilers have their uses, although I would argue that they should not be used to add non-compliant features to the stylesheet. That should be done at runtime if possible.
- However, you can still (cautiously) use bleeding-edge features. Just don't depend on them, don't use vendor-specific prefixes in your raw CSS, and try to add them at runtime if possible. Use feature detection to selectively load polyfills and add vendor-specific prefixes to the CSS where necesary on a browser-by-browser basis so that new features are supported, and vendor-specific prefixes are added. If the bleeding-edge feature you're using has been standardized, and is supported (as a standard) in the user's browser, the feature detection script does nothing, and everyone is happy.
- Ideally, you'd fetch these scripts from a reliable CDN so that they're continuously updated/maintained by developer, and also cached from site to site.
- This is all sort of tricky, but implemented properly souldn't "break the web" like IE6 did. It's the price you need to pay if you want to use bleeding-edge features. We'd "break the web" if Mozilla implemented webkit-specific prefixes incorrectly. IE6's nasty legacy has little to do with the fact that it implemented proprietary extensions; those things are mostly still there in IE9 (and then some), and aren't an issue at all from a compatibility perspective (the ActiveX/VbScript security nightmare is a different topic). The problem came from the fact that IE6 ostensibly implemented the same standards as everybody else, but did so poorly, incompletely, and inconsistently (for instance, IE's JavaScript getElementById method prefers to retrieve elements by name instead of id; can you seriously tell me with a straight face that this isn't a bug? and, oh god, oh god; I just got a flashback of an ill-fated project I worked on to develop a rich webapp for BlackBerry OS 4; RIM built their old browser around IE 5.5's DOM implementation, and somehow managed to botch that; they broke their implementation of a broken browser, and were shipping it with new phones as recently as last year).
It would be a terrible idea for Mozilla to support WebKit's non-standardized vendor-specific prefixes for all these same reasons (not to mention that the WebKit project has major issues with documentation and consistency, both of which Mozilla have coincidentally gotten quite good at recently). Developers should be encouraged to use JavaScript middleware to support nonstandard or bleeding-edge CSS features (like what JQuery did for JavaScript), and the W3C and browser developers should be forcibly coerced into supporting and standardizing new features that have strong demand and consensus. (I'm looking at you, Apple. Even IE supports box-shadow without a funky prefix.)
The fact that in 2012 people are still arguing about how to implement something as basic as embedding a video in a HTML page is a good example of how backwards it is to expect a standards committee to do a good job driving innovation.Much of the argument is focused on encodings and software patents. This is not a herp-derp-what-do-we-do ivory tower debate, it’s a real legitimate argument among competing businesses bristling with patent portfolios and still trying to meet someplace in the middle. If all you want to do is throw video in a browser, Macromedia had an answer for you a decade ago and Youtube took it all the way to the bank. If you want to do it in a way that’s usable by new technologies outside of cumbersome licensing deals, you get the debate that W3C is having now.
Honestly, much of the impatience with standards bodies over this just reminds me of Kent Brockman’s “democracy simply doesn’t work”.
posted by migurski at 2:12 PM on February 15, 2012 [4 favorites]
Can someone explain the downside of just writing:
posted by designbot at 2:13 PM on February 15, 2012 [1 favorite]
border-radius: 2px;-webkit-border-radius: 2px;
-moz-border-radius: 2px;
border-radius: 2px;posted by designbot at 2:13 PM on February 15, 2012 [1 favorite]
designbot: well, nothing now. A few years ago (not sure how long now) it wouldn't have worked anywhere, except maybe Opera. And while border-radius is maybe not a great example, the point (IMHO) of using a vendor-specific prefix is that where the idea or spec is unclear, different browsers may render a given property somewhat differently.
Actually, for border-radius: which corner do you start with if you want every corner to have a different radius? (TBH, I can never remember even w/out prefixes, always have to look it up.) For something that's really complicated (animations, gradients), there's probably a dozen ways that you could write the property, and when there isn't yet a spec or a consensus, you might need to use the vendor-specific versions to reconcile what different vendors think is the "right" answer.
You know what? Writing that all out actually made up my mind for me -- I haven't been able to figure out what I think about this issue until now. And my take is that as long as Webkit (et al), Mozilla, Opera, etc are all different development teams, with the possibility of having different answers to those questions, then there should be separate vendor prefixes, not -beta, not -alpha.
From the author's POV, it's incredibly annoying, and the easy answer is to make it work for the dominant player in your sites' markets*, to hell with the rest. These days there are also answers that involve frameworks, scripting and whatnot, and those make sense to me. But to say that it's too hard to even try feels like the wrong take.
* At my day job, Firefox has more twice the market share of Safari. With the addition of Chrome/Android, Webkit is significant, but not overwhelming. A year ago, it would've been ridiculous to target for Webkit, and now not so much. Which from my POV, means that belt & suspenders is the way to go, however you craft those belts and/or suspenders. Then again, IE still makes up a slim majority of visits, so there's that.
posted by epersonae at 2:33 PM on February 15, 2012
Actually, for border-radius: which corner do you start with if you want every corner to have a different radius? (TBH, I can never remember even w/out prefixes, always have to look it up.) For something that's really complicated (animations, gradients), there's probably a dozen ways that you could write the property, and when there isn't yet a spec or a consensus, you might need to use the vendor-specific versions to reconcile what different vendors think is the "right" answer.
You know what? Writing that all out actually made up my mind for me -- I haven't been able to figure out what I think about this issue until now. And my take is that as long as Webkit (et al), Mozilla, Opera, etc are all different development teams, with the possibility of having different answers to those questions, then there should be separate vendor prefixes, not -beta, not -alpha.
From the author's POV, it's incredibly annoying, and the easy answer is to make it work for the dominant player in your sites' markets*, to hell with the rest. These days there are also answers that involve frameworks, scripting and whatnot, and those make sense to me. But to say that it's too hard to even try feels like the wrong take.
* At my day job, Firefox has more twice the market share of Safari. With the addition of Chrome/Android, Webkit is significant, but not overwhelming. A year ago, it would've been ridiculous to target for Webkit, and now not so much. Which from my POV, means that belt & suspenders is the way to go, however you craft those belts and/or suspenders. Then again, IE still makes up a slim majority of visits, so there's that.
posted by epersonae at 2:33 PM on February 15, 2012
This is not a herp-derp-what-do-we-do ivory tower debate, it’s a real legitimate argument among competing businesses bristling with patent portfolios and still trying to meet someplace in the middle. If all you want to do is throw video in a browser, Macromedia had an answer for you a decade ago and Youtube took it all the way to the bank. If you want to do it in a way that’s usable by new technologies outside of cumbersome licensing deals, you get the debate that W3C is having now.
If the same thing had happened with embedded images, we would have some crappy proprietary image plugin that nobody wants handling all of the images on the web while the web standards people debated about GIF patent concerns or whether JPEG was an efficient enough lossy image compression method or whatever. Instead, someone implemented support for images and put it in a browser. Maybe 10 years ago when web video was a relatively new technology it would have made sense to argue over which format should be the recommended one but doing that today is like going without food for days because you can't decide what you want to eat.
posted by burnmp3s at 2:39 PM on February 15, 2012
If the same thing had happened with embedded images, we would have some crappy proprietary image plugin that nobody wants handling all of the images on the web while the web standards people debated about GIF patent concerns or whether JPEG was an efficient enough lossy image compression method or whatever. Instead, someone implemented support for images and put it in a browser. Maybe 10 years ago when web video was a relatively new technology it would have made sense to argue over which format should be the recommended one but doing that today is like going without food for days because you can't decide what you want to eat.
posted by burnmp3s at 2:39 PM on February 15, 2012
At my day job, Firefox has more twice the market share of Safari.
At my day job IE, as a whole, is nearly 4/5ths of the user base.
Now, if you'll excuse me, I'm going to ride my dinosaur over to the Starrocks and commiserate with Fred and Barney.
posted by dw at 2:44 PM on February 15, 2012 [3 favorites]
At my day job IE, as a whole, is nearly 4/5ths of the user base.
Now, if you'll excuse me, I'm going to ride my dinosaur over to the Starrocks and commiserate with Fred and Barney.
posted by dw at 2:44 PM on February 15, 2012 [3 favorites]
Lots of people debated GIFs in the 1990’s. It’s why we have the PNG image format.
What happened with embedded images is almost exactly what’s happening with video right now: browser makers in a hurry to ship something implemented the simplest thing that could possible work and it was generally adopted by the population at large. Meanwhile and much more slowly, standards bodies debated the choice of formats and implementation, and over time the decision to use an “IMG” tag was vindicated while emerging broad support for the patent-free and open PNG format essentially obliterated the once-ubiquitous GIF format for non-animations.
posted by migurski at 3:06 PM on February 15, 2012 [1 favorite]
What happened with embedded images is almost exactly what’s happening with video right now: browser makers in a hurry to ship something implemented the simplest thing that could possible work and it was generally adopted by the population at large. Meanwhile and much more slowly, standards bodies debated the choice of formats and implementation, and over time the decision to use an “IMG” tag was vindicated while emerging broad support for the patent-free and open PNG format essentially obliterated the once-ubiquitous GIF format for non-animations.
posted by migurski at 3:06 PM on February 15, 2012 [1 favorite]
Another perspective:
"It’s never a good thing for there to be homogeneity in the experimentation phase. The explicit goal of the prefixes system is to enable diversity of early opinion and fast coalescing around the best answer, thereby enabling the writing of a standard which is likely to need less revising and iteration. Diversity provides some value, the market tests the alternatives, and we deliver the most value we can over time through the standard version. It has always been thus, but prefixes make it less risky…assuming we don’t start stepping on everyone else’s toes.posted by weston at 8:54 PM on February 15, 2012 [1 favorite]
"...we have much bigger fish that need frying, and stat. Prefixes do work, they’re essential to delivering a future platform that can compete with native alternatives, and yes, they should be torn down at the same pace they’re erected."
The stupid thing about this whole debate is that it’s only really an issue because Mozilla is flustered about people selecting the Webkit-specific properties for their sites, and Mozilla is responding by making their browser respond to someone else’s vendor prefixes.That's ridiculous. There's nothing wrong with implementing -webkit properties. Including multiple tags with the same data just wastes bytes. Maybe add an -draft-/-beta- prefix or something for experimental/nonstandard features.
...
Daniel Glazman’s suggested approach is the right one and I think it’s being misunderstood in this thread: Mozilla’s response should be to ensure that every -webkit- property they want to support works as a -moz- property, and then target web developers with a search/replace campaign showing how easy it is to add the additional property, while at the same time working with the W3C to ensure that the prefixed properties are suitable for adoption as non-prefixed standards.
Also, I wonder why people don't use server-side CSS parsers that let you write
gradient: ... and have it translated to an appropriate tag
However, you can still (cautiously) use bleeding-edge features. Just don't depend on them, don't use vendor-specific prefixes in your raw CSS, and try to add them at runtime if possible. Use feature detection to selectively load polyfills and add vendor-specific prefixes to the CSS where necesary on a browser-by-browser basis so that new features are supported, and vendor-specific prefixes are added. If the bleeding-edge feature you're using has been standardized, and is supported (as a standard) in the user's browser, the feature detection script does nothing, and everyone is happy.I've mentioned it before, but why not just load the entire layout engine? I mean google has Chrome Frame which lets you use webkit in IE6. It's a separate download and works as a plugin. But if a browser supports canvas, you could in theory do all the layout in javascript. Store it a central location, like jquery is today and it will sit in people's caches. And you'll be able to write your own extensions for whatever you want. Dynamic shadows? Blur? 3d transformations? multiplication and addition of images rather then just alpha blending? Hexagonal boxes instead of square ones? Go nuts!
Ideally, you'd fetch these scripts from a reliable CDN so that they're continuously updated/maintained by developer, and also cached from site to site.
posted by delmoi at 2:23 PM on February 16, 2012
But if a browser supports canvas, you could in theory do all the layout in javascript.
That sounds good? Just reading that sentence exhausts me.
posted by Artw at 2:58 PM on February 16, 2012
That sounds good? Just reading that sentence exhausts me.
posted by Artw at 2:58 PM on February 16, 2012
That's ridiculous. There's nothing wrong with implementing -webkit properties. Including multiple tags with the same data just wastes bytes. Maybe add an -draft-/-beta- prefix or something for experimental/nonstandard features.He’s plainly biased, but I agree with Alex Russell’s opinion on why Mozilla should avoid implementing the -webkit properties:
Now, what about the related argument that Mozilla & Co. are only going to be doing this for properties which are “stable” (nevermind their actual standardization status)? The argument says that because something hasn’t changed in another vendor’s prefixed version in a while, it must be safe to squat on. Not only is this (again) incredibly short-sighted, it says that instead of forcing a standard over the line and clobbering both developers and other vendors with the dreaded label of “proprietary” (the usual and effective tactic in this situation), they’re instead willing to claim ownership and therefore blame for the spread of this soon-to-be-proprietary stuff, all the while punting on having an independent opinion about how the features should be structured and giving up on the standards process…and all for what?In a world where it costs more than two megabytes of data transfer to view a single tweet on Twitter.com, the wasted bytes of extra selectors seem immaterial. More to the point, it only makes sense for Mozilla to borrow prefixes from Webkit if Mozilla agrees that Webkit has done “the right-hand side” correctly (e.g the actual syntax for describing a gradient), and once you agree to that you’re two steps away from getting the dumb thing through committee and into a standard.
…
If the reasoning behind prefixes is to set up and tear down large-scale experiments, iterate, and collect feedback then Lea’s -prefix-free approach and PPK’s -alpha-*/-beta-* proposals are equally counter-productive and should be avoided at all costs. Making prefixes less painful to use reduces the natural incentives for migrating to a standard while blindly assuming the same right-hand for a future standard version as we have for some prefixed versions is plainly idiotic. What were they thinking?
Also, why not just load the entire layout engine? Because then you’d be implementing Flash, and we all know how awesome that was.
posted by migurski at 3:22 PM on February 16, 2012
If the reasoning behind prefixes is to set up and tear down large-scale experiments, iterate, and collect feedback then Lea’s -prefix-free approach and PPK’sLook, obviously developers can make their pages work in mozilla and webkit both, simply by adding -moz- versions of the tags. but they're not going to If they were going to develop the right way, they would have done it. The problem with the idea that you can just "educate developers" is that it just won't work
It's like the years and years and years people spent trying to get everyone to write well-formed/valid HTML. Finally with HTML5 they realized it was a losing battle and they just said "Fuck-it, let's just standardize the way we deal with fucked up code!"
That sounds good? Just reading that sentence exhausts me.It was less exhausting then reading all of this - If you added all those 'polyfills' to a page you'd probably just be better off just using pure canvas.
Also, why not just load the entire layout engine? Because then you’d be implementing Flash, and we all know how awesome that was.Yes, except without the compatibility problems, lack of platform support, privacy issues, or security vulnerabilities.
And anyway, you can already do everything in canvas that you used to be able to do in flash. This would just mean using standard layout, and being able to extend it.
Anyway I think it's where we're headed in future and there's nothing to can do about it. :P
posted by delmoi at 4:03 PM on February 16, 2012
Look, obviously developers can make their pages work in mozilla and webkit both, simply by adding -moz- versions of the tags. but they're not going to If they were going to develop the right way, they would have done it. The problem with the idea that you can just "educate developers" is that it just won't work
I don't know about this. I'm not sure that developers don't really *like* themselves a good religious campaign now and again. And we're all working in the recent wake of a successful campaign to get web developers to abandon a well-known and reasonably effective means of laying out web pages (<table>) in favor of adopting a somewhat more esoteric if also reasonably effective and arguably more flexible means (CSS positioning). Heck, *adoption* might be putting it mildly -- some took it on as a religion. And that's with half of the trotted out justifications being overblown or false.
Getting people to copy and paste a line and replace -webkit with -o|-ms|-moz| should be a little easier than getting them to recode entire layouts.
Like I said above, though, I don't see anything wrong with aliasing -draft-property and/or property to -vendor-property with the understanding that the final behavior of property could change, and I think that move combined with education would probably be more effective than either alone.
posted by weston at 5:34 PM on February 16, 2012
I don't know about this. I'm not sure that developers don't really *like* themselves a good religious campaign now and again. And we're all working in the recent wake of a successful campaign to get web developers to abandon a well-known and reasonably effective means of laying out web pages (<table>) in favor of adopting a somewhat more esoteric if also reasonably effective and arguably more flexible means (CSS positioning). Heck, *adoption* might be putting it mildly -- some took it on as a religion. And that's with half of the trotted out justifications being overblown or false.
Getting people to copy and paste a line and replace -webkit with -o|-ms|-moz| should be a little easier than getting them to recode entire layouts.
Like I said above, though, I don't see anything wrong with aliasing -draft-property and/or property to -vendor-property with the understanding that the final behavior of property could change, and I think that move combined with education would probably be more effective than either alone.
posted by weston at 5:34 PM on February 16, 2012
It was less exhausting then reading all of this - If you added all those 'polyfills' to a page you'd probably just be better off just using pure canvas.
Except CANVAS is still missing significant accessibility features. Building a site purely in CANVAS is akin to building a site in early Flash.
posted by dw at 8:58 PM on February 16, 2012
Except CANVAS is still missing significant accessibility features. Building a site purely in CANVAS is akin to building a site in early Flash.
posted by dw at 8:58 PM on February 16, 2012
I think what delmoi is suggesting skirts the accessibility issue entirely -- you grab the same markup over HTTP that you do right now, but you're adding a JavaScript rendering engine to the page that would read the markup source itself and then replace the normally-rendered body with a big old canvas element on which it would do all the rendering itself, rather than leaving things to the browser. In effect, you have a JavaScript web browser running within your web browser. The source markup would be precisely as accessible as it was beforehand (interactive accessibility features would of course depend on the quality of the browser).
It's a little bit intriguing and I've seen some things which have taken related approaches -- Bespin/Skywriter, for example.
But I think there's a severe underestimation of the work involved. To say "if you added all those 'polyfills' to a page you'd probably just be better off just using pure canvas" is giving short shrift to all the work a somewhat-behind-the-times browser does even without the polyfills -- the polyfills, multitudinous and sizeable as they may seem, are mostly just implementing recent features and frosting, not doing the bulk of the work of a rendering/layout engine. So anything that's filling in here isn't going to be *smaller* than a payload of polyfills, it's going to be bigger.
I think it's also generally true that the best web developers don't just dump in "all" the polyfills, they target a select few for features they think are important and let the rest fall back. Chucking an entire rendering engine at the client doesn't exactly allow modular feature selection.
Then again, maybe somebody could run Webkit through Emscripten and do just that.
Of course, the other problem is that generally, the browsers most in need of that much help also don't have a built-in canvas implementation. So, you'll need a Canvas polyfill...
posted by weston at 12:16 PM on February 17, 2012
It's a little bit intriguing and I've seen some things which have taken related approaches -- Bespin/Skywriter, for example.
But I think there's a severe underestimation of the work involved. To say "if you added all those 'polyfills' to a page you'd probably just be better off just using pure canvas" is giving short shrift to all the work a somewhat-behind-the-times browser does even without the polyfills -- the polyfills, multitudinous and sizeable as they may seem, are mostly just implementing recent features and frosting, not doing the bulk of the work of a rendering/layout engine. So anything that's filling in here isn't going to be *smaller* than a payload of polyfills, it's going to be bigger.
I think it's also generally true that the best web developers don't just dump in "all" the polyfills, they target a select few for features they think are important and let the rest fall back. Chucking an entire rendering engine at the client doesn't exactly allow modular feature selection.
Then again, maybe somebody could run Webkit through Emscripten and do just that.
Of course, the other problem is that generally, the browsers most in need of that much help also don't have a built-in canvas implementation. So, you'll need a Canvas polyfill...
posted by weston at 12:16 PM on February 17, 2012
« Older What's Your Ludic Goal? | Hillary can be President after all! Newer »
This thread has been archived and is closed to new comments
I guess this shouldn't be unexpected, but it certainly is disappointing.
posted by mcstayinskool at 11:06 AM on February 15, 2012 [2 favorites]