feedutils 0.5.0 → 0.5.1

Sign up to get free protection for your applications and to get access to all the features.
Files changed (12) hide show
  1. checksums.yaml +4 -4
  2. data/Manifest.txt +3 -0
  3. data/README.md +67 -1
  4. data/lib/feedutils.rb +2 -0
  5. data/lib/feedutils/builder/atom.rb +16 -14
  6. data/lib/feedutils/helper/atom_v03.rb +66 -0
  7. data/lib/feedutils/parser.rb +10 -1
  8. data/lib/feedutils/version.rb +1 -1
  9. data/test/feeds/quirksblog.atom.v03 +1098 -0
  10. data/test/helper.rb +6 -1
  11. data/test/test_atom_v03.rb +41 -0
  12. metadata +6 -2
checksums.yaml CHANGED
@@ -1,7 +1,7 @@
1
1
  ---
2
2
  SHA1:
3
- metadata.gz: fc27ca90a5876fa6ae3ca6abaad1dba94d95a19b
4
- data.tar.gz: 704c4187ca9e9b903fe99ecee3f45c7e5d0150cc
3
+ metadata.gz: 87c86554fce1375bc1009ee9c69e0403a580f8ba
4
+ data.tar.gz: c20b98e0b8236f105e81920191d676a82a692a1a
5
5
  SHA512:
6
- metadata.gz: 19f0245d4dd3e01403ef6d822ddca5022178b6718201af402fcdd9f7963252acea856cdc45b3e28103f1e5efc92f9be5c2ee4abd78d2896d85af2f7929c96584
7
- data.tar.gz: 8b684e82f2ba8473dc80ec5f4a02a0c10df15e0342aa4b182aaba6a55746dc8fd343d620e864a718056e1c6df4253c1e7d10e8e3d169d3551711e9c7a31c706f
6
+ metadata.gz: 6c94d61659eae2168d085528cba9635df42b3ec90834df8c4d33778e9b1e82bfda84b806baf29656b7411adc87662c8ccb42f90f147508bfe6dcfceb788791be
7
+ data.tar.gz: dc77c30d67b9c4364febaeaf8c51e56b891ed74bb82b0c6a3aa98c30cc9d7f8c413dbb899fe6df6a7ea1ca52b9ab15bdf07c112d309fc224c97c1a4384bd404a
data/Manifest.txt CHANGED
@@ -6,12 +6,15 @@ lib/feedutils.rb
6
6
  lib/feedutils/builder/atom.rb
7
7
  lib/feedutils/builder/rss.rb
8
8
  lib/feedutils/feed.rb
9
+ lib/feedutils/helper/atom_v03.rb
9
10
  lib/feedutils/item.rb
10
11
  lib/feedutils/parser.rb
11
12
  lib/feedutils/version.rb
12
13
  test/feeds/googlegroups.atom
13
14
  test/feeds/googlegroups2.atom
15
+ test/feeds/quirksblog.atom.v03
14
16
  test/helper.rb
15
17
  test/test_atom.rb
16
18
  test/test_atom_from_file.rb
19
+ test/test_atom_v03.rb
17
20
  test/test_rss.rb
data/README.md CHANGED
@@ -11,7 +11,73 @@ feedutils gems - web feed parser and normalizer (RSS 2.0, Atom, etc.)
11
11
 
12
12
  ## Usage
13
13
 
14
- TBD
14
+ ### Structs
15
+
16
+ Feed • Item
17
+
18
+ ### `Feed` Struct
19
+
20
+ ~~~
21
+ class Feed
22
+ attr_accessor :format # e.g. atom|rss 2.0|etc.
23
+ attr_accessor :title
24
+ attr_accessor :title_type # e.g. text|html|html-escaped (optional) -use - why?? why not??
25
+ attr_accessor :url
26
+
27
+ attr_accessor :items
28
+
29
+ attr_accessor :summary # e.g. description (rss)
30
+ attr_accessor :summary_type # e.g. text|html|html-escaped
31
+
32
+ attr_accessor :title2 # e.g. subtitle (atom)
33
+ attr_accessor :title2_type # e.g. text|html|html-escaped
34
+
35
+ attr_accessor :published
36
+ attr_accessor :updated
37
+ attr_accessor :built
38
+
39
+ attr_accessor :generator
40
+ attr_accessor :generator_version # e.g. @version (atom)
41
+ attr_accessor :generator_uri # e.g. @uri (atom) - use alias url/link ???
42
+ end
43
+ ~~~
44
+
45
+
46
+ ### `Item` Struct
47
+
48
+ ~~~
49
+ class Item
50
+ attr_accessor :title
51
+ attr_accessor :title_type # optional for now (text|html|html-escaped) - not yet set
52
+ attr_accessor :url # todo: rename to link (use alias) ??
53
+
54
+ attr_accessor :content
55
+ attr_accessor :content_type # optional for now (text|html|html-escaped|binary-base64) - not yet set
56
+
57
+ attr_accessor :summary
58
+ attr_accessor :summary_type # optional for now (text|html|html-escaped) - not yet set
59
+
60
+ attr_accessor :published
61
+ attr_accessor :updated
62
+
63
+ attr_accessor :guid # todo: rename to id (use alias) ??
64
+ end
65
+ ~~~
66
+
67
+
68
+ ### Read Feed Example
69
+
70
+ ~~~
71
+ require 'open-uri'
72
+ require 'feedutils'
73
+
74
+ xml = open( 'http://openfootball.github.io/atom.xml' ).read
75
+
76
+ feed = FeedUtils::Parser.parse( xml )
77
+ pp feed
78
+ ~~~
79
+
80
+
15
81
 
16
82
  ## Alternatives
17
83
 
data/lib/feedutils.rb CHANGED
@@ -15,6 +15,8 @@ require 'feedutils/version' # let it always go first
15
15
  require 'feedutils/builder/atom'
16
16
  require 'feedutils/builder/rss'
17
17
 
18
+ require 'feedutils/helper/atom_v03'
19
+
18
20
  require 'feedutils/feed'
19
21
  require 'feedutils/item'
20
22
  require 'feedutils/parser'
data/lib/feedutils/builder/atom.rb CHANGED
@@ -28,32 +28,34 @@ class AtomFeedBuilder
28
28
  logger.debug " atom | title.content >#{atom_feed.title.content}< : #{atom_feed.title.content.class.name}"
29
29
 
30
30
 
31
- ## note: for now assume id is feed (html)url
32
- ## use url only if starts_with http
33
- ## might not be link e.g blogger uses for ids =>
34
- ## <id>tag:blogger.com,1999:blog-4704664917418794835</id>
35
- ##
36
- ## Note: remove (strip) leading and trailing spaces and newlines
37
-
38
- if atom_feed.id.content.strip.start_with?( 'http' )
39
- feed.url = atom_feed.id.content.strip
40
- else
41
- feed.url = nil
42
- end
43
-
44
31
  logger.debug " atom | id.content >#{atom_feed.id.content}< : #{atom_feed.id.content.class.name}"
45
32
 
33
+ feed.url = nil
34
+
46
35
  ## note: use links (plural to allow multiple links e.g. self,alternate,etc.)
47
36
  atom_feed.links.each_with_index do |link,i|
48
37
  logger.debug " atom | link[#{i+1}] link rel=>#{link.rel}< : #{link.rel.class.name} type=#{link.type} href=#{link.href}"
49
38
 
50
- ## for now assume alternate is link or no rel specified (assumes alterante)
39
+ ## for now assume alternate is link or no rel specified (assumes alternate)
51
40
  ## note: only set if feed.url is NOT already set (via <id> for example)
52
41
  if feed.url.nil? && (link.rel == 'alternate' || link.rel.nil?)
53
42
  feed.url = link.href
54
43
  end
55
44
  end
56
45
 
46
+ ## note: as fallback try id if still no url found
47
+ ## use url only if starts_with http
48
+ ## might not be link e.g blogger uses for ids =>
49
+ ## <id>tag:blogger.com,1999:blog-4704664917418794835</id>
50
+ ##
51
+ ## note: id might actually be link to feed NOT to site (remove fallback - why - why not???)
52
+ ##
53
+ ## Note: remove (strip) leading and trailing spaces and newlines
54
+
55
+ if feed.url.nil? && atom_feed.id.content.strip.start_with?( 'http' )
56
+ feed.url = atom_feed.id.content.strip
57
+ end
58
+
57
59
 
58
60
  if atom_feed.updated
59
61
  # NOTE: empty updated.content e.g. used by google groups feed
data/lib/feedutils/helper/atom_v03.rb ADDED
@@ -0,0 +1,66 @@
1
+ # encoding: utf-8
2
+
3
+
4
+ ###
5
+ # hack:
6
+ ## try to patch/convert old obsolete atom v0.3 to v1(-ish)
7
+ ##
8
+ ## in <feed> convert
9
+ ## version="0.3" => removed/dropped! - use ns for version
10
+ ## xmlns="http://purl.org/atom/ns#" => xmlns="http://www.w3.org/2005/Atom"
11
+ ##
12
+ ## <modified>2014-12-31T15:33:00Z</modified> => <updated>
13
+ ## <issued>2014-12-31T13:02:07Z</issued> => <published>
14
+ ##
15
+ ##
16
+ ## more changes:
17
+ ## author url => author uri
18
+ ## generator @url => generator @uri
19
+ ## tagline => subtitle
20
+ ## copyright => rights
21
+ ## <created>2014-12-31T13:02:07Z</created> => removed/dropped!
22
+ ##
23
+ ## todo/fix: fix/convert content @type @mode - why?? why not??
24
+ ##
25
+ ## content @mode => removed/dropped!
26
+ ## @type=text/plain @mode=escaped => @type=text
27
+ ## @type=text/html @mode=escaped => @type=html
28
+
29
+
30
+ ## see also
31
+ ## - rakaz.nl/2005/07/moving-from-atom-03-to-10.html
32
+
33
+
34
+ module FeedUtils
35
+
36
+ class AtomV03Helper
37
+
38
+ include LogUtils::Logging
39
+
40
+ def match?( xml )
41
+ ## Note: =~ return nil on match; convert to boolean e.g. always return true|false
42
+ (xml =~ /<feed\s+version="0\.3"/) != nil
43
+ end
44
+
45
+ def convert( xml )
46
+ xml = xml.sub( /<feed[^>]+>/ ) do |m|
47
+ ## Note: m passed in is just a string w/ the match (NOT a match data object!)
48
+ ## puts "match (#{m.class.name}): "
49
+ ## pp m
50
+ el = m.sub( /version="0\.3"/, '' )
51
+ el = el.sub( /xmlns="http:\/\/purl\.org\/atom\/ns#"/, 'xmlns="http://www.w3.org/2005/Atom"' )
52
+ el
53
+ end
54
+
55
+ xml = xml.gsub( /<modified>/, '<updated>' )
56
+ xml = xml.gsub( /<\/modified>/, '</updated>' )
57
+
58
+ xml = xml.gsub( /<issued>/, '<published>' )
59
+ xml = xml.gsub( /<\/issued>/, '</published>' )
60
+ xml
61
+ end
62
+
63
+ end # class AtomV03Helper
64
+
65
+ end # module FeedUtils
66
+
data/lib/feedutils/parser.rb CHANGED
@@ -14,12 +14,21 @@ class Parser
14
14
  ### Note: lets keep/use same API as RSS::Parser for now
