Firefox 46 supports some -webkit prefixed CSS properties | Hacker News Reader

Firefox 46 supports some -webkit prefixed CSS properties

developer.mozilla.org

71 pointssimon0441 comments

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.

> It was a joke of a web-framework.

Hey, at least it wasn't ASP classic

I'm pretty sure he meant ASP Classic. In any case ASP.NET a.k.a. ASP.NET Core is one of the best looking frameworks right now.

Yep, it is open source, cross-platform, with a fantastic MVC framework and an elegant language (C#).

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.

ASP.NET Core 1 (formerly ASP.NET 5.0) development works great in Visual Studio Code https://code.visualstudio.com/, which is FOSS (MIT license) https://github.com/Microsoft/vscode/ and works on Linux and OS X as well as Windows.

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.

You should check out Project Rider[0].

[0] https://blog.jetbrains.com/dotnet/2016/01/13/project-rider-a...

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.

This is the answer. Asp.net 1.1 was mostly designed for "drag'n'drop" pixel aligned "form" layouts. Optimised for VB6 devs. Definitely not webby.

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.

> 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.

FWIW, these aren't actually enabled in 46 unless you flip the `layout.css.prefixes.webkit` pref to true.

(We hope to flip that to true by default soon: https://bugzilla.mozilla.org/show_bug.cgi?id=1259345)

Very interesting considering WebKit is moving away from prefixes: https://webkit.org/blog/6131/updating-our-prefixing-policy/

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.

And one of the reasons mentioned in there, incidentally, is browser vendors feeling compelled to become compatible with each other's prefixes.

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].

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

> 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}.

[0] http://www.sitepoint.com/opera-css3-webkit-prefix/

[1] https://msdn.microsoft.com/en-us/library/mt270097%28v=vs.85%...

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.

[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

Obviously the solution is vendor-specific suffixes! /joke attempt

Abso-bloomin'-lutely not. :) Vendor-specific infixes...

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.

(Disclaimer: I work on Firefox.)

this is bad.

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.

...what.

I don't think you understand how prefixes are used in the wild. Vendor prefixes re-inforce monoculture, they don't prevent it.

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.

> well, Google (the irony) sued and won. Microsoft had to remove IE from Windows, and browser vendors agreed to not force standards themselves.

What on earth are you talking about? This is not a thing that ever happened.

are you too young to remember the browser wars and how Google sued ms for giving internet explorer for free with msn as the honepage?

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, of course, Safari sends a Mozilla user-agent...

and everyone send in a gecko string...

Disappointing, but you can see the corner they're wedged into here. Maintain purity or lose users due to sites not working "because of Firefox".

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.

This is why we can't have nice things. https://webkit.org/blog/6131/updating-our-prefixing-policy/

This specification, created by Mozilla, is also relevant: https://compat.spec.whatwg.org/

FWIW, Firefox Dev Ed / Aurora has had this for a while and has been on 47 since 08 March.

https://www.mozilla.org/en-US/firefox/47.0a2/releasenotes/

Google is moving as aggressively as Microsoft was with IE, and Mozilla bent over, again.

for the kids that don't remember, go read about why all the worst parts of JavaScript are the way they are...

The problems with a WebKit monoculture on mobile are as much Apple's fault as they are Google's. Neither did anything to stop it until far too late.

New changes welcome.

This is making me sad...

> 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)

Well done Mozilla.

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.

[0] https://compat.spec.whatwg.org/#introduction

[1] following the lead of Opera and Microsoft in doing so

Reply on news.ycombinator.com