This is far from unprecedented, the genesis of Firefox basically involved implementing a ton of IE's behavior for compatibility with the web as it existed.
It's the kind of mess that got Firefox to have to implement other browsers' prefixes that led to Blink, Gecko and WebKit ceasing to use them for new features. Unfortunately, that doesn't clean up the existing problems, but it should prevent creating more.
It seems they agree the existing state of affairs isn't acceptable, but don't agree about how to proceed.
Consider Mozilla's perspective... they're trying to refocus on Firefox[1] and immediately after they find a suitable place for Thunderbird[2] they release support for WebKit prefixes while Apple announces dropping the same prefixes. Not only does this mean Mozilla arguably wasted time, it also means they'll have this prefix code as an artifact for some time while it becomes increasingly irrelevant. At the same time, it makes Firefox seem antiquated while the floor falls out from under its user base[3].
> It seems they agree the existing state of affairs isn't acceptable, but don't agree about how to proceed.
They completely agree how to proceed, Firefox and Chrome both moved to using feature flags instead of vendor prefixes a while back, but there are so many -webkit- prefixed "advanced" properties in the wild, and developers only testing their site in Chrome (which hasn't removed the old prefixed properties for compatibility reasons) that Mozilla felt compelled to add support for these. Incidentally, they're following Opera[0] and Microsoft[1] in doing so.
> while Apple announces dropping the same prefixes
Apple didn't announce dropping support for existing prefixed properties (at best they noted that they may remove some over time depending on compatibility needs), only that new features will be gated instead of prefixed going forwards.
> it also means they'll have this prefix code as an artifact for some time while it becomes increasingly irrelevant.
Prefixed properties are just specific names, the vendor prefix is incidental, Mozilla implemented and enabled a bunch of properties named -webkit-{something} instead of {something}.
As I understand it, WebKit's feature flags will not include the webkit prefix:
"WebKit’s new policy is to implement experimental features unprefixed"
But Mozilla still plans for experimental features to be prefixed:
"Mozilla supports a number of extensions to CSS that are prefixed with -moz-.
Some of these properties have been included in draft CSS specification for inclusion in the final recommendation, but are still experimental... Once standardized, and the support for the un-prefixed variant added, the prefixed properties are dropped."
I'm not sure what you're trying to say. The webkit quote indicates that new experimental features will be unprefixed and behind flags, which is already the policy at Mozilla. For instance as of Firefox 46 (release channel) "grid" is unprefixed (there is no -moz-grid[0]) but behind a flag (layout.css.grid.enabled).
> But Mozilla still plans for experimental features to be prefixed:
The quote doesn't support your interpretation, it only indicates that there are -moz-prefixed experimental properties, just as there are -webkit-prefixed experimental properties.
From that article: "We expect to significantly reduce the number of prefixed properties supported over time but Web compatibility will require us to keep around prefixed versions of some features."
The features WebKit needs to keep around to continue to work with many websites are presumably about the same as those Firefox felt it had to implement to work with many websites.
remember when Microsoft was the first to ship a browser shipped by default and dictated the standards by releasing it as they saw fit in that monopolistic browser? (for the kids of today, devs from that day loved ie just like you love chrome today. IE invented the developer panel and ajax request, both things you live by today)
well, Google (the irony) sued and won. Microsoft had to remove IE from Windows, and browser vendors agreed to not force standards themselves. that is the only reason we have prefixes. it send the message "we think it's cool, but wait for everyone to agree on the best way to implement this".
without prefixes, Google, having the browser monopoly (since Android is the new windows) can dictate the direction as it see fits. just like Microsoft when they sued them.
The modern "no prefixes" approach is to hide the new features behind a runtime flag or in a pre-release beta channel. Web developers can test the feature but not use it in production websites until browser vendors standardize it.
> Firefox 46 supports some -webkit prefixed CSS properties
>When implementing new features for the Web, it’s important for us to be able to get them into the hands of developers early, so they can give new things a try
> WebKit is moving away from prefixes (webkit.org)
Mozilla is adding support for existing wide-spread -webkit-prefixed properties for compatibility reasons[0][1].
Existing properties which Webkit isn't dropping, they're dropping prefixes for new experimental features, a move Firefox (and Chrome) made more than 3 years ago.
Which you'd have know had you read the first comment of the sister story instead of going no further than the story title.
I don't blame them. I remember reading how IE on Windows 10 sends a Safari user agent because so many sites use user agent sniffing rather than capability detection for things like touch events.
So, all disappointing, but we (as an industry) have no-one but ourselves to blame for it. Firefox and MS are just putting the user first.
And I still see web developers who reject the idea that we have troublesome webkit monoculture. And when you ask them what non-webkit browsers they are testing on, they're response while not literally "What do you mean testing?", effectively conveys the same: "Just use latest Chrome (Works on my machine)".
When Microsoft created its initial version of ASP.Net, it was mainly designed to allow Windows VB6 point-and-click programmers to create web applications without understanding how the web worked. It was a joke of a web-framework.
The irony is that right now, I can tell the current crop of "ninja" web-developers (who rightfully rejected ASP.Net and its ilk) are starting more and more to look like this generation's VB6 programmers: Unambitious. Untalented. Unprincipled. Web-standards? Whatever works, and this works on my machine.
It's quite frightening. I thought we were past this shit.
I think he meant the original ASP.NET -- webforms. That version basically was windows forms but on the web in a bizarre way. Also it's poopy doodoo and I don't recommend using it (webforms I mean, not the modern ASP.NET)
I wonder if that's the case (what was meant). When I first worked with ASP.NET 1.1, getting it to work (feature-level) with Opera often required forgoing most of the "managed" control properties and using CSS/JS directly. The backend .NET code was much more of a joy to work with than Classic ASP, but the managed ASP.NET frontend portion, not as much.
> The irony is that right now, I can tell the current crop of "ninja" web-developers (who rightfully rejected ASP.Net and its ilk) are starting more and more to look like this generation's VB6 programmers: Unambitious. Untalented. Unprincipled. Web-standards? Whatever works, and this works on my machine.
Anything which is commoditized will see a dip in quality. Including programmers for popular languages/frameworks/etc.
There were a lot of very talented VB6, ASP Classic, and similar programmers. There was also a lot of corporate programmers who didn't care and just did what needed to be done.
I think the same is true now. Ultimately you get what you pay for, if companies want the lowest bidder and want it down quickly rather than correctly then they only have themselves to blame.
I will say that I do hope frameworks save us to a certain degree. If they're targeting JQuery, Bootstrap, or similar it will give them Edge/Firefox for "free" even if WebKit is their primary target.
That's why it's particularly frustrating that Firefox isn't a really good, fast, spec-compliant browser. Mozilla holds that flag, but little things like HTML5 input types are not implemented in Firefox yet.
Chrome isn't perfect to be sure, but Firefox really seems to be lagging. Hopefully now that they've dropped Firefox OS and Thunderbird they can focus solely on Firefox, because we really need Firefox to exist.
41 comments
[ 2.9 ms ] story [ 95.3 ms ] threadConsider Mozilla's perspective... they're trying to refocus on Firefox[1] and immediately after they find a suitable place for Thunderbird[2] they release support for WebKit prefixes while Apple announces dropping the same prefixes. Not only does this mean Mozilla arguably wasted time, it also means they'll have this prefix code as an artifact for some time while it becomes increasingly irrelevant. At the same time, it makes Firefox seem antiquated while the floor falls out from under its user base[3].
1. http://news.softpedia.com/news/mozilla-wants-to-ditch-thunde... 2. http://news.softpedia.com/news/two-foundations-are-willing-t... 3. http://www.w3schools.com/browsers/browsers_stats.asp
They completely agree how to proceed, Firefox and Chrome both moved to using feature flags instead of vendor prefixes a while back, but there are so many -webkit- prefixed "advanced" properties in the wild, and developers only testing their site in Chrome (which hasn't removed the old prefixed properties for compatibility reasons) that Mozilla felt compelled to add support for these. Incidentally, they're following Opera[0] and Microsoft[1] in doing so.
> while Apple announces dropping the same prefixes
Apple didn't announce dropping support for existing prefixed properties (at best they noted that they may remove some over time depending on compatibility needs), only that new features will be gated instead of prefixed going forwards.
> it also means they'll have this prefix code as an artifact for some time while it becomes increasingly irrelevant.
Prefixed properties are just specific names, the vendor prefix is incidental, Mozilla implemented and enabled a bunch of properties named -webkit-{something} instead of {something}.
[0] http://www.sitepoint.com/opera-css3-webkit-prefix/
[1] https://msdn.microsoft.com/en-us/library/mt270097%28v=vs.85%...
"WebKit’s new policy is to implement experimental features unprefixed"
But Mozilla still plans for experimental features to be prefixed:
"Mozilla supports a number of extensions to CSS that are prefixed with -moz-.
Some of these properties have been included in draft CSS specification for inclusion in the final recommendation, but are still experimental... Once standardized, and the support for the un-prefixed variant added, the prefixed properties are dropped."
> But Mozilla still plans for experimental features to be prefixed:
The quote doesn't support your interpretation, it only indicates that there are -moz-prefixed experimental properties, just as there are -webkit-prefixed experimental properties.
[0] well there is a display: -moz-grid value for display but it's a historical XUL property unrelated to the CSS Grid Layout module: https://bugzilla.mozilla.org/show_bug.cgi?id=616605#c10
The features WebKit needs to keep around to continue to work with many websites are presumably about the same as those Firefox felt it had to implement to work with many websites.
(Disclaimer: I work on Firefox.)
remember when Microsoft was the first to ship a browser shipped by default and dictated the standards by releasing it as they saw fit in that monopolistic browser? (for the kids of today, devs from that day loved ie just like you love chrome today. IE invented the developer panel and ajax request, both things you live by today)
well, Google (the irony) sued and won. Microsoft had to remove IE from Windows, and browser vendors agreed to not force standards themselves. that is the only reason we have prefixes. it send the message "we think it's cool, but wait for everyone to agree on the best way to implement this".
without prefixes, Google, having the browser monopoly (since Android is the new windows) can dictate the direction as it see fits. just like Microsoft when they sued them.
I don't think you understand how prefixes are used in the wild. Vendor prefixes re-inforce monoculture, they don't prevent it.
What on earth are you talking about? This is not a thing that ever happened.
>When implementing new features for the Web, it’s important for us to be able to get them into the hands of developers early, so they can give new things a try
> WebKit is moving away from prefixes (webkit.org)
Well done Mozilla.
Existing properties which Webkit isn't dropping, they're dropping prefixes for new experimental features, a move Firefox (and Chrome) made more than 3 years ago.
Which you'd have know had you read the first comment of the sister story instead of going no further than the story title.
[0] https://compat.spec.whatwg.org/#introduction
[1] following the lead of Opera and Microsoft in doing so
So, all disappointing, but we (as an industry) have no-one but ourselves to blame for it. Firefox and MS are just putting the user first.
When Microsoft created its initial version of ASP.Net, it was mainly designed to allow Windows VB6 point-and-click programmers to create web applications without understanding how the web worked. It was a joke of a web-framework.
The irony is that right now, I can tell the current crop of "ninja" web-developers (who rightfully rejected ASP.Net and its ilk) are starting more and more to look like this generation's VB6 programmers: Unambitious. Untalented. Unprincipled. Web-standards? Whatever works, and this works on my machine.
It's quite frightening. I thought we were past this shit.
Hey, at least it wasn't ASP classic
Visual Studio is of course proprietary and windows-only, but it isn't necessary to use. Although you'd be a fool not to use it.
A lot of people don't realize that Visual Studio Code is, in fact, it's own product and not a version of full Visual Studio.
[0] https://blog.jetbrains.com/dotnet/2016/01/13/project-rider-a...
It wasn't until Microsoft started with asp.net MVC that asp.net finally started going somewhere properly.
And that was ironically much closer to classic asp and "real" web programming than the initial versions of asp.net ever was.
Anything which is commoditized will see a dip in quality. Including programmers for popular languages/frameworks/etc.
There were a lot of very talented VB6, ASP Classic, and similar programmers. There was also a lot of corporate programmers who didn't care and just did what needed to be done.
I think the same is true now. Ultimately you get what you pay for, if companies want the lowest bidder and want it down quickly rather than correctly then they only have themselves to blame.
I will say that I do hope frameworks save us to a certain degree. If they're targeting JQuery, Bootstrap, or similar it will give them Edge/Firefox for "free" even if WebKit is their primary target.
Chrome isn't perfect to be sure, but Firefox really seems to be lagging. Hopefully now that they've dropped Firefox OS and Thunderbird they can focus solely on Firefox, because we really need Firefox to exist.
https://www.mozilla.org/en-US/firefox/47.0a2/releasenotes/
(We hope to flip that to true by default soon: https://bugzilla.mozilla.org/show_bug.cgi?id=1259345)
for the kids that don't remember, go read about why all the worst parts of JavaScript are the way they are...