15
15
  def initialize( xml )
16
16
  @xml = xml
17
+ @atomv03helper = AtomV03Helper.new
17
18
  end
18
19
 
20
+
19
21
  def parse
20
22
  logger.debug "using stdlib rss/#{RSS::VERSION}"
21
23
 
22
- parser = RSS::Parser.new( @xml )
24
+ ## old (obsolete) Atom Version 0.3 - try to patch/upgrade to 1.0(-ish)
25
+ if @atomv03helper.match?( @xml )
26
+ logger.warn "*** atom v0.3 feed; try to patch/upgrade to 1.0(-ish); please use/find atom v1.0 feed"
27
+ parser = RSS::Parser.new( @atomv03helper.convert( @xml ))
28
+ else
29
+ parser = RSS::Parser.new( @xml )
30
+ end
31
+
23
32
  parser.do_validate = false
24
33
  parser.ignore_unknown_element = true
25
34
 
data/lib/feedutils/version.rb CHANGED
@@ -4,7 +4,7 @@ module FeedUtils
4
4
 
5
5
  MAJOR = 0
6
6
  MINOR = 5
7
- PATCH = 0
7
+ PATCH = 1
8
8
  VERSION = [MAJOR,MINOR,PATCH].join('.')
9
9
 
10
10
  def self.version
