
Firefox 49 fixes sites designed with WebKit in mind, and more - dwaxe
https://hacks.mozilla.org/2016/09/firefox-49-fixes-sites-designed-with-webkit-in-mind-and-more/
======
Ezhik
I'm worried about Chrome's dominance, honestly. Google can basically dictate
things the same way Microsoft did in the past. We are obviously not in quite
the same situation - open source and all, but there have ready been several
cases where Google just decided to do things, and other players in the field
had no choice but to follow.

~~~
prohor
Yes like this one - just dropping part of current SVG standard that was
supported by all browsers. Without any notification and replacement it broke
some sites. Why? Because it was too much code, low adoption and it is
depreciated in SVG 2.0 _draft_.

[https://bugs.chromium.org/p/chromium/issues/detail?id=539385](https://bugs.chromium.org/p/chromium/issues/detail?id=539385)

~~~
chickenbane
Actually, Chrome dropping a feature that was removed from a spec, was a lot of
code and had low adoption sounds like a good idea.

Engineering is always about trade-offs, and choosing a good balance in Chrome
is what made it so popular. The parent of this comment was worried about
Chrome's "dominance", but remember Chrome was the last browser to the party.
Safari's dominance appears to be the reason Firefox added -webkit prefixes.

If you really think the SVG feature was important and Chrome should support
it, then lobby for it to be part of the standard and for other web developers
to use it. But it's not a great example of Chrome pushing its whim on others.

~~~
prohor
Yes, but the problem it is part of _current_ standard, 2.0 is still work in
progress. Also alternative API from SVG 2.0 is not yet delivered by Chrome
either as far as I know.

~~~
gsnedders
The Chrome team removed something that there was agreement across all browsers
to deprecate, and which was made optional in a near-finished spec.

Also, it's perfectly typical for drafts to be what implementers are targeting,
as plenty of published specs receive almost no errata and any issues in them
only get addressed in new revisions.

------
liquidise
In response to the complaints about "this is Big Internet Corps. fault", i
think that is hasty. I code systems for all major modern browsers (including
IE and Edge) and Cordova. I can count on exactly 0 fingers the number of times
i have used a '-browser' prefix in the last year.

The fact of the matter is that standards are moving fast and better still is
the rate at which browsers are implementing those standards is very powerful.

The use of css prefixes is, in my opinion, lazy. Many of popular directives
are now implemented by browsers in the generic form anyways. The ones that are
not can almost always be achieved through another styling method.

~~~
kccqzy
I use flexbox (with autoprefixer) extensively and I think achieving similar
designs without flexbox is a waste of programmer productivity. Yes I am lazy
but I think it's productive.

~~~
masklinn
Flexbox is available unprefixed in all current browser versions.

------
sigvef
Thanks Mozilla! Lots of great work being done, and it can be easy to take it
for granted at times. This release makes me particularly happy because if
fixes a WebRTC/MediaStream bug that I've been wrestling with on my current
project ( [https://www.zombocam.com](https://www.zombocam.com) ) for a few
weeks. So thank you Firefox team!

~~~
alexbecker
Is this named for [http://www.zombo.com/](http://www.zombo.com/) by any
chance?

~~~
sigvef
Anything is possible with Zombocam :P

------
6mirrors
From the perspective of web developers, this is a bad decision as it
encourages the _direct_ use of non-standard features and thus leaves even more
space for compatibility issues. Here is why:

If firefox doesn't support -webkit prefix, the developers are forced to
consider the compatibility issues and use something like "autoprefixer" to
help. All of the experimental features will work as well as they could on
different browsers (IE, Chrome, Firefox...)

But if firefox support -webkit prefix and the developers buy it, they will
write something like '-webkit-feature' directly and assume it will work on the
_major browsers_. The problem is, _major browsers_ only includes _webkit based
browsers_ , what about IE ?

If a developer uses a non-standard feature directly, forcing he/she to
consider the potential problems is better than leaving him/her a fragile
solution.

~~~
djsumdog
I have to agree totally. This change is asinine. They're basically inserting a
regression away from standards just so content will look slightly better in
their bowser (To gain browser share?)

~~~
EdSharkey
I think Firefox will continue to support non-prefixed equivalents as well.
Also, it seems like there are some useful -webkit- prefixed CSS properties
that haven't yet been standardized with an unprefixed name. I think this is a
good thing, they're adding new features that will (hopefully) get standardized
someday.

Let's heap some scorn on those websites and internal corporate teams that do
all their work on Chrome and Safari and never test on other browsers. It's
always laziness (not testing their crap at all) or lame excuses (Chrome is
faster, why would I bother?) that's to blame.

I don't mind being the "Firefox guy" on teams I'm part of and making sure my
baby always gets some love.

------
consto
These sites have all broken because of the way browsers handle new css
properties, and by that I mean the -browser prefix. Web developers see this
new shiny feature that either makes the page prettier, or easier to create, of
course they'll use them.

If browser developers really wanted web developers not to use these properties
they would have to be enabled, manually, per browser. That would allow people
to create implementations and test them, but stop prefixes getting onto the
general web. Instead we are left with many browsers (i.e. not chrome) being
forced to implement each others prefixes, and to a lesser extend JS libraries.

~~~
TazeTSchnitzel
> If browser developers really wanted web developers not to use these
> properties they would have to be enabled, manually, per browser.

That is precisely the approach being taken these days. Prefixes are legacy.

------
hobarrera
For years now it's been obvious that Chrome is the new IE. This merely makes
it even more obvious.

~~~
bitmapbrother
No, IE shit the bed with its pathetic compliance with web standards. If
anything, Edge is the new IE. Chrome is one of the most web standard compliant
browsers out there and as long as it stays that way I'm okay with its
dominance.

~~~
gcp
_Chrome is one of the most web standard compliant browsers out there_

It helps if you're the one making the standards. Much of the current web
standardization effort is just documenting what Chrome does and what
particular bugs Blink has.

~~~
masklinn
> Much of the current web standardization effort is just documenting what
> Chrome does and what particular bugs Blink has.

Which is exactly what "the current web standardisation" was with respect to
MSIE back in the days of the Second War.

~~~
gcp
Well yes, but there was also significant outreach effort to get rid of the
most egregious IE specifics and show how things could be done better and
cleaner with (non IE specific) web standards. And that part was rather
successful.

------
chaosfox
hah thats funny, back in the day Opera also supported webkit prefixes[1],
today it uses the blink engine.

1\.
[http://www.opera.com/docs/specs/presto2.12/css/aliases/](http://www.opera.com/docs/specs/presto2.12/css/aliases/)

~~~
tr4656
Blink is a fork of webkit so it supports webkit prefixes anyways.

~~~
thunderbong
He's talking about Opera 12 and before which was built on the Presto engine,
not the Webkit engine

~~~
codedokode
The case with Opera is interesting. The web standards became so complicated
that Opera was unable to maintain their alternative engine and implement all
of new features. Microsoft might have to switch to webkit in the future too.

------
teekert
So, will I now see that very very nice mobile ui for outlook on FF mobile as
well as on Chrome on android?

Edit: Yes!! Finally!!

Now, if only it would handle favicons the way chrome does it (many sites have
a nice favicon for on the Android Launcher desktop in chrome, while in FF they
get a low res white on orange star icon. Very ugly... On second inspection,
seems like Chrome makes nice icon out of the first letter of the main domain
and matches the main color to the one used on the site as a default, while FF
has that star.)

Also, it lacks drag-to-refresh as it does in Chrome. But I can tap the address
bar and "enter" of course.

~~~
nachtigall
> Also, it lacks drag-to-refresh as it does in Chrome. But I can tap the
> address bar and "enter" of course.

You can also "Menu" > "Reload".

------
EdSharkey
Stick it to 'em, Mozilla! Don't let perfect be the enemy of the good.

------
minitech
Firefox 49 supports background-clip: text, but thanks to these changes, the
safest pattern to use to get it working in Firefox is still the -webkit one!

    
    
      color: #0dd;
    
      background-image: -webkit-linear-gradient(to right, #0cf, #0fc);
      -webkit-background-clip: text;
      -webkit-text-fill-color: transparent;
    

[https://jsfiddle.net/8kyzg826/](https://jsfiddle.net/8kyzg826/)

------
frik
That was the tipping point of Opera and IE/Edge too. Opera 12 had various
methods to emulate other browsers behaviours and compatibility domain-lists,
in the end Opera 12 died and the next version, Opera 15, was just a fork of
Chromium. IE/Edge feels pretty broken in modern web similar to Opera 12 back
then.

The question is were is webkit/Safari is this game. Most website have
stylesheets that mention webkit prefixes, and it's now clear why Google
removed the prefixes from their webkit fork (blink). It's bad for the end user
and the web devs, but good for them.

------
Scarbutt
One of the reasons I moved back to chrome from firefox was that it got
annoying of dealing with websites that didn't work well in firefox, so this is
a good UX improvement IMO.

But now it means firefox has to chase chrome's tail all the time?

~~~
dblohm7
It shouldn't: experimental web features are now hidden behind browser
preferences instead of prefixes that anybody can (ab)use.

------
Bino
Hmm, I really feel Apple is to blame for this mess, just my gut feeling.

~~~
kitsunesoba
Mozilla is at least partially responsible as well. WebKit only became as
dominant as it did because it was readily and easily embeddable, highly
portable, and nearly language and toolkit agnostic.

Gecko easily could've become a major player as well, but instead of looking
ahead and making Gecko more appealing to developers and OEMs, they dropped
support for embedded Gecko entirely and doubled down on Gecko and Firefox for
all practical purposes being one in the same and forcing anyone interested in
using Gecko to wrestle around with XULRunner.

So today WebKit is everywhere (even where Chrome/Blink isn't) and is the bar
all others are measured by. Had Mozilla been more amicable to projects like
Camino and K-Meleon things might be different now.

~~~
pcwalton
KHTML was hardly embeddable, portable, or language/toolkit agnostic at the
time.

~~~
lmm
It was absolutely embeddadble - the KPart was a first-class supported way of
using it (widely used in other KDE applications) - and at least somewhat
portable (KDE on windows predates WebKit).

~~~
gcp
But didn't KPart rely on KDE (libs)? That's hardly embeddable in any
meaningful sense. Gecko was embeddable too if everything you wrote was XUL :-)

~~~
lmm
Kdeui was (and remains) a first-class toolkit for writing arbitrary
applications (and widely used as such) in a way that XUL has never really
been.

~~~
pcwalton
I think "embeddable" means at least "I have an arbitrary Charles Petzold-style
Win32 app and I want to put KHTML in it without adopting my whole app to a
framework". KParts was never really designed for this.

