3 ms·

The Great WebKit Comparison Table

32 points by mikecane 16y ago

icefox 16y ago
dupe from months ago
- windsurfer 16y ago
  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.
seiji 16y ago
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 16y ago
  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 16y ago
    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 16y ago
      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).
wayne 16y ago
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 16y ago
  Different versions of WebKit, primarily. The chart seems to include every version that has shipped since '07.
- sprout 16y ago
  I discovered the other day that Android's WebKit forgoes SVG support to save 1mb in the binary... which kind of pisses me off on my Droid, where that is really unnecessary. But mostly I would say it's timing, you have to freeze at some point and make a stable release.
andrewl-hn 16y ago
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 16y ago
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..

32 points by mikecane 16y ago

icefox 16y ago

dupe from months ago

windsurfer 16y ago
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.

seiji 16y ago

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 16y ago
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 16y ago
  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 16y ago
    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).

wayne 16y ago

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 16y ago
Different versions of WebKit, primarily. The chart seems to include every version that has shipped since '07.
sprout 16y ago
I discovered the other day that Android's WebKit forgoes SVG support to save 1mb in the binary... which kind of pisses me off on my Droid, where that is really unnecessary. But mostly I would say it's timing, you have to freeze at some point and make a stable release.

andrewl-hn 16y ago

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 16y ago

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