data/test/feeds/quirksblog.atom.v03 ADDED
@@ -0,0 +1,1098 @@
1
+ <?xml version="1.0" encoding="utf-8"?>
2
+ <feed version="0.3" xmlns="http://purl.org/atom/ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xml:lang="en">
3
+ <title>QuirksBlog</title>
4
+ <link rel="alternate" type="text/html" href="http://www.quirksmode.org/blog/" />
5
+ <modified>2014-12-31T15:33:00Z</modified>
6
+ <tagline></tagline>
7
+ <id>tag:www.quirksmode.org,2014:/blog//1</id>
8
+ <generator url="http://www.movabletype.org/" version="3.14">Movable Type</generator>
9
+ <copyright>Copyright (c) 2014, ppk</copyright>
10
+
11
+ <entry>
12
+ <title>A new Microsoft browser?</title>
13
+ <link rel="alternate" type="text/html" href="http://www.quirksmode.org/blog/archives/2014/12/a_new_microsoft.html" />
14
+ <modified>2014-12-31T15:33:00Z</modified>
15
+ <issued>2014-12-31T13:02:07Z</issued>
16
+ <id>tag:www.quirksmode.org,2014:/blog//1.2445</id>
17
+ <created>2014-12-31T13:02:07Z</created>
18
+ <summary type="text/plain"><p>Recently the news broke that Microsoft may be working on another browser instead of IE. After reviewing the available evidence I&amp;#8217;ve come to the conclusion that, although Microsoft is making a few adjustments, and a name change for IE might...</p></summary>
19
+ <author>
20
+ <name>ppk</name>
21
+ <url>http://www.quirksmode.org/</url>
22
+ <email>ppk@xs4all.nl</email>
23
+ </author>
24
+ <dc:subject>IE</dc:subject>
25
+ <content type="text/html" mode="escaped" xml:lang="en" xml:base="http://www.quirksmode.org/blog/">
26
+ <![CDATA[<p>Recently the <a href="http://www.zdnet.com/article/microsoft-is-building-a-new-browser-as-part-of-its-windows-10-push/" class="external">news broke</a> that Microsoft may be working on another browser instead of IE. After reviewing the available evidence I&#8217;ve come to the conclusion that, although Microsoft is making a few adjustments, and a name change for IE might be a good idea, the new browser will essentially be IE12. Still, I think we web developers should support the &#8220;new browser&#8221; narrative.</p>
27
+ ]]>
28
+ <![CDATA[<p>It seems the <a href="http://www.neowin.net/news/internet-explorer-12-big-changes-are-coming-to-trident" class="external">decision was taken</a> to fork Trident, Microsoft&#8217;s rendering engine. One version will essentially be IE11 with all backward-compatible bells and whistles, while the other one will be IE12, although it may carry a different name and will <a href="http://www.neowin.net/news/internet-explorer-12-ui-overhaul-is-a-blend-of-chrome-and-firefox-adds-extension-support" class="external">sport a new interface and support extensions</a>. (IE extensions, that is. Not Chrome or Firefox extensions.)</p>
29
+
30
+ <p>The idea seems to be that Windows 10 will ship both these browsers. The Internet icon on the desktop will start up IE12, while &#8220;if a page calls for IE to render in a compatibility mode&#8221; IE11 will be started up. I am assuming that what&#8217;s meant here is the <a href="http://msdn.microsoft.com/en-us/library/jj676915(v=vs.85).aspx" class="external">meta versioning switch</a>.</p>
31
+
32
+ <p>Remember that to this day IE11 also contains IE 10, 9, 8, 7, and 5.5, which are accessible through the <a href="/blog/archives/2008/01/the_versioning_1.html">once-maligned</a> but now mostly-forgotten meta versioning switch, as well as, in the case of 5.5, the good old <a href="/css/quirksmode.html">doctype switch</a>.</p>
33
+
34
+ <p>The plan seems to be that the new IE12 will not carry all that cruft, but be a forward-looking modern browser. If you need legacy stuff you must start up another browser. Actually this is not such a bad idea. The versioning switch never really caught on on the public Internet (although corporate Intranets may be a different story), so why weigh IE down with a lot of other rendering engines that hardly anyone outside a corporate environment will ever need?</p>
35
+
36
+ <p>An implication of forking IE is that the new IE11 would be maintained separately from IE12. That might be interesting, although it&#8217;s also a lot of hassle for Microsoft. We&#8217;ll have to see if they&#8217;re really going to maintain two browsers.</p>
37
+
38
+ <p>Finally, IE may be changing names in the near future. Actually, that&#8217;s a pretty good idea. The brand &#8220;IE&#8221; has become synonymous with slow, old-fashioned, non-standard-compliant browsing &#8212; even though from IE10 on there was little reason for that judgement. But IE is being weighed down by the IE6 legacy, and a new name may be just what it needs. So let&#8217;s do it. (But not &#8220;Spartan,&#8221; please. It doesn&#8217;t make sense for a browser. Why not an explorer from the good old days? Maybe even a Dutch one?)</p>
39
+
40
+ <p>Internally, when talking to other web devs, you should treat the next Microsoft browser as IE12. Externally, however, when talking to clients and other non-techies, it could make sense to support the &#8220;Microsoft is creating a new browser&#8221; narrative. Who knows, your clients or other contacts may decide it&#8217;s time to say goodbye to their old IE versions and embrace the new browser. That would help them, us, and Microsoft at the same time.</p>
41
+ ]]>
42
+ </content>
43
+ </entry>
44
+ <entry>
45
+ <title>Gradients (and screenshots) update</title>
46
+ <link rel="alternate" type="text/html" href="http://www.quirksmode.org/blog/archives/2014/11/gradients_and_s.html" />
47
+ <modified>2014-11-26T12:11:25Z</modified>
48
+ <issued>2014-11-26T12:09:47Z</issued>
49
+ <id>tag:www.quirksmode.org,2014:/blog//1.2444</id>
50
+ <created>2014-11-26T12:09:47Z</created>
51
+ <summary type="text/plain"><p>Just now I published the retests of the CSS Images and replaced content spec, which includes gradients. It was during these tests yesterday that I discovered Android screenshots aren&amp;#8217;t always trustworthy, and meanwhile I&amp;#8217;ve got enough information for an update....</p></summary>
52
+ <author>
53
+ <name>ppk</name>
54
+ <url>http://www.quirksmode.org/</url>
55
+ <email>ppk@xs4all.nl</email>
56
+ </author>
57
+ <dc:subject>Content</dc:subject>
58
+ <content type="text/html" mode="escaped" xml:lang="en" xml:base="http://www.quirksmode.org/blog/">
59
+ <![CDATA[<p>Just now I published the retests of the <a href="/css/images/">CSS Images and replaced content</a> spec, which includes gradients. It was during these tests yesterday that I discovered <a href="/blog/archives/2014/11/android_gradien.html">Android screenshots aren&#8217;t always trustworthy</a>, and meanwhile I&#8217;ve got enough information for an update.</p>
60
+
61
+ <p>Many people advised me to take a screenshot of the screenshot. I did, and it shows the original screenshot correctly instead of repeating the problem. So this avenue of research does not lead anywhere.</p>
62
+ ]]>
63
+ <![CDATA[<h3>The screenshot problem</h3>
64
+
65
+ <p>The vast majority of commenters agrees that the screenshot problem is caused by incorrect calibration of the device screen; that is, the correct gradient RGBA colour values the browser passes on to the OS cannot be processed correctly, and as a result the colours as shown on the screen are incorrect. However, the screenshot app gets its data directly from the browser, and thus shows the correct colours.</p>
66
+
67
+ <h4>Meta-screenshots - no go</h4>
68
+
69
+ <p>The most often-repeated advice I got was to take a screenshot of the published screenshot and see what happens. Apparently the expectation was that this meta-screenshot would have the same problems as the original gradient. That turns out not to be the case.</p>
70
+
71
+ <p>Here is my first ever meta-screenshot, taken with the Sony Xperia S of <a href="/blog/archives/2014/11/android_gradien.html">yesterday&#8217;s screenshots</a>. For comparison I also repeat the original screenshot.</p>
72
+
73
+ <p><img src="/blog/pix/gradients/xperia_metascreenshot.png" class="screenshot" alt="A screenshot of yesterday's screenshot."></p>
74
+
75
+ <p><img src="/blog/pix/gradients/xperia_screenshot.png" class="screenshot" alt="Yesterday's screenshot"></p>
76
+
77
+ <p>I don&#8217;t see a lot of difference in the gradient, and the conclusion must be that the Xperia handles the image correctly, and does not repeat the original calibration problems here. So this research angle leads nowhere.</p>
78
+
79
+ <h4>Affected devices</h4>
80
+
81
+ <p>The final question is which devices are actually incorrectly calibrated. I went through all of my devices that have a browser capable of showing gradients, sent them to <a href="/css/images/position.html">the test page</a>, and the results are in the table below:</p>
82
+
83
+ <style>
84
+ table td {
85
+ border: 1px solid;
86
+ width: 15em;
87
+ padding: 5px;
88
+ vertical-align: top;
89
+ }
90
+
91
+ </style>
92
+
93
+ <table>
94
+ <tr>
95
+ <th>Calibrated</th>
96
+ <th>Not calibrated</th>
97
+ </tr>
98
+ <tr>
99
+ <td>
100
+ Apple iPad 2<br>
101
+ Apple iPhone 4S<br>
102
+ BlackBerry Z10<br>
103
+ Google Nexus 4<br>
104
+ Google Nexus 7<br>
105
+ HTC M8<br>
106
+ HTC One X<br>
107
+ Huawei C8813<br>
108
+ Microsoft Surface<br>
109
+ Motorola Moto G<br>
110
+ Nintendo Wii U<br>
111
+ Nokia Lumia 520<br>
112
+ Nokia Lumia 820<br>
113
+ Samsung Galaxy Note I<br>
114
+ Samsung Galaxy S4<br>
115
+ Wolfgang AT-AS45FW<br>
116
+ Xiaomi M2<br>
117
+ </td>
118
+ <td>
119
+ LG L5<br>
120
+ Sony Xperia S<br>
121
+ T2Mobile Flame<br>
122
+ </td>
123
+ </tr>
124
+ </table>
125
+
126
+ <p>It turns out that most devices actually properly calibrate their screens; the only exceptions being the LG L5, Xperia S, and the Flame (the Firefox OS reference device). So this problem may not be as huge as I initially thought.</p>
127
+
128
+ <h3>Other gradient notes</h3>
129
+
130
+ <p>The rest of the tests was fairly uneventful. It turns out that all desktop browsers now support the <a href="/css/images/gradients.html">new syntax</a>, and Safari iOS and Chrome Android do as well. The other WebKit-based browsers still require middle syntax. Interesting, but expected.</p>
131
+
132
+ <p>Also, it turns out that IE has a bug when you define linear gradients with angle keywords in a non-square box. The IE team has meanwhile confirmed the bug and is working on an update. Compare <a href="/css/images/colorstops.html">this page</a> in IE and any other browser, and pay close attention to the red. A corner of each element should show full red, but in IE that doesn&#8217;t happen. Below you see screenshots; IE left, Chrome right.</p>
133
+
134
+ <p><img src="/blog/pix/gradients/bug_ie.png" alt="Color stop test in IE">
135
+ <img src="/blog/pix/gradients/bug_chrome.png" alt="Color stop test in Chrome"></p>
136
+
137
+ <p>Finally, Firefox now supports <a href="/css/images/image-orientation.html">image-orientation</a>. The other browsers don&#8217;t.</p>
138
+
139
+ <p>Anyway, this was an eventful retest. I hope my next one is nice and boring.</p>
140
+ ]]>
141
+ </content>
142
+ </entry>
143
+ <entry>
144
+ <title>Android gradient screenshot madness</title>
145
+ <link rel="alternate" type="text/html" href="http://www.quirksmode.org/blog/archives/2014/11/android_gradien.html" />
146
+ <modified>2014-11-26T12:14:36Z</modified>
147
+ <issued>2014-11-25T17:05:00Z</issued>
148
+ <id>tag:www.quirksmode.org,2014:/blog//1.2443</id>
149
+ <created>2014-11-25T17:05:00Z</created>
150
+ <summary type="text/plain"><p>Another fine day at the QuirksMode test labs, where we test browsers so you don&amp;#8217;t have to. Today&amp;#8217;s topic is CSS gradients, and the subtle ways in which the various Android devices fuck them up. Also, the not-so-subtle ways in...</p></summary>
151
+ <author>
152
+ <name>ppk</name>
153
+ <url>http://www.quirksmode.org/</url>
154
+ <email>ppk@xs4all.nl</email>
155
+ </author>
156
+ <dc:subject>Mobile web dev</dc:subject>
157
+ <content type="text/html" mode="escaped" xml:lang="en" xml:base="http://www.quirksmode.org/blog/">
158
+ <![CDATA[<p>Another fine day at the QuirksMode test labs, where we test browsers so you don&#8217;t have to. Today&#8217;s topic is CSS gradients, and the subtle ways in which the various Android devices fuck them up. Also, the not-so-subtle ways in which Android devices fuck up <strong>screenshots</strong> of said gradients.</p>
159
+ ]]>
160
+ <![CDATA[<p>It turns out that there are differences between gradients on the various Android devices. This is <strong>not</strong> a browser thing, but an actual device thing. I compared the same gradient test on different Android devices in Firefox, Android WebKit, and Chrome, and found the same differences between the browsers. It became obvious that there are incompatibilities between these Androids&#8217; graphical ... thingies, and that browsers don&#8217;t (can&#8217;t?) work around them.</p>
161
+
162
+ <p>So I thought I&#8217;d write a snarky post embellished with some screenshots. It was when I had made those screenshots that the other shoe dropped: <strong>the screenshots show different gradients than the screen</strong>. In other words, Android screenshots cannot be trusted to show subtle browser differences. Actual external pictures taken with a camera are mandatory.</p>
163
+
164
+ <p>This is all so marvelous. No wonder I can&#8217;t quit smoking.</p>
165
+
166
+ <h3>Show, don&#8217;t tell</h3>
167
+
168
+ <p>Compare the following two pictures and ponder the differences. Both show the first test on <a href="/css/images/position.html">this page</a> in Chrome 39 for Android on the Sony Xperia S.</p>
169
+
170
+ <p>The first one is a screenshot taken with the Xperia itself. It shows the more-or-less correct gradient. However, it doesn&#8217;t actually match what the device shows on-screen.</p>
171
+
172
+ <p><img src="/blog/pix/gradients/xperia_screenshot.png"></p>
173
+
174
+ <p>The second one is taken with an external camera. It shows what I see on-screen, and it&#8217;s clear that the gradient is subtly different from the one in the screenshot. The yellow doesn&#8217;t form a narrow band, and the gradient from red to orange takes much less space.</p>
175
+
176
+ <p><img src="/blog/pix/gradients/xperia_camera.png"></p>
177
+
178
+ <p>The first picture matches what I see in desktop browsers and most other Android devices. The second picture matches what Xperia users will actually see. How much of a problem this is depends on the site&#8217;s graphic design and the exact gradients you use, but it&#8217;s a problem you should be aware of.</p>
179
+
180
+ <h3>One more for the road</h3>
181
+
182
+ <p>Hell, let&#8217;s do another one. Here is the same test case, again in Chrome 39, but now on the LG L5. First the screenshot, then the external camera.</p>
183
+
184
+ <p><img src="/blog/pix/gradients/l5_screenshot.png"></p>
185
+
186
+ <p>Again, there is a subtle difference between the gradients, though it&#8217;s less pronounced than with the Xperia. Again, the screenshot matches the other browsers much better than what&#8217;s actually on the screen.</p>
187
+
188
+ <p><img src="/blog/pix/gradients/l5_camera.png"></p>
189
+
190
+ <h3>What&#8217;s going on?</h3>
191
+
192
+ <p>It seems clear that the screenshot app uses a different graphical ... thingy than the screen and/or browser. The screenshot app gets the correct gradients, while the browser window on the screen does not. Again, this is a device problem, and not a browser problem. Firefox, Android WebKit, and Chrome show roughly the same gradient on each device, and the same differences from device to device.</p>
193
+
194
+ <p>Since I don&#8217;t know anything about Android&#8217;s graphical thingies I cannot solve this riddle. Just be aware that there are gradient problems on Android, and also screenshot problems on Android. Wonderful, marvellous.</p>
195
+
196
+ <p>Now if you&#8217;ll excuse me I&#8217;ll go and drink myself into a stupor.</p>
197
+
198
+ <p><strong>Update</strong>: The consensus among those who commented on this article is that the device's screens are badly calibrated. So far it seems LG and Sony are affected, but Samsung and HTC are not.</p>
199
+
200
+ <blockquote><p>The fundamental issue is that a specific RGBA colour value looks
201
+ different on different physical displays, but the screen buffer is
202
+ generated without taking into account the properties of the display.</p></blockquote>
203
+
204
+ <p>(Eli Fidler, BlackBerry)</p>
205
+
206
+ <p>The real point here is that Android screenshots (and remote testing solutions that depend on them) are not reliable enough for web developers to use.</p>
207
+
208
+ <p><strong>Update 2</strong>: See <a href="/blog/archives/2014/11/gradients_and_s.html">this new article</a> for some more information.</p>]]>
209
+ </content>
210
+ </entry>
211
+ <entry>
212
+ <title>Transition tests</title>
213
+ <link rel="alternate" type="text/html" href="http://www.quirksmode.org/blog/archives/2014/11/transition_test.html" />
214
+ <modified>2014-11-05T14:54:55Z</modified>
215
+ <issued>2014-11-05T14:53:57Z</issued>
216
+ <id>tag:www.quirksmode.org,2014:/blog//1.2442</id>
217
+ <created>2014-11-05T14:53:57Z</created>
218
+ <summary type="text/plain"><p>Today I published my tests of CSS transitions in the desktop and mobile browsers. I created the test cases ages ago, but interpreting the results turned out to be tricky....</p></summary>
219
+ <author>
220
+ <name>ppk</name>
221
+ <url>http://www.quirksmode.org/</url>
222
+ <email>ppk@xs4all.nl</email>
223
+ </author>
224
+ <dc:subject>Content</dc:subject>
225
+ <content type="text/html" mode="escaped" xml:lang="en" xml:base="http://www.quirksmode.org/blog/">
226
+ <![CDATA[<p>Today I <a href="/css/transitions/">published</a> my tests of CSS transitions in the desktop and mobile browsers. I created the test cases ages ago, but interpreting the results turned out to be tricky.</p>
227
+ ]]>
228
+ <![CDATA[<p>Big overview: transitions are supported very well, except in the proxy browsers (which can&#8217;t handle this kind of client-side interactivity) and IE9. However, there are a few more subtle problems:</p>
229
+
230
+ <ul>
231
+ <li>All WebKit-based browsers except for Safari still require a <code>-webkit-</code> prefix (die! die!) and don&#8217;t support the transitionend event.</li>
232
+ <li>When zooming in on a page, desktop Safari and the desktop Blink-based browsers transition elements. This should NOT happen, since the element&#8217;s state does not change. This is a serious bug that has been in existence for at least two years &#8212; I remember talking to someone about it. <a href="/css/transitions/zoom.html">Try it here</a>. (Since mobile pinch-zooming is totally different from desktop page-zooming this bug only affects the desktop browsers.)</li>
233
+ <li>Firefox on Android, but not on desktop or Firefox OS, handles quite a few properties in a very ugly, jaggy way. <a href="/css/transitions/properties_mobile.html">Details here</a>.</li>
234
+ </ul>
235
+
236
+ <h3>Implied values</h3>
237
+
238
+ <p>A CSS declaration is only transitionable if it goes from a numeric value to a numeric value. Thus, <code>display</code> will never transition since it doesn&#8217;t have numeric values. An element with <code>height: auto</code> won&#8217;t transition, either, since <code>auto</code> is not a number.</p>
239
+
240
+ <p>The really tricky thing here is default or implied values (<a href="/css/transitions/impliedvalues.html">desktop</a>, <a href="/css/transitions/impliedvalues_mobile.html">mobile</a>). An element has no <code>letter-spacing</code> defined, and transitions to a state that has <code>letter-spacing: 2px</code>. Should the browser transition it or not? Since the default value of <code>letter-spacing</code> is 0, it should. (Firefox doesn&#8217;t, but that&#8217;s a bug.)</p>
241
+
242
+ <p>There are more complicated declarations that can trip you up, though. The most important one is <code>left</code>. What if an element has <code>position: absolute</code> but no coordinates defined? <code>left</code> (and, I suppose, the others) is not <code>0</code>, as you might expect, but <code>auto</code>, which is not a number and thus can&#8217;t handle transitions. All WebKit-based browsers handle this wrong, as do older Chromes. (It was fixed between 30 and 33.)</p>
243
+
244
+ <p>The most complex declaration is <code>border</code>. Suppose an element has no border defined and then transitions to <code>border: 5px solid red</code>. An element without a border has a <code>border-width: 0</code>, that&#8217;s easy. The tricky thing is that <code>border-style</code> uses keywords and thus does not transition.</p>
245
+
246
+ <style>
247
+ div.test {
248
+ -webkit-transition-property: all;
249
+ -webkit-transition-duration: 2s;
250
+ -moz-transition-property: all;
251
+ -moz-transition-duration: 2s;
252
+ -ms-transition-property: all;
253
+ -ms-transition-duration: 2s;
254
+ -o-transition-property: all;
255
+ -o-transition-duration: 2s;
256
+ transition-property: all;
257
+ transition-duration: 2s;
258
+ padding: 10px;
259
+ }
260
+
261
+ div.test:hover {
262
+ border: 5px solid red;
263
+ }
264
+
265
+ </style>
266
+
267
+ <div class="test">
268
+ Hover over this element to view the border effect.
269
+ </div>
270
+
271
+ <p>When transitioning from <code>none</code> to <code>5px solid red</code>, the <code>border-style</code> is immediately set to <code>solid</code>, while <code>border-width</code> transitions in an acceptable way. The users won&#8217;t notice anything. Going the other way, though, <code>border-style</code> is immediately set to <code>none</code> and no transition takes place, which confused me mightily. I actually needed help to figure this out (thanks, <a href="http://www.xanthir.com/blog/" class="external">Tab</a>).</p>
272
+
273
+ <p>Anyway, this goes to show that doing the tests is not the problem; interpreting them is. I hope I got them all right.</p>
274
+ ]]>
275
+ </content>
276
+ </entry>
277
+ <entry>
278
+ <title>Linkbait 32</title>
279
+ <link rel="alternate" type="text/html" href="http://www.quirksmode.org/blog/archives/2014/10/linkbait_32.html" />
280
+ <modified>2014-10-03T13:50:35Z</modified>
281
+ <issued>2014-10-03T13:49:26Z</issued>
282
+ <id>tag:www.quirksmode.org,2014:/blog//1.2441</id>
283
+ <created>2014-10-03T13:49:26Z</created>
284
+ <summary type="text/plain"><p>From the last month or so, with a few older articles....</p></summary>
285
+ <author>
286
+ <name>ppk</name>
287
+ <url>http://www.quirksmode.org/</url>
288
+ <email>ppk@xs4all.nl</email>
289
+ </author>
290
+ <dc:subject>Linkbait</dc:subject>
291
+ <content type="text/html" mode="escaped" xml:lang="en" xml:base="http://www.quirksmode.org/blog/">
292
+ <![CDATA[<p>From the last month or so, with a few older articles.</p>
293
+ ]]>
294
+ <![CDATA[<ul class="linkbait">
295
+
296
+ <li>Older, but still important. Tomi Ahonen <a href="http://communities-dominate.blogs.com/brands/2014/07/samsung-shock-number-is-official-from-investor-relations.html" class="external">reports</a> that Samsung is losing quite a bit of smartphone sales market share, mostly because of competition from cheap Chinese vendors in the developing world.</li>
297
+
298
+ <li>Speaking about Tomi, he also <a href="http://communities-dominate.blogs.com/brands/2014/08/first-time-ever-anywhere-international-data-on-smartphone-unique-owner-installed-base-including-regi.html" class="external">found numbers</a> on smartphone unique owner installed base &#8212; in other words, the number of smartphone owners per 100 people in a country. He trusts the numbers for the developed world, but suspects the Indian and Chinese stats, in particular, only come from metropolitan areas where smartphone ownership is a lot higher than in rural areas.</li>
299
+
300
+ <li>Opera <a href="http://www.operasoftware.com/press/releases/mobile/2014-09-24" class="external">reports</a> that mobile internet users in India continue to move from feature phones (and not basic, as the headline says) to Androids. It offers some stats about this movement, but it should be remembered that the only way for Opera to get these stats is by measuring Opera Mini usage. Thus, consumers who move from a feature phone with Opera Mini to an Android without Opera Mini are not counted, and the total number may be higher.
301
+ Despite that flaw, it&#8217;s good to have some numbers on the Indian market.</li>
302
+
303
+ <li>LG is <a href="http://www.theverge.com/2014/10/2/6888445/lg-webos-smartwatch" class="external">working on</a> a webOS smart watch. Since I continue to doubt if browsers can be installed on smart watches with the current state of the hardware, the webOS stuff will likely be about writing apps in HTML5. That&#8217;s cool in itself, but I doubt it&#8217;s going to draw a lot of developers &#8212; also because the next move LG (or any big Asian company) would make to reach out to web developers would be the first.</li>
304
+
305
+ <li>Interesting Scientia Mobile <a href="http://data.wurfl.io/MOVR/pdf/2014_q2/MOVR_2014_q2.pdf" class="external">report</a> on smartphone usage in western countries relative to Asia. They&#8217;re tweaking the definitions of smartphones and feature phones (about time!)<br>
306
+ Data gathered from hits on WURFL, the device database system that helps you combat device bugs. Some conclusions:
307
+ <ul>
308
+ <li>Tablet usage in the West is over triple that found in Asia.</li>
309
+ <li>Apple market share 39% in the West; 13% in the East</li>
310
+ <li> While Apple dominates the Western markets, Android tablet manufacturers, as a group, hold a lead over Apple in Asia. Nevertheless, Apple’s 31% share of Asia shows a strong presence. </li>
311
+ </ul>
312
+ Much more good stuff in here. Go read it.</li>
313
+
314
+ <li>Cyanogen, the independent provider of Android ROMs, will <a href="http://www.techinasia.com/cyanogen-teams-micromax-enter-india/" class="external">team up</a> with Indian device vendor Micromax to create a new generation of affordable Android phones. This is important for web developers because Cyanogen uses Chromium, and not Android WebKit, as its default browser.</li>
315
+
316
+ <li>Tim Kadlec <a href="http://timkadlec.com/2014/09/js-parse-and-execution-time/" class="external">ran some tests</a> and figured out the parsing and execution time for jQuery 2.1.1 on a variety of mobile and other browsers. The variations are huge; from a median 725 milliseconds on a BlackBerry OS6 to 5 on a modern MacBook Air.<br>
317
+ He concludes that the hardware has the most impact on parsing and execution time, and since a new trend is shaping up where cheap (hence hardware-challenged) phones are being spread through the developing world, this may become a problem in the future. Sure, those phones run modern browsers, but if they don&#8217;t have the hardware to back them up, performance is going to be meh anyway.</li>
318
+
319
+ <li>Steve Souders <a href="http://www.stevesouders.com/blog/2014/09/12/onload-in-onload/" class="external">studies what happens</a> when an onload event handler is added to a page in a script that&#8217;s called onload. And before you say this is a weird use case, third-party scripts (ads!) do this. And it impacts performance negatively.</li>
320
+
321
+ <li>Due to the recent addition of touch events to IE11, Jacob Rossi <a href="http://blogs.msdn.com/b/ie/archive/2014/09/05/making-the-web-just-work-with-any-input.aspx" class="external">studies</a> how the three series of events (mouse, touch, and pointer) can cooperate, and where their strong and weak points are.</li>
322
+
323
+ <li>You&#8217;ve probably seen this: Yoav Weiss <a href="https://dev.opera.com/articles/native-responsive-images/" class="external">discusses</a> the history and current state of affairs in responsive images.</li>
324
+
325
+ <li>Christopher Aue <a href="http://christopheraue.net/2014/03/05/vertical-align/" class="external">demystifies</a> <code>vertical-align</code>. And yes, this is complicated.</li>
326
+
327
+ <li>Max Firtman <a href="http://www.mobilexweb.com/blog/safari-ios8-iphone6-web-developers-designers" class="external">takes a good look</a> at iOS8 and tells us what changed, what stayed the same, and what broke. The most important one is of course the fake DPR of 3 on the iPhone 6+.</li>
328
+
329
+ <li>In Chromium 37 the event coordinates of touch events <a href="http://updates.html5rocks.com/2014/09/Precision-Touch-for-Precise-Gestures" class="external">are now floating-point</a> instead of integers. This change may make sense, as explained on the page, though only with a DPR higher than 1.</li>
330
+
331
+ <li>Older, but still very interesting: John Gruber&#8217;s <a href="http://daringfireball.net/2014/08/larger_iphone_display_conjecture" class="external">conjectures on the iPhone 6 sizes</a>. Meanwhile we know the answer, but this article was an eye-opener for me. In particular, it turns out that native iOS development has a concept called <em>points</em>, and if you calculate the number of points that fit on an iOS screen you arrive at exactly the ideal viewport. Thus, native and web are more alike than I thought.<br>
332
+ John&#8217;s iPhone 6+ measurements were off, because he didn&#8217;t anticipate Apple shrinking the display by 13%. Despite that, it&#8217;s a great bit of detective work.</li>
333
+
334
+ <li>Freddie DeBoer <a href="http://dish.andrewsullivan.com/2014/08/23/the-internet-is-neither-open-nor-free/" class="external">takes exception</a> to the idea that
335
+ <blockquote>
336
+ <p>the internet as this open space where only talent matters and where everyone has a chance to impact the discussion</p>
337
+ </blockquote>
338
+ Commenters are the bane of civil discussion. That&#8217;s a sad truth bloggers found out about a while ago, but the myth of comments being good on principle should be laid to rest.</li>
339
+
340
+ <li>Hong Kong protesters, knowing that internet and mobile networks are controlled by the state and may be closed down at any moment, <a href="http://readwrite.com/2014/09/29/firechat-hong-kong-protests" class="external">opt for</a> another way of staying in touch. Essentially, every phone becomes a Bluetooth node, passing on messages until they reach the intended recipient. Due to this decntralized nature, the network is not able to pass private messages: each contributor could read each message that passes through his phone.</li>
341
+
342
+ <li>A word from our sponsors: Looking for a conference dedicated to web <strong>design</strong>? Look no further than <a href="http://dsgnday.nl" class="external">dsgnday</a>; 11th of November, Amsterdam.</li>
343
+
344
+
345
+ </ul>
346
+ ]]>
347
+ </content>
348
+ </entry>
349
+ <entry>
350
+ <title>The ninth Chromium: Xiaomi</title>
351
+ <link rel="alternate" type="text/html" href="http://www.quirksmode.org/blog/archives/2014/10/the_ninth_chrom.html" />
352
+ <modified>2014-10-02T12:40:24Z</modified>
353
+ <issued>2014-10-02T12:26:27Z</issued>
354
+ <id>tag:www.quirksmode.org,2014:/blog//1.2440</id>
355
+ <created>2014-10-02T12:26:27Z</created>
356
+ <summary type="text/plain"><p>This week I finally gathered the courage to run the media query test suite I wrote over a year ago in the latest crop of mobile browsers. The results are moderately interesting, especially when it comes to Chromium-based browsers. I...</p></summary>
357
+ <author>
358
+ <name>ppk</name>
359
+ <url>http://www.quirksmode.org/</url>
360
+ <email>ppk@xs4all.nl</email>
361
+ </author>
362
+ <dc:subject>Chrome</dc:subject>
363
+ <content type="text/html" mode="escaped" xml:lang="en" xml:base="http://www.quirksmode.org/blog/">
364
+ <![CDATA[<p>This week I finally gathered the courage to run the <a href="/css/mediaqueries/mobile.html">media query</a> test suite I wrote over a year ago in the latest crop of mobile browsers. The results are moderately interesting, especially when it comes to Chromium-based browsers. I discovered a new one: Xiaomi Chromium. It&#8217;s the ninth I identified, and the first one I had to work really hard on in order to get a version number.</p>
365
+ ]]>
366
+ <![CDATA[<p>As I have been saying for ages, and <a href="/blog/archives/2014/09/25_of_mobile_ch.html">found some evidence for</a> last week, a browser that identifies itself as Chrome isn&#8217;t necessarily Google Chrome. However, what I was not prepared for is finding a Chromium-based browser that does <em>not</em> identify itself as Chrome. And that&#8217;s exactly what happened.</p>
367
+
368
+ <p>While running the Android WebKit tests I noticed that the one on the Xiaomi M2 behaved quite differently from the rest. I started to get suspicions, which bloomed into certainty when it turned out it supports the <a href="/css/mediaqueries/features.html">pointer media query</a>, something only Chromium browsers on Android do. (No, desktop Chromes don&#8217;t.) I concluded the Xiaomi default browser is a Chromium, and not an Android WebKit.</p>
369
+
370
+ <h3>#9</h3>
371
+
372
+ <p>It&#8217;s the ninth Chromium I know of, so it&#8217;s time to make a list:</p>
373
+
374
+ <ol>
375
+ <li>Google Chrome; Chromium 37; desktop and mobile. Tested.</li>
376
+ <li>Opera; Chromium 37; desktop and mobile. Tested.</li>
377
+ <li>Yandex; Chromium 36; desktop. Tested.</li>
378
+ <li>Xiaomi; Chromium 34 or 35; mobile. Tested.</li>
379
+ <li>Cyanogen; Chromium 33; mobile. Tested.</li>
380
+ <li>Puffin; Chromium 30; mobile. Tested.</li>
381
+ <li>Samsung; Chromium 28; mobile. Tested.</li>
382
+ <li>Amazon Silk; unknown version; tablet. Not tested.</li>
383
+ <li>Nokia X; unknown version; mobile. Not tested.</li>
384
+ </ol>
385
+
386
+ <p>I think there are a few more desktop browsers that run Chromium (Maxthon, for instance), but I don&#8217;t follow them, so I&#8217;m not sure. The mobile/tablet list is complete, as far as I know.</p>
387
+
388
+ <p>And no, Chrome on iOS is not on the list. It doesn&#8217;t use Chromium for a rendering engine, but the Apple WebView. That&#8217;s because Apple does not allow anyone to install rendering engines on iOS.</p>
389
+
390
+ <h3>Detective work</h3>
391
+
392
+ <p>The problem with the Xiaomi Chromium that it doesn&#8217;t identify itself as such. Its UA string is the following, and note that the keyword <code>Chrome</code> is absent:</p>
393
+
394
+ <pre>
395
+ Mozilla/5.0 (Linux; U; Android 4.1.1; en-us; MI 2 Build/JRO03L)
396
+ AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0
397
+ Mobile Safari/537.36 XiaoMi/MiuiBrowser/2.0.1
398
+ </pre>
399
+
400
+ <p>The absence of <code>Chrome</code> means that every single browser detect out there will misidentify it. It also means I don&#8217;t know which Chromium version it is.</p>
401
+
402
+ <p>Fortunately there are compatibility patterns that give a clue as to its version. For ages I tested <a href="/css/mediaqueries/animation.html">four media queries</a> that were <a href="http://trac.webkit.org/export/38760/trunk/WebKitSite/specs/MediaQueriesExtensions.html" class="external">created by Apple</a> in 2008 and thus found their way into WebKit: <code>-webkit-animation</code>, <code>-webkit-transform-2d</code>, <code>-webkit-transform-3d</code>, and <code>-webkit-transition</code>. I thought they would become important. They didn&#8217;t, to the point where Chromium is in the process of removing them.</p>
403
+
404
+ <p>Fortunately this process is slow, which is why the four media queries can serve as a tracer for Chromium versions. Chromium 33 supported all of them, while Chrome 37 only supports <code>-webkit-transform-3d</code>. (Why? Apparently because it&#8217;s <a href="https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/lYZC-Xqf_Gw/D6Or7mZHwr4J" class="external">widely used</a> (see first comment).)</p>
405
+
406
+ <p>The Xiaomi Chromium does not support <code>transition</code>, but it supports the other three. So it would seem Xiaomi Chromium falls somewhere between 33 and 37.</p>
407
+
408
+ <p>Can we pinpoint the version further? It turns out we have one more clue. The Yandex 14 browser, which uses Chromium 35, has exactly the same compatibility pattern as Xiaomi: no <code>transition</code>, but the other three are supported.</p>
409
+
410
+ <p>Then I got <em>really</em> lucky. After writing the previous paragraph I decided to see if there&#8217;s an update for Yandex. Turns out there is, and it updates to Chrome 36, which supports only <code>transform-3d</code>.</p>
411
+
412
+ <p>Thus, we have now ascertained that the Xiaomi Chromium version is higher than 33 and lower than 36. 34 or 35, in other words.</p>
413
+
414
+ <h3>Google, please help</h3>
415
+
416
+ <p>This kind of detective work is fun if you have to do it occasionally, and if a vital tracer such as these four media queries is available. I wouldn&#8217;t like to do this for every unidentified Chromium I encounter, though.</p>
417
+
418
+ <p>That&#8217;s why I&#8217;d like to ask Google to help me out a bit. I would need one of the following two, and preferably both:</p>
419
+
420
+ <ol>
421
+ <li>An archive of old Chrome on Android versions, with automatic updates disabled. I could use them to run my own comparisons.</li>
422
+ <li>A log file of changes from version to version. High-level only; it just needs to consist of features added and removed, such as the media queries I talked about earlier.</li>
423
+ </ol>
424
+
425
+ <p>This would greatly help me, and other web developers as well, I suppose, to make sense of the increasingly complicated Chromium world.</p>
426
+ ]]>
427
+ </content>
428
+ </entry>
429
+ <entry>
430
+ <title>25% of mobile Chrome users use Samsung Chrome</title>
431
+ <link rel="alternate" type="text/html" href="http://www.quirksmode.org/blog/archives/2014/09/25_of_mobile_ch.html" />
432
+ <modified>2014-09-26T10:27:43Z</modified>
433
+ <issued>2014-09-25T11:18:47Z</issued>
434
+ <id>tag:www.quirksmode.org,2014:/blog//1.2439</id>
435
+ <created>2014-09-25T11:18:47Z</created>
436
+ <summary type="text/plain"><p>For at least a year now I&amp;#8217;ve held to the theory that the huge uptake in Chrome we&amp;#8217;re seeing on the mobile web is mostly due to Samsung using its own version (based on Chromium 28) in its high-end smart...</p></summary>
437
+ <author>
438
+ <name>ppk</name>
439
+ <url>http://www.quirksmode.org/</url>
440
+ <email>ppk@xs4all.nl</email>
441
+ </author>
442
+ <dc:subject>Market share</dc:subject>
443
+ <content type="text/html" mode="escaped" xml:lang="en" xml:base="http://www.quirksmode.org/blog/">
444
+ <![CDATA[<p>For at least a year now I&#8217;ve held to the theory that the huge uptake in Chrome we&#8217;re seeing on the mobile web is mostly due to Samsung using its own version (based on Chromium 28) in its high-end smart devices from the Galaxy S4 on.</p>
445
+
446
+ <p>Yesterday <a href="http://krijnhoetmer.nl" class="external">Krijn</a> started tweeting about mobile stats he had, and it turned out he was willing to share. He gave me data on about 100K mobile and tablet hits in Q2 on a project of his he&#8217;s worked on for <del>ages</del> five years. I took the data gratefully and created a <a href="/analytics/analytics.html">table</a>.</p>
447
+
448
+ <p>Conclusion: Of Chrome users, 25% uses Samsung Chrome &#8212; this amounts to about 5% of all mobile visits to the site. On the one hand this proves that Samsung Chrome is a Thing &#8212; on the other hand I had expected a much higher percentage. So my theory isn&#8217;t right, but Samsung Chrome is still important.</p>
449
+ ]]>
450
+ <![CDATA[<p>Samsung Chrome is not exactly the same as Google Chrome. It&#8217;s still at version 28, and there are some other differences. For instance, it supports <a href="/css/cascading/mobile.html">scoped styles</a>, something Google Chrome never did without a flag. I feel we should take more care to test specifically on Samsung Chrome and separate it from Google Chrome. So buy that Galaxy S4 or S5 and start working.</p>
451
+
452
+ <h3>Source</h3>
453
+
454
+ <p>The statistics come from the <a href="http://royal.nl" class="external">Royal</a> sites, which are targeted at a Dutch audience looking for holidays, primarily on the Mediterranean coast, but also elsewhere. The first surprise was that about 45% of total hits came from mobile devices or tablets.</p>
455
+
456
+ <p>Snapshot: person on couch wanting to book holiday, too lazy to get up to computer, uses tablet or mobile device within reach instead. Still, 45% remains a lot.</p>
457
+
458
+ <p>More than 50% of these mobile/tablet hits come from Apple devices. Almost all the rest comes from various Androids, and it&#8217;s here that the stats start to become truly interesting.</p>
459
+
460
+ <h3>Result</h3>
461
+
462
+ <p>You can browse the full analysis <a href="/analytics/analytics.html">here</a> and compare it to <a href="http://gs.statcounter.com/#mobile+tablet-browser-NL-monthly-201403-201406-bar" class="external">StatCounter&#8217;s analysis</a> of Q2.</p>
463
+
464
+ <p>This was the general browser make-up:</p>
465
+
466
+ <table class="browserStats">
467
+ <caption>Q2 mobile/tablet browsers to the Royal sites compared to StatCounter</caption>
468
+ <tr>
469
+ <th>Browser</th>
470
+ <th>Percentage ROYAL</th>
471
+ <th>Percentage STATCOUNTER</th>
472
+ </tr>
473
+ <tr>
474
+ <td>Safari</td>
475
+ <td>59%</td>
476
+ <td>54%</td>
477
+ </tr>
478
+ <tr>
479
+ <td>Chrome</td>
480
+ <td>20%</td>
481
+ <td>20%</td>
482
+ </tr>
483
+ <tr>
484
+ <td>Android WebKit</td>
485
+ <td>19%</td>
486
+ <td>24%</td>
487
+ </tr>
488
+ <tr>
489
+ <td>IE</td>
490
+ <td>1%</td>
491
+ <td>1%</td>
492
+ </tr>
493
+ <tr>
494
+ <td>Others</td>
495
+ <td>1%</td>
496
+ <td>1%</td>
497
+ </tr>
498
+ </table>
499
+
500
+ <p>That&#8217;s a pretty close match &#8212; there&#8217;s only a 5% difference that has gone from Android WebKit to Safari. It&#8217;s fun to theorise about affluent people (Apple!) booking more holidays than less affluent ones (old Androids!), but I&#8217;ll resist that lure.</p>
501
+
502
+ <p>However, where StatCounter gives you the bare browser numbers at best, I could dig deeper into the Royal stats. I focused on Chrome, since that browser is my biggest worry right now. So what about those 20% Chrome hits?</p>
503
+
504
+ <table class="browserStats" style="width: 100%">
505
+ <caption>Q2 mobile/tablet Chrome hits to the Royal sites</caption>
506
+ <tr>
507
+ <th>Chrome</th>
508
+ <th>Percentage</th>
509
+ <th>Notes</th>
510
+ </tr>
511
+ <tr>
512
+ <td>Chrome iOS</td>
513
+ <td>42%</td>
514
+ <td>12.5% of all hits from Apple devices</td>
515
+ </tr>
516
+ <tr>
517
+ <td>Google Chrome latest (34/35)</td>
518
+ <td>31%</td>
519
+ <td>Only 7% of this 31% (= about 2% of all Chrome hits) come from Google Nexus devices</td>
520
+ </tr>
521
+ <tr>
522
+ <td>Samsung Chrome 28</td>
523
+ <td>19%</td>
524
+ <td>Default browser on Galaxy S4 and up</td>
525
+ </tr>
526
+ <tr>
527
+ <td>Samsung Chrome 18</td>
528
+ <td>6%</td>
529
+ <td>Old default browser on Galaxy S4 and up</td>
530
+ </tr>
531
+ <tr>
532
+ <td>Google Chrome 33</td>
533
+ <td>1%</td>
534
+ <td rowspan="2">These people didn&#8217;t upgrade their Chrome</td>
535
+ </tr>
536
+ <tr>
537
+ <td>Other Chromes</td>
538
+ <td>1%</td>
539
+ </tr>
540
+ </table>
541
+
542
+ <p>Surprisingly, Chrome on iOS is the biggest Chrome. It accounts for 42% of Chrome hits, and 12.5% of Apple device hits. One in eight Apple device users uses Chrome, in other words. That&#8217;s WAY more than I expected.</p>
543
+
544
+ <p>Please remember that Chrome on iOS is NOT in fact Chrome. Apple doesn&#8217;t allow the installation of other rendering engines on iOS, so Chrome is forced to use the Apple WebView, which is essentially Safari with another JavaScript engine.</p>
545
+
546
+ <p>In the middle of Q2 Google Chrome was updated from 34 to 35, so I combine those two browsers as &#8220;Chrome latest.&#8221; These users use a downloaded Chrome (except the slight number of users actually surfing with a Google Nexus, where Google Chrome is the default browser). Again, this is more than I expected. I thought consumers don&#8217;t download browsers &#8212; it seems I&#8217;m not entirely right here.</p>
547
+
548
+ <p>Then comes 25% of Chrome users actually using Samsung&#8217;s Chrome, which was first at 18 and then got upgraded to 28. This is the hidden group that no web developer except for me pays attention to.</p>
549
+
550
+ <p>Finally, 2% other Chromes. These are mostly people who didn&#8217;t update their browsers, I guess.</p>
551
+
552
+ <h3>Methodology</h3>
553
+
554
+ <p>The stats were gathered by Google Analytics. Krijn gave me CSV files of the Q2 devices and browsers. Unfortunately these two are separate &#8212; despite more than fifteen years of experience with web stats, the first package that actually cross-references browsers with devices or OSs still has to be written. (I mean, it&#8217;s not THAT difficult to calculate that 23% of Android users use Chrome, and show that fact clearly in the reports, is it? But this seems to be a curious blind spot of analytics package creators.)</p>
555
+
556
+ <p>I took the devices file, which also includes a browser version number &#8212; but not a name. (Why not? I have no clue. Blind spot etc.) I removed all devices that had less than 10 hits, because I had to manually go through the file and this removed about 75% of the lines without affecting the overall stats too much. I then removed a lot of extra stuff I didn&#8217;t need, and was left with lines like this:</p>
557
+
558
+ <pre>
559
+ Samsung GT-P7310 Galaxy Tab 8.9,4.0,47
560
+ </pre>
561
+
562
+ <p>The first item is clearly a device. The second is the browser version number, the third the number of hits. My job was to match browser version numbers to browser names, and fortunately that was pretty simple most of the time. The <code>4.0</code> above clearly refers to Android WebKit; Chrome has much more complicated version numbers like <code>35.0.1916.141</code>. I also added a device type: phone or tablet. So I manually expanded the line above to the following (and yes, I had to do this for every single line &#8212; more than 300 in total. I&#8217;m glad I removed the long tail.)</p>
563
+
564
+ <pre>
565
+ Samsung GT-P7310 Galaxy Tab 8.9,4.0,47,Android WebKit,tablet
566
+ </pre>
567
+
568
+ <p>In the <a href="/analytics/analytics.html">table</a> I ignored device types for now; I may delve into those at a later date, but right now it wasn&#8217;t my main research question.</p>
569
+
570
+ <p>If you&#8217;re interested, the sanitized data is <a href="/analytics/data.js">here</a>.</p>
571
+
572
+ <p>Granted, 100K hits is not really a lot, and I&#8217;d love to repeat the experiment with a much larger set of data. On the other hand, that much larger data set just isn&#8217;t there, and any data is better than no data.</p>
573
+
574
+
575
+ <p><strong>Update</strong>: Peter Gasston <a href="https://twitter.com/stopsatgreen/status/515113197050036224" class="external">tweeted</a> he&#8217;s seeing roughly similar Samsung Chrome numbers: 32% of mobile Chrome users. Chrome iOS at 17% &#8212; distinctly lower than in the data I went through.</p>
576
+
577
+ <p><strong>Update to update</strong>: I checked Peter's numbers myself, and it turns out only 10% of his Chrome mobile visitors use Samsung Chrome. Also, it seems Google Analytics can't distinguish between Chrome and Android WebKit.</p>
578
+ ]]>
579
+ </content>
580
+ </entry>
581
+ <entry>
582
+ <title>dsgnday announces Peter Boersma</title>
583
+ <link rel="alternate" type="text/html" href="http://www.quirksmode.org/blog/archives/2014/09/dsgnday_announc.html" />
584
+ <modified>2014-09-23T10:57:52Z</modified>
585
+ <issued>2014-09-23T10:56:50Z</issued>
586
+ <id>tag:www.quirksmode.org,2014:/blog//1.2438</id>
587
+ <created>2014-09-23T10:56:50Z</created>
588
+ <summary type="text/plain"><p>On 11th of November we&amp;#8217;ll organise the first dsgnday in Amsterdam; a one-day conference for graphic and UX designers working on the web. Today we announce the last speaker....</p></summary>
589
+ <author>
590
+ <name>ppk</name>
591
+ <url>http://www.quirksmode.org/</url>
592
+ <email>ppk@xs4all.nl</email>
593
+ </author>
594
+ <dc:subject>dsgnday</dc:subject>
595
+ <content type="text/html" mode="escaped" xml:lang="en" xml:base="http://www.quirksmode.org/blog/">
596
+ <![CDATA[<p>On 11th of November we&#8217;ll organise the first <a href="http://dsgnday.nl" class="external">dsgnday</a> in Amsterdam; a one-day conference for graphic and UX designers working on the web. Today we announce the last speaker.</p>
597
+ ]]>
598
+ <![CDATA[<p>A few weeks back <a href="/blog/archives/2014/09/dsgnday.html">we announced</a> seven out of eight speakers. We still owed you an eighth one, and today we're happy to announce that <a href="http://peterboersma.com" class="external">Peter Boersma</a> has agreed to speak.</p>
599
+
600
+ <p>While working for increasingly international clients, Peter still managed to become a fixture of the Amsterdam UX scene, organising and hosting several meet-ups and conferences.</p>
601
+
602
+ <p>At dsgnday he's going to talk about his passion: expanding your influence and improving your design process. UX covers more of the design process than just creating wireframes or code. It should influence and inform all details of the site, and your job isn't done when a wireframe is accepted and implemented.</p>
603
+
604
+ <p>With the addition of Peter our <a href="http://dsgnday.nl/programme" class="external">line-up</a> is complete.
605
+
606
+ <ul>
607
+ <li>Mark Boulton, thoughts from his notebook
608
+ <li>Bonnie Colville-Hyde, user experience comics
609
+ <li>Stephen Hay, designing in the browser
610
+ <li>Val Head, designing meaningful animations
611
+ <li>Laura Kalbag, accessibility by design
612
+ <li>Peter Boersma, expanding your influence
613
+ <li>Leisa Reichelt, the strategy is delivery
614
+ <li>Mike Rohde, sketchnote mini workshop
615
+ </ul>
616
+
617
+
618
+ <p><a href="http://dsgnday.nl/tickets" class="external">Tickets</a> are € 275, and coffee, lunch, and drinks afterwards are included.</p>
619
+ ]]>
620
+ </content>
621
+ </entry>
622
+ <entry>
623
+ <title>Browser stats for Q1 and Q2</title>
624
+ <link rel="alternate" type="text/html" href="http://www.quirksmode.org/blog/archives/2014/09/browser_stats_f_8.html" />
625
+ <modified>2014-09-17T12:31:31Z</modified>
626
+ <issued>2014-09-17T12:30:50Z</issued>
627
+ <id>tag:www.quirksmode.org,2014:/blog//1.2437</id>
628
+ <created>2014-09-17T12:30:50Z</created>
629
+ <summary type="text/plain"><p>It&amp;#8217;s time for some browser stats, as always courtesy of StatCounter....</p></summary>
630
+ <author>
631
+ <name>ppk</name>
632
+ <url>http://www.quirksmode.org/</url>
633
+ <email>ppk@xs4all.nl</email>
634
+ </author>
635
+ <dc:subject>Market share</dc:subject>
636
+ <content type="text/html" mode="escaped" xml:lang="en" xml:base="http://www.quirksmode.org/blog/">
637
+ <![CDATA[<p>It&#8217;s time for some browser stats, as always courtesy of <a href="http://gs.statcounter.com/" class="external">StatCounter</a>.</p>
638
+ ]]>
639
+ <![CDATA[<p>I didn&#8217;t report the Q1 stats before because I was too busy with <a href="http://www.smashingmagazine.com/2014/04/29/meet-mobile-web-handbook-new-smashing-book-peter-paul-koch/" class="external">the book</a>. So here are the Qa and Q2 stats in one easy-to-digest package.</p>
640
+
641
+ <p>Headline: Chrome. Q1 and Q2 were Chrome&#8217;s quarters. The browser grew on desktop, mobile, and tablet, though the desktop growth was minimal.</p>
642
+
643
+ <h3>Mobile</h3>
644
+
645
+ <p>On mobile Chrome&#8217;s share tripled from January to June &#8212; from 6 to 18% of the total mobile browser market. I&#8217;m not sure what fueled this huge growth. (And don&#8217;t tell me it&#8217;s consumers downloading it of their own free will &#8212; I don&#8217;t believe that.)</p>
646
+
647
+ <p>First of all the usual caveat (though nobody ever listens to me): I suspect that the majority of these Chrome hits are not Google Chrome but Samsung Chrome &#8212; the default browser of the Galaxy S4 and newer high-end models that currently stands at version 28, instead of Google Chrome&#8217;s 37.</p>
648
+
649
+ <p>So one explanation of Chrome&#8217;s jump is Samsung selling a lot of high-end devices with Samsung Chrome 28 as their default browser to people who actually surf. Absent actual data this is the explanation I&#8217;m going to believe.</p>
650
+
651
+ <p>Chrome is still smaller than Android WebKit, but for the first time I&#8217;m starting to see a trend that Chrome will catch up pretty soon. By the end of the year? Possibly. Still, that won&#8217;t mean that Android WebKit will disappear, so you should continue to acquire those Android test devices and test in all Android WebKits you can lay your hands on.</p>
652
+
653
+ <p>Also interesting is where Chrome&#8217;s growth comes from. Whatever else is happening, Chrome is <em>not</em> replacing Android WebKit. Instead, what these numbers seem to suggest is people switching over from older phones, that run proxy browsers such as Opera Mini, Nokia Xpress, or UC Mini, to newer, higher-end Samsung devices. Android is eating the non-smartphone world, in other words. Horace Dediu <a href="http://www.asymco.com/2014/03/18/invaluable/" class="external">has been saying this forever</a>, and now we found some browser data that could correlate with his theory.</p>
654
+
655
+ <table class="browserStats">
656
+ <caption>Global mobile browser stats, quarterly</caption>
657
+ <tr>
658
+ <th>Browser</th>
659
+ <th>Q2 2014</th>
660
+ <th class="narrow">ch</th>
661
+ <th>Q1 2014</th>
662
+ <th class="narrow">ch</th>
663
+ <th>Q4 2013</th>
664
+ <th class="narrow">ch</th>
665
+ <th>Q3 2013</th>
666
+ <th class="narrow">ch</th>
667
+ <th>Q2 2013</th>
668
+ </tr>
669
+ <tr>
670
+ <td>Android</td>
671
+ <td>25%</td>
672
+ <td>-1</td>
673
+ <td>26%</td>
674
+ <td>0</td>
675
+ <td>26%</td>
676
+ <td>-2</td>
677
+ <td>28%</td>
678
+ <td>-2</td>
679
+ <td>30%</td>
680
+ </tr>
681
+ <tr>
682
+ <td>Safari</td>
683
+ <td>23%</td>
684
+ <td>+1</td>
685
+ <td>22%</td>
686
+ <td>+1</td>
687
+ <td>21%</td>
688
+ <td>-2</td>
689
+ <td>23%</td>
690
+ <td>-3</td>
691
+ <td>26%</td>
692
+ </tr>
693
+ <tr>
694
+ <td>Chrome</td>
695
+ <td>18%</td>
696
+ <td>+7</td>
697
+ <td>11%</td>
698
+ <td>+5</td>
699
+ <td>6%</td>
700
+ <td>+2</td>
701
+ <td>4%</td>
702
+ <td>+1</td>
703
+ <td>3%</td>
704
+ </tr>
705
+ <tr>
706
+ <td>Opera</td>
707
+ <td>12%</td>
708
+ <td>-1</td>
709
+ <td>13%</td>
710
+ <td>-6</td>
711
+ <td>19%</td>
712
+ <td>+3</td>
713
+ <td>16%</td>
714
+ <td>0</td>
715
+ <td>16%</td>
716
+ </tr>
717
+ <tr>
718
+ <td>UC</td>
719
+ <td>10%</td>
720
+ <td>-1</td>
721
+ <td>11%</td>
722
+ <td>0</td>
723
+ <td>11%</td>
724
+ <td>0</td>
725
+ <td>11%</td>
726
+ <td>+2</td>
727
+ <td>9%</td>
728
+ </tr>
729
+ <tr>
730
+ <td>Nokia</td>
731
+ <td>4%</td>
732
+ <td>-2</td>
733
+ <td>6%</td>
734
+ <td>-1</td>
735
+ <td>7%</td>
736
+ <td>0</td>
737
+ <td>7%</td>
738
+ <td>0</td>
739
+ <td>7%</td>
740
+ </tr>
741
+ <tr>
742
+ <td>BlackBerry</td>
743
+ <td>2%</td>
744
+ <td>0</td>
745
+ <td>2%</td>
746
+ <td>-1</td>
747
+ <td>3%</td>
748
+ <td>0</td>
749
+ <td>3%</td>
750
+ <td>0</td>
751
+ <td>3%</td>
752
+ </tr>
753
+ <tr>
754
+ <td>NetFront</td>
755
+ <td>2%</td>
756
+ <td>0</td>
757
+ <td>2%</td>
758
+ <td>0</td>
759
+ <td>2%</td>
760
+ <td>0</td>
761
+ <td>2%</td>
762
+ <td>0</td>
763
+ <td>2%</td>
764
+ </tr>
765
+ <tr>
766
+ <td>IE</td>
767
+ <td>2%</td>
768
+ <td>0</td>
769
+ <td>2%</td>
770
+ <td>0</td>
771
+ <td>2%</td>
772
+ <td>+1</td>
773
+ <td>1%</td>
774
+ <td>0</td>
775
+ <td>1%</td>
776
+ </tr>
777
+ <tr>
778
+ <td>Other</td>
779
+ <td>2%</td>
780
+ <td>-3</td>
781
+ <td>5%</td>
782
+ <td>+2</td>
783
+ <td>3%</td>
784
+ <td>-2</td>
785
+ <td>5%</td>
786
+ <td>+2</td>
787
+ <td>3%</td>
788
+ </tr>
789
+ <tr class="separator">
790
+ <td>Volatility</td>
791
+ <td></td>
792
+ <td>8%</td>
793
+ <td></td>
794
+ <td>8%</td>
795
+ <td></td>
796
+ <td>6%</td>
797
+ <td></td>
798
+ <td>5%</td>
799
+ <td></td>
800
+ </tr>
801
+ <tr>
802
+ <td>Mobile</td>
803
+ <td>25%</td>
804
+ <td>+2</td>
805
+ <td>23%</td>
806
+ <td>+3</td>
807
+ <td>20%</td>
808
+ <td>+3</td>
809
+ <td>17%</td>
810
+ <td>+2</td>
811
+ <td>15%</td>
812
+ </tr>
813
+
814
+ </table>
815
+
816
+ <h3>Desktop</h3>
817
+
818
+ <p>On desktop Chrome&#8217;s growth is much less pronounced, but it&#8217;s there, and IE bears the cost. If this trend continues Chrome will be the majority desktop browser by the end of the year.</p>
819
+
820
+ <p>Also, by the end of the year less than two-thirds of global hits on websites will come from desktop browsers. Most of the rest will be mobile browsers. Still need arguments to convince your boss mobile is important? Just show him (or her, I suppose) the numbers.</p>
821
+
822
+ <table class="browserStats">
823
+ <caption>Global desktop browser stats, quarterly</caption>
824
+ <tr>
825
+ <th>Browser</th>
826
+ <th>Q2 2014</th>
827
+ <th class="narrow">ch</th>
828
+ <th>Q1 2014</th>
829
+ <th class="narrow">ch</th>
830
+ <th>Q4 2013</th>
831
+ <th title="Change" class="narrow">ch</th>
832
+ <th>Q3 2013</th>
833
+ <th title="Change" class="narrow">ch</th>
834
+ <th>Q2 2013</th>
835
+ </tr>
836
+ <tr>
837
+ <td>Chrome</td>
838
+ <td>48%</td>
839
+ <td>+1</td>
840
+ <td>47%</td>
841
+ <td>+3</td>
842
+ <td>44%</td>
843
+ <td>0</td>
844
+ <td>44%</td>
845
+ <td>+1</td>
846
+ <td>43%</td>
847
+ </tr>
848
+ <tr>
849
+ <td>IE</td>
850
+ <td>23%</td>
851
+ <td>-2</td>
852
+ <td>25%</td>
853
+ <td>-3</td>
854
+ <td>28%</td>
855
+ <td>0</td>
856
+ <td>28%</td>
857
+ <td>-1</td>
858
+ <td>29%</td>
859
+ </tr>
860
+ <tr>
861
+ <td>Firefox</td>
862
+ <td>20%</td>
863
+ <td>0</td>
864
+ <td>20%</td>
865
+ <td>0</td>
866
+ <td>20%</td>
867
+ <td>0</td>
868
+ <td>20%</td>
869
+ <td>-1</td>
870
+ <td>21%</td>
871
+ </tr>
872
+ <tr>
873
+ <td>Safari</td>
874
+ <td>5%</td>
875
+ <td>0</td>
876
+ <td>5%</td>
877
+ <td>0</td>
878
+ <td>5%</td>
879
+ <td>0</td>
880
+ <td>5%</td>
881
+ <td>0</td>
882
+ <td>5%</td>
883
+ </tr>
884
+ <tr>
885
+ <td>Opera</td>
886
+ <td>1%</td>
887
+ <td>0</td>
888
+ <td>1%</td>
889
+ <td>0</td>
890
+ <td>1%</td>
891
+ <td>0</td>
892
+ <td>1%</td>
893
+ <td>0</td>
894
+ <td>1%</td>
895
+ </tr>
896
+ <tr>
897
+ <td>Others</td>
898
+ <td>3%</td>
899
+ <td>+1</td>
900
+ <td>2%</td>
901
+ <td>0</td>
902
+ <td>2%</td>
903
+ <td>0</td>
904
+ <td>2%</td>
905
+ <td>+1</td>
906
+ <td>1%</td>
907
+ </tr>
908
+ <tr class="separator">
909
+ <td>Volatility</td>
910
+ <td></td>
911
+ <td>2%</td>
912
+ <td></td>
913
+ <td>3%</td>
914
+ <td></td>
915
+ <td>0</td>
916
+ <td></td>
917
+ <td>2%</td>
918
+ <td></td>
919
+ </tr>
920
+ <tr>
921
+ <td>Desktop</td>
922
+ <td>69%</td>
923
+ <td>-2</td>
924
+ <td>71%</td>
925
+ <td>-4</td>
926
+ <td>75%</td>
927
+ <td>-3</td>
928
+ <td>78%</td>
929
+ <td>-3</td>
930
+ <td>81%</td>
931
+ </tr>
932
+ </table>
933
+
934
+ <h3>Tablet</h3>
935
+
936
+ <p>And even on tablets Chrome is growing. I&#8217;m not sure if Samsung Chrome is deployed on tablets as well (I don&#8217;t keep close track of the Android tablet market). Here, too, I see Chrome overtaking Android WebKit before the end of the year.</p>
937
+
938
+ <p>Still, Safari has two-thirds of the tablet browsing market, so any other browser is a footnote.</p>
939
+
940
+ <table class="browserStats">
941
+ <caption>Global tablet browser stats, quarterly</caption>
942
+ <tr>
943
+ <th>Browser</th>
944
+ <th>Q2 2014</th>
945
+ <th class="narrow">ch</th>
946
+ <th>Q1 2014</th>
947
+ <th class="narrow">ch</th>
948
+ <th>Q4 2013</th>
949
+ <th title="Change" class="narrow">ch</th>
950
+ <th>Q3 2013</th>
951
+ <th title="Change" class="narrow">ch</th>
952
+ <th>Q2 2013</th>
953
+ </tr>
954
+ <tr>
955
+ <td>Safari</td>
956
+ <td>67%</td>
957
+ <td>-1</td>
958
+ <td>68%</td>
959
+ <td>-1</td>
960
+ <td>69%</td>
961
+ <td>-1</td>
962
+ <td>70%</td>
963
+ <td>-2</td>
964
+ <td>72%</td>
965
+ </tr>
966
+ <tr>
967
+ <td>Android</td>
968
+ <td>15%</td>
969
+ <td>-1</td>
970
+ <td>16%</td>
971
+ <td>0</td>
972
+ <td>16%</td>
973
+ <td>0</td>
974
+ <td>16%</td>
975
+ <td>+1</td>
976
+ <td>15%</td>
977
+ </tr>
978
+ <tr>
979
+ <td>Chrome</td>
980
+ <td>12%</td>
981
+ <td>+3</td>
982
+ <td>9%</td>
983
+ <td>+2</td>
984
+ <td>7%</td>
985
+ <td>0</td>
986
+ <td>7%</td>
987
+ <td>0</td>
988
+ <td>7%</td>
989
+ </tr>
990
+ <tr>
991
+ <td>Silk</td>
992
+ <td>3%</td>
993
+ <td>0</td>
994
+ <td>3%</td>
995
+ <td>0</td>
996
+ <td>3%</td>
997
+ <td>0</td>
998
+ <td>3%</td>
999
+ <td>0</td>
1000
+ <td>3%</td>
1001
+ </tr>
1002
+ <tr>
1003
+ <td>Opera</td>
1004
+ <td>1%</td>
1005
+ <td>0</td>
1006
+ <td>1%</td>
1007
+ <td>0</td>
1008
+ <td>1%</td>
1009
+ <td>0</td>
1010
+ <td>1%</td>
1011
+ <td>0</td>
1012
+ <td>1%</td>
1013
+ </tr>
1014
+ <tr>
1015
+ <td>Firefox</td>
1016
+ <td>1%</td>
1017
+ <td>0</td>
1018
+ <td>1%</td>
1019
+ <td>0</td>
1020
+ <td>1%</td>
1021
+ <td>0</td>
1022
+ <td>1%</td>
1023
+ <td>0</td>
1024
+ <td>1%</td>
1025
+ </tr>
1026
+ <tr>
1027
+ <td>Others</td>
1028
+ <td>1%</td>
1029
+ <td>-1</td>
1030
+ <td>2%</td>
1031
+ <td>-1</td>
1032
+ <td>3%</td>
1033
+ <td>+1</td>
1034
+ <td>2%</td>
1035
+ <td>+1</td>
1036
+ <td>1%</td>
1037
+ </tr>
1038
+ <tr class="separator">
1039
+ <td>Volatility</td>
1040
+ <td></td>
1041
+ <td>3%</td>
1042
+ <td></td>
1043
+ <td>2%</td>
1044
+ <td></td>
1045
+ <td>1%</td>
1046
+ <td></td>
1047
+ <td>2%</td>
1048
+ <td></td>
1049
+ </tr>
1050
+ <tr>
1051
+ <td>Tablet</td>
1052
+ <td>6%</td>
1053
+ <td>0</td>
1054
+ <td>6%</td>
1055
+ <td>+1</td>
1056
+ <td>5%</td>
1057
+ <td>0</td>
1058
+ <td>5%</td>
1059
+ <td>+1</td>
1060
+ <td>4%</td>
1061
+ </tr>
1062
+ </table>
1063
+ ]]>
1064
+ </content>
1065
+ </entry>
1066
+ <entry>
1067
+ <title>DOM HTML table updated</title>
1068
+ <link rel="alternate" type="text/html" href="http://www.quirksmode.org/blog/archives/2014/09/dom_html_table.html" />
1069
+ <modified>2014-09-16T11:01:52Z</modified>
1070
+ <issued>2014-09-16T10:44:34Z</issued>
1071
+ <id>tag:www.quirksmode.org,2014:/blog//1.2436</id>
1072
+ <created>2014-09-16T10:44:34Z</created>
1073
+ <summary type="text/plain"><p>And here&amp;#8217;s the first table updated according to the new IE8-and-up rule. It&amp;#8217;s past time I updated the DOM Compatibility tables, even though they&amp;#8217;re not as exciting as they were ten years ago....</p></summary>
1074
+ <author>
1075
+ <name>ppk</name>
1076
+ <url>http://www.quirksmode.org/</url>
1077
+ <email>ppk@xs4all.nl</email>
1078
+ </author>
1079
+ <dc:subject>Content</dc:subject>
1080
+ <content type="text/html" mode="escaped" xml:lang="en" xml:base="http://www.quirksmode.org/blog/">
1081
+ <![CDATA[<p>And <a href="/dom/html/">here&#8217;s the first table</a> updated according to the <a href="/blog/archives/2014/09/ie_survey_resul.html">new IE8-and-up rule</a>. It&#8217;s past time I updated the DOM Compatibility tables, even though they&#8217;re not as exciting as they were ten years ago.</p>
1082
+ ]]>
1083
+ <![CDATA[<p>These tables are mainly about <code>innerHTML</code> and friends, though they also detail some other properties of HTML elements, such as <code>classList</code> and <code>dataset</code>.</p>
1084
+
1085
+ <p>Unsurprisingly, all desktop browsers support nearly everything, with only Firefox holding out on not supporting <code>innerText</code> and <code>outerText</code> (though it does support <code>outerHTML</code> &#8212; go figure).</p>
1086
+
1087
+ <p>It turns out there are no less than three properties that say something about the page&#8217;s character set, and interesting slight browser incompatibilities. Did you know that, without you specifying UTF-8, IE and Firefox use Windows-1252 while Safari and the Blink browsers use ISO-8859-1? Now that you know, do you care? You always specify UTF-8 anyway, right? Be aware that in Safari, and only in Safari, it&#8217;s utf-8 instead of UTF-8.</p>
1088
+
1089
+ <p>Then there&#8217;s <code>document.activeElement</code>, which refers to the element the user is currently focusing on. That&#8217;s usually the BODY, but it could also be a form field or link. I tested it on buttons, links, and regular inputs, and only IE and Firefox support them on all three, though Firefox on Mac doesn&#8217;t do buttons (Windows and Linux do). Blink-based browsers don&#8217;t do links, and Safari does only regular inputs. Go figure.</p>
1090
+
1091
+ <p>And so on and so forth. Not the most exciting material, but the <a href="/dom/html/">DOM HTML table</a> now reflects the predilections of today&#8217;s desktop browsers.</p>
1092
+
1093
+ <p>I haven&#8217;t done the mobile tests yet; I&#8217;m slowly going through my device lab once again, and I am going to wait for iOS8 before embarking on actual tests.</p>
1094
+ ]]>
1095
+ </content>
1096
+ </entry>
1097
+
1098
+ </feed>