

The Great WebKit Comparison Table - mikecane
http://www.quirksmode.org/webkit.html

======
wayne
What's the high-level reason for such a big discrepency between WebKit
browsers? E.g. I'm confused why some would have :nth-child support and other
wouldn't. Do all these companies have their own local forks? Are some using
old versions of WebKit?

~~~
tvon
Different versions of WebKit, primarily. The chart seems to include every
version that has shipped since '07.

------
andrewl-hn
I'm watching this table closely for quite a while. The real thing is that
there's no WebKit on mobile YET. Over time all those players are getting more
and more standards-complaint and as a result there are less differences
between them now than it was, say, half a year ago. It's especially true for
more relevant once (Safari, iPhone/iPad, Android and Chrome). Other players,
notably Symbian, evolving much slower. Also it's always a pleasure to see when
a newer player behaves favorably and is serious about standard-compliance.
Bada does a very good job, unlike WebOS.

------
ZeroGravitas
Didn't someone take this chart and scale it by marketshare (e.g. iOS version 2
and Android version 1.0 would basically disappear)? If they didn't someone
should, because at the moment it's intentionally deceiving to make a point,
but hiding behind its slant behind its boring tabular nature..

------
seiji
This is how Chrome identifies itself: "Mozilla/5.0 (X11; U; Linux x86_64; en-
US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.70 Safari/533.4"

It's AppleWebKit, Chrome, KHTML, Gecko _and_ Safari. They sure don't want to
be left out.

~~~
pornel
It's also Mozilla. This won't stop until authors realize that User-Agent
sniffing is stupid. Unfortunetly there's no sign of that happening, e.g. Vimeo
requires desktop Safari to have Flash installed unless User-Agent contains
word "iPad".

~~~
wanderr
Real question: if user agent sniffing is wrong, what is the proper way of
determining whether certain behavior will be buggy in a given browser?

Example: every browser sends mouse events (esp relating to scolling) to
plugins differently. We have to check the agent string and react accordingly
so the scroll wheel on mice behaves consistently across all browsers.
Iceweasel failed and had broken scroll support from us for months because we
didn't know they send a completely different user agent string, apparently to
discourage sniffing. Ironically that just meant we had to add that agent
string to the list.

Is there a better way to handle those issues that doesn't involve sniffing the
agent string?

~~~
pornel
I don't know specifics of the bug you mention.

If possible, run a test to check if function behaves correctly (this is good
for parsing and CSS bugs, less for user input).

If the bug is undetectable via test, but is already fixed in later version of
the engine, test for engine and presence of feature added at that time (that's
a bit icky too, but at least dependent on behaviour, rather than just name
that browser reports).

It's not always possible not to sniff, but it's still bad. e.g. what if bug is
fixed in later version, but you keep applying workaround?

At least if you sniff, don't look for brand (Firefox/Iceweasel), but for
engine (Gecko is so nice that it includes build date).

------
icefox
dupe from months ago

~~~
windsurfer
Whoop dee do, I didn't see it. Don't upvote if you've seen it before and we'll
get the community to decide if it's important.

