Firefox Will Support Non-Standard CSS For WebKit Compatibility (theregister.co.uk)

RoccamOccam writes: Mozilla developers have discussed a plan to implement support for a subset of non-standard CSS prefixes used in WebKit. Mozilla developer Daniel Holbert says: "A good chunk of the web today (and particularly the mobile web) effectively relies on -webkit prefixed CSS properties & features. We wish we lived in a world where web content always included standards-based fallback (or at least multiple-vendor-prefixed fallback), but alas, we do not live in that world. To be successful at rendering the web as it exists, we need to add support for a list of frequently-used -webkit prefixed CSS properties & features."

Comments

Safari really is the new IE

[Anonymous Coward]

So basically, Edge and Firefox have to adopt their shitty, broken, prefixed CSS, because web developers were too lazy to do things right... just like how Mozilla and others have had to adopt IE6-isms, because developers were too lazy in the same way. Great. Shows just how professional my peers are that they refuse to develop to proper standards, and worse, developed sites without proper (and usually trivial) fallbacks... all for mere eye candy.

The list of prefixed properties

[Anubis IV]

Here's a list of the "-webkit"-prefixed properties.

https://compat.spec.whatwg.org...

At least at an initial glance, it seems to me that the criticisms about WebKit being "the new IE" are generally misplaced, since most of the listed properties are aliases for the standard versions of those properties. I.e. WebKit was the first rendering engine to support those properties, but it did so while the web standard was being finalized, so it prefixed those properties, as it is supposed to. Lazy developers implemented those properties using the prefixed property, since that's all that was available at the time, but didn't go back to fix the code afterwards when the standard was finalized.

Long story short, WebKit did things exactly as they were supposed to. They implemented a proposed standard, prefixed it as they were supposed to, and then implemented the standard version later while maintaining support for the prefixed version. Really, the only ones who aren't following best practices are the developers too lazy to update their code to work with the current standards, but if we're going to blame WebKit for being too quick to support proposals, then we may as well blame the other rendering engines for being so slow that the lazy devs couldn't use their prefixed versions. Two sides of the same coin. It's no surprise that one side blames the other.

Re:The list of prefixed properties

[Anonymous Coward]

Where it goes wrong is when other implementations implement the prefixed versions. That makes things worse than any delay in standardizing those features does.

Now there's the standard features, the Firefox-only features, the prefixed features Firefox implements, and the prefixed features Firefox doesn't implement. And we're back to the same hell we were in not long ago and seemed to be climbing out of.

Initiatives like this will not speed up standardization and the adoption of the standards, they will slow it down.

Re:The list of prefixed properties

[Junior J. Junior III]

Long story short, WebKit did things exactly as they were supposed to. They implemented a proposed standard, prefixed it as they were supposed to, and then implemented the standard version later while maintaining support for the prefixed version. Really, the only ones who aren't following best practices are the developers too lazy to update their code to work with the current standards, but if we're going to blame WebKit for being too quick to support proposals, then we may as well blame the other rendering engines for being so slow that the lazy devs couldn't use their prefixed versions. Two sides of the same coin. It's no surprise that one side blames the other.

I think browser developers could all have gone a little bit further and not enabled their proprietary CSS prefixes in production releases by default. Maybe push those into a "developers only" mode, or an extension, but keep it out of production.

The prefixed CSS rules were supposed to be for not-yet finalized pre-standards versions of stuff the W3C hadn't yet finalized, to give web developers a chance to play with them, test them, and provide feedback so that when W3C finalized their recommendation, they were well tested in the real world and good.

By making them available to everyone early, it incentivized web developers who wanted their websites to look "cutting edge" to make use of the unofficial properties before they were ready. Also, the slowness with which W3C has historically acted to finalize their recommendations exacerbates this incentive. If a web developer waits for the W3C to finalize and only uses W3C recommendations, they're left hoplelessly behind the state of the art.

From that point, it was only a matter of time before a dominant browser emerged with its proprietary prefixes became de facto standards adopted by web developers before W3C was ready to finalize their own version of them. What else could they do?

So, blame W3C for not being faster, but mainly blame browser developers for tacitly allowing and encouraging developers to make use of the experimental CSS properties ahead of itme for production sites.

Re:The list of prefixed properties

[jrumney]

Part of the "standard web" push has always been: Broken sites will sometimes be broken, and it is up to developers, not browser vendors, to fix them.

This comment was brought to you by Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36 Edge/12.10136

. Business as usual.

Re:No, we don't.

[amicusNYCL]

when web sites see their numbers start to plummet cause no one can view their site properly, maybe they'll fix it with standards compliant code.

Except that's not what happens. Websites don't see their numbers plummet, browsers see their market share plummet when people notice the site works in one browser and not in another browser. Guess which of those 2 groups Firefox is finding themselves inside. They want to be in the other group, and they don't want to wait for website developers to get their shit together or else Firefox is going to go the same way as Netscape.

If Webkit doesn't want to comply

Webkit is following the standard just fine. The drafts clearly said that browser vendors should implement experimental properties with their own prefixes prior to things being finalized. Every major vendor has their own prefix that was used during that time. Those prefixes are no longer needed, but web developers still launch sites that have the -webkit prefix only, without support for any other browser. So, only Webkit browsers use that CSS, and other browsers look like shit because the web developers didn't bother to put the standard properties, only the prefixed properties. The problem is not browsers, it is lazy and/or incompetent website developers (again).

Re:No, we don't.

[rudy_wayne]

Those prefixes are no longer needed, but web developers still launch sites that have the -webkit prefix only, without support for any other browser. So, only Webkit browsers use that CSS, and other browsers look like shit because the web developers didn't bother to put the standard properties, only the prefixed properties. The problem is not browsers, it is lazy and/or incompetent website developers (again).

This is true, BUT, when people encounter a page that doesn't display properly on one browser, but works fine on another, they automatically blame the browser, not the lazy, shitty developers.

There is a simple fix -- name and shame. If a non-webkit browser encounters a page with only a -webkit prefix, then the browser should display a message which says something along the line of "This page contains code specifically designed for Safari, Chrome or Opera and may not display properly if you are using a different browser".

It's not a perfect solution, but at least it informs the user that the problem is with the lazy, shitty developers and not the browser. Time to grow some balls -- name and shame.

Re:firefox caves again

[Lehk228]

I don't think supporting a number of nonstandard tags originating from a different open source browser engine is hurting anyone's free-dumb

Re:No, we don't.

[roca]

So you're saying the way to get market share is to tell your users to use a different browser.

No big deal, mostly just aliases

[dwheeler]

I looked at the list, and it's really no big deal. Firefox will just add support for some aliases for standard names, so that existing websites that use "-webkit" prefixes will "just work" today. That's good for users, and it doesn't mean the 'death of standards' or anything like that. It's reasonable to ask people to use the standard names going *forward*. However, it takes a long time for older sites to update, and they rarely update completely correctly. This decision means that Firefox users will have a good experience looking at other sites.

Re:Standard cliche-liketalking points, sadly!

[roca]

We thought we should try site evangelism and education first. They didn't work. With Microsoft's help they might have had a better chance (though I think they probably still wouldn't have worked), but Microsoft caved before we did.