Plans are afoot for Firefox to work with pre-complete web standards as implemented in rivals’ browsers. Mozilla developers have revealed a plan to implement support for a subset of non-standard CSS prefixes used in WebKit, –webkit. Changes are planned for either Firefox 46 or 47, set to be released around April and May. …
Thanks for the informed comment and reasoned argument.
This appears to be a very sensible and pragmatic move for firefox. Presumably for a bunch of already agreed and finalised standards all that would be required is for firefox to support the -webkit and non-webkit prefixed versions of the CSS, presumably bringing it into line with webkit browsers which I'm guessing don't remove support for -webkit prefix as soon as the standard is finalised.
Short of getting every website author to go and clean up all their sites to ensure only standards compliant tags are used, and to ensure that they keep these up-to-date while also ensuring backward compatibility of their sites on older browsers, this appears to be the best way of ensuring Firefox remains relevant as an alternative rendering engine. This is important to ensure that webkit-based browsers don't completely dominate and thus begin to ignore standards altogether (as happened with IE back in the day)
This post has been deleted by its author
The problem with IE6 sites wasn't that they only worked on Windows, it was that they only worked on IE6. Your critical difference actually makes this worse, there's even less reason for the move to standards.
It would be far better if they added such support *conditionally* on the browsing machine's DNS suffix *not* matching the website under view (at least to some level in the hierarchy).
Real end-users get the support they need for broken sites. The authors of those sites get a slap in the face. Everyone's happy.
So much for standards.
Not that I'm expecting much common sense from the overall web / web-app / html5 / browser community. There's too much self serving self interest for any one of the large players to actually want to make it possible for code or web pages to be truly write once display/run anywhere.
Oh what the hell. If it reduces the pain of web development in the web's dying years, go for it.
Sure those are still missing? developer.mozilla.org lists String.trim() as being supported by Chrome, Firefox since version 3.5, IE since 9, Opera since 10.5, Safari since 5. The String.startsWith() needs a bit newer browser, but is supported by Chrome 41, IE 12, Opera 41, Safari 9. You cannot expect Microsoft/Apple/Google to do anything about their older browser versions.
And if the customer insists that you support feature X on an iPhone and on Chrome and the only way to get paid is to use a webkit prefix? Even after you've explained how much of a bad idea that is? You'd close your business rather than implement something browser specific?
And if the customer insists that you support feature X on an iPhone and on Chrome and the only way to get paid is to use a webkit prefix?
Care to name such a "feature"?
I've looked at the list on the WHATWG site, and I don't think any of it is compelling. Hell, I don't think any of it is even interesting. It's just a bunch more stupid shine.
I think it'd be better if we just started hitting WebKit developers with sticks until they cut this crap out.
As Peter-Paul Koch pointed out a while back: vendor prefixes are a solution looking for a problem. Working with them without some magic CSS automation which knew when to use which prefixes, added considerably to the overhead for the developer with little obvious benefit: testing them is also a real pain.
The idea behind prefixes was sound enough: allow development in practice rather than in committee but the implementation sucked. A simple switch in the browser "support experimental features" would have sufficed. This would have encouraged gradual enhancement and prevented developers targeting experimental features. Fortunately, Google and Opera decided to stop creating new prefixes for Blink in 2013 and this approach is gradually being adopted by the other browser makers. Except Apple.
Dev/design shops don't have the resources to do everything properly. Sites need to be built in a timely fashion, and updated to meet rapidly shifting requirements from all sides... which requires developing primarily in one browser (latest Firefox or Chrome), relying on a lot of 3rd-party code, and then debugging other browsers as an afterthought. There's a ton of outdated, preliminary, erroneous, and obfuscated documentation to sift through as well. And experienced devs and designers tend to burn out, so even big-budget projects are understaffed. And that, in a nutshell, is why we're in this mess.
Dev/design shops don't have the resources to do everything properly. Sites need to be built in a timely fashion, and updated to meet rapidly shifting requirements from all sides... which requires developing primarily in one browser (latest Firefox or Chrome), relying on a lot of 3rd-party code, and then debugging other browsers as an afterthought.
So what you're saying is that web developers are the new VBA record macro -> edit monkeys? There's not doing shit properly because you don't have time and then there's just writing shit. Web development is starting to seem very much like the latter.
Biting the hand that feeds IT © 1998–2022