« Lame Apple
- 18h17 »
By glazou on Wednesday 25 April 2012, 17:48 - CSS and style
Remember what I said a while ago here? I was not lying, here we are.
But, I mean, you *do* know what the remedy for this has been all along, right? The one that is simultaneously guaranteed to have resulted in in web developers' compliance (if only because they'd have no choice) but which vendors aren't interested in playing along with? I'm not talking about the unrealistic, ideal-driven demand that web devs be principled on the issue and do the pure and right thing. I'm talking about the approach that has the dirty, hacky signs that real pragmatism has come into play:
Prefixed features are only enabled in pre-release builds and in release builds where the engine is being used outside a browser context.
Webkit on iOS/Android still needs to support those things because it drives several platform components? No problem, they're still there for that reason. But the renderer used by Mobile Safari and the other Webkit-derived browsers has them turned off.
You're a web dev, and you want to show off a tech demo for something that just gained support in the development build for your browser? No problem, the development versions are there for that reason. But the dot-oh releases that casual users are downloading from http://vendor.tld/browser, that are being being bundled with multimedia runtime plugins, and that are being updated by release-channel background update services have them turned off.
Worried that web devs will be oblivious to the fact that their users on the release channels aren't going to be seeing the things they themselves are seeing on the development builds? No problem, both the built-in and third party inspectors display conspicuous warnings for their benefit: "This better not be production, because this stuff's not gonna work."
So now we get a glimpse of the real problem, which is that *ostensibly* these things are only for experimentation. But if this were the case, there would be no pushback against setting the above approach into motion. Not from the vendors who are on the more favorable side of the Webkit monoculture and who profess their sympathies, and *certainly* not from the ones who are on the desperate side of it. But it hasn't happened, and it's probably not going to. Which leads us to explicitly call out, as I called it, the real problem:
The conversation as it exists now, doesn't track all the factors which are shaping the decisions being made; there are things at play here, that the conversation doesn't touch. So long as this continues to happen, it prevents us from having one which has the potential to lead to a real solution. And it might even not. But at least we'd be having an honest conversation.
1. To be clear, they *should* be, but it isn't realistic to expect it. http://www.marco.org/2012/02/25/rig...
The idea with CSS prefixes has failed and should be removed. No more need to write crappy code again and problem solved.
Everybody is just wasting time with alternative solutions such as "developers should not" talk.
LOL, Opera. So one irrelevant browser makes a desperate play to get some sort of market share. Really, enough is enough. The only people who care about what Opera does are industry people. It's irrelevant. Stop talking about it and let it die.
There are a few question to this, the first thing... how quick will prefixed elements become a part of the CSS standard? It would help when solving this problem.
Two, if Opera moves in this direction... what would be the meaning of the standards process. Would it even be nessicary since one engine would basically call the shots (and honestly, that could be ANY engine at this point... alas with Webkit on two of the more popular platforms on the web, Market effects have decided for all of us)?
Three... This is twice now that something like this has happened on the web in it's histroy. And honestly, it makes one question what would happen if there is a thrid instants of this... What could be the things in place to prevent that? The need for mono-culture standarizing...
Co-chairman of the W3C CSS Working Group, entrepreneur, software engineer, geek, father of two, polyglot, unashamed French, duck lover. Nah.
Powered by Dotclear