-
Notifications
You must be signed in to change notification settings - Fork 13
/
index.html
1215 lines (1214 loc) · 52.7 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html>
<html>
<head>
<title>
Use Cases and Requirements for Installable Web Apps
</title>
<meta charset='utf-8'>
<script src='//www.w3.org/Tools/respec/respec-w3c-common' async=""
class='remove'>
</script>
<script src="respecConfig.js" class='remove'>
</script>
</head>
<body>
<section id='abstract'>
<p>
This document provides an overview of how web applications have started
to be integrated into native application environments, and outlines the
use cases and requirements for a standard that could allow users to
"install" web applications. The use cases and requirements were
gathered by examining the landscape of proprietary solutions, and,
where possible, by gathering statistics about the prevalence and usage
patterns of particular solutions used in the wild.
</p>
<p>
Proprietary solutions that integrate web applications into the
underlying operating system have been used in the wild for a few years
now, so consolidation towards a standardized solution could potentially
benefit users, developers, and browser vendors.
</p>
</section>
<section id='sotd'>
<p>
This document is undergoing heavy revision and changing on an almost
daily basis. If you have any thoughts or comments about the content,
please either join the <a href=
"http://lists.w3.org/Archives/Public/public-web-mobile/">public-webmob
mailing list</a> or <a href=
"https://github.com/w3c-webmob/installable-webapps/issues">file a
bug</a> on GitHub. All contributions welcome.
</p>
</section>
<section>
<h2>
Introduction
</h2>
<p>
To launch native applications on either a desktop-class machine or a
mobile device, users are generally presented with icons and
corresponding labels that represent the applications installed on their
system. Having the icons of web applications appear amongst
applications that the user considers native (e.g., those on the home
screen of a device) gives the perception to users that a web
application has been "installed" - even if the processes that go into
actually "installing" a web application differ from those of a native
application.
</p>
<figure>
<img src="images/nativeapp_icons.jpg" alt=
"Various operating systems and their application icons.">
<figcaption>
Some application icons of Android 4.3, Windows Phone 7, and Mac OS
Mavericks.
</figcaption>
</figure>
<p>
At the time of writing, the web platform lacks a standardized means for
a web application to indicate that it can be "installed" and treated as
if it were an native application. As this document will show, the web
platform also lacks sufficient metadata for a Web application to be
successfully integrated into an underlying platform in the same way
native applications are (i.e., not just on the homescreen, but
integration into other contexts such as the task switcher, privacy
and security settings, etc.).
</p>
<p>
Because of this gap in the web platform, browser vendors, including
Google, Apple, Microsoft, and Mozilla, have implemented proprietary
solutions that allow users to add web applications to the homescreen.
To get a web application to more fully integrate with the OS,
developers are sometimes required to use proprietary opt-in mechanisms,
which we discuss later, to indicate to the browser that the web
application can potentially work as a stand-alone application once it's
added to the homescreen. These opt-in mechanisms primarily provide the
OS with metadata (e.g., the icons and name of the application) so when
the web application is added to the homescreen, it appears
indistinguishable from an application that was natively installed.
</p>
</section>
<section>
<h2>
Bookmarking
</h2>
<p>
To access a web application, users traditionally opened up a web
browser, typed a URL or a search query into a search box, and had the
browser navigate to the web application they wanted. Alternatively, a
user may have "bookmarked" within a Web browser a set of web documents
or web applications they commonly access.
</p>
<p>
More recently, browsers have started to monitor user's browsing habits
to intelligently deduce which are the most common web sites the user
likes to visit (i.e., a type of automatic bookmarking). The browser
will then present visual links to those sites. Depending on the
browser, user-defined and automatically-gleaned bookmarks will appear
as a list of document titles or file names in either a drop-down menu,
"<a href=
"http://en.wikipedia.org/wiki/Features_of_the_Opera_web_browser#Speed_Dial">speed-dial</a>"
entries, a toolbar, and/or a dedicated application window or tab. All
these bookmark types are illustrated below.
</p>
<figure>
<img src="images/desktop_bookmarking.png" alt="">
<figcaption>
In a desktop-based browser, there are at least six different ways to
access bookmarks. Some of those bookmarks are derived dynamically by
monitoring user's browsing habits, such as the most visited sites and
"<a href=
"http://en.wikipedia.org/wiki/Features_of_the_Opera_web_browser#Speed_Dial">speed
dial</a>" entries the user sees when they open a new tab.
</figcaption>
</figure>
<section>
<h3>
Bookmarking on mobile browsers
</h3>
<p>
On mobile devices, the interaction model has traditionally been the
same as the one described above: historically, there's been a clear
distinction between opening a native application and accessing a web
application. That is, to access a Web application a user needs to
first locate the Web browser they want to use, launch it, and then
either type-in a URL or select a bookmark. Web browsers on mobile
operating systems have thus added similar bookmarking facilities as
those found in desktop-class browsers. This is shown below.
</p>
<figure>
<img src="images/mobile_bookmarks.jpg" alt=
"From left to right, the bookmarking facilities of Safari on iOS, Android 4.3 stock browser, Chrome on iOS, Internet Explorer 10 on Windows Phone 8, and Firefox OS's default browser.">
<figcaption>
The bookmarking facilities of mobile browsers closely resemble
those of desktop-browsers - providing both a traditional list of
bookmarks as well as a "speed dial" that can contain either
automatically gleaned bookmarks or user-configured ones.
</figcaption>
</figure>
<p>
The bookmarking facilities of mobile browsers helps reduce some of
the burden of typing URLs. Particularly for sites that the user
visits regularly, it means that a web site can be accessed by a
single press. Additionally, bookmarking facilities help separate
native applications from web sites the user needs to access for other
reasons (e.g., a particular wiki page on an intranet, a document with
commonly required information, etc.).
</p>
<p>
The following table shows some examples of how a user bookmarks a
page on a mobile browser. Both iOS and Android provide the user with
the ability to customize the name of the bookmark, as well as
organize the bookmark by placing it into a particular location.
Firefox OS, however, simply let's the user "star" a page - this gives
the user the option to bookmark the page. Once bookmarked, the site
is added to a bookmarks tab (not shown below), which, unlike other
mobile browsers, does not provide a means to manipulate the metadata
of the bookmark. On Windows Phone the user can "add favorite". It
does not allow the user to choose the location when adding a site,
however, IE Mobile has a separated option called, "Pin to start".
</p>
<table border="1">
<caption>
Bookmarking a page on a mobile browser
</caption>
<tr>
<th scope="col">
iOS Safari
</th>
<th scope="col">
Android Default Browser
</th>
<th scope="col">
Firefox OS 1.1
</th>
<th scope="col">
Windows Phone 8 IE 10
</th>
</tr>
<tr>
<td>
<img src="images/addtohomescreen/bookmark_io.png" alt=".">
</td>
<td>
<img src="images/addtohomescreen/bookmark_android.png" alt=".">
</td>
<td>
<img src="images/addtohomescreen/bookmark_fxos.png" alt=".">
</td>
<td>
<img src="images/addtohomescreen/bookmark_wp.png" alt=".">
</td>
</tr>
</table>
</section>
<section>
<h3>
Side-effects of bookmarking: multiple home screens
</h3>
<p>
Because basic bookmarks contain links to a range of different types
of resources, the bookmarking facilities of desktop and mobile
browsers do not integrate into an operating system's application
menu. This means that web applications and "native" applications are
treated as different things. This separation makes sense for many
kinds of web sites (e.g., static, informational websites that provide
little other functionality), but there is a range of applications
that can provide an experience that is analogous to that provided by
an application installed locally on a user's device (e.g., a game, an
office productivity suite, a news or social networking site, a
currency converter or photo manipulation utility, etc.). That said,
it is users who are in the best position to decide what they consider
an "app" and where they would like to access it from (either as a
bookmark or as one of their locally installed applications).
</p>
<p>
As shown below, this desire to treat websites as applications has led
at least one browser maker to attempt to replicate the homescreen
experience directly in the browser itself.
</p>
<figure>
<img src="images/ios_default_tab.png" alt=""> <img src=
"images/iOS_homescreen.png" alt="">
<figcaption>
In iOS 7's Safari web browser, the default tab view presents icons
derived from websites to create what is, in effect, a second
homescreen - image on the left. This can be clearly seen when
contrasted with the actual iOS 7 homescreen -image on the right.
Google Chrome's browser, although not shown here, does the same
thing in iOS: it presents bookmarked pages as a grid of icons.
</figcaption>
</figure>
<p>
Although this is a convenient way to access web sites, there are web
applications that would benefit users if they were directly available
from where the user normally accesses their installed applications.
Also relegating web applications to this second homescreen means that
web applications are treated as "second-class citizens": in the sense
that in order to access these applications, a user must first launch
the correct browser (from potentially a range of different browsers),
and then press the icon for the application they wish to load.
</p>
</section>
<section>
<h3>
Key components of bookmarking
</h3>
<p>
From the discussion above, we can conclude that the key bits of
information that are needed to enable bookmarking are:
</p>
<dl>
<dt>
Name (label or title):
</dt>
<dd>
Generally this will be the title of the page being bookmarked.
Mobile browsers usually allow users to change this, specially when
bookmarking to the homescreen.
</dd>
<dt>
Icon:
</dt>
<dd>
Generally, the site's favicon. However, proprietary solutions exist
that allow the browser to select from a range of icons.
</dd>
<dt>
URL:
</dt>
<dd>
The URL to be loaded when the user activates the bookmark.
</dd>
<dt>
Organization:
</dt>
<dd>
Browsers generally provide some facility to allow bookmarks to be
organized (e.g., into folders).
</dd>
</dl>
</section>
</section>
<section>
<h2>
Add to homescreen
</h2>
<p>
Ideally, web applications should be immediately available to users
without them needing to launch a separate application (a web browser)
and having to type a URL. A user may have found a web application
through browsing the web (e.g., through a search engine, via a link
given to them by a friend on a social network, or through a website
that works as an "app store"), but once added to the homescreen, the
developer needs to be able to control if in web application opens in a
Web browser environment or if the application is launched
<dfn>standalone</dfn>: that is, once the application is launched, it
appears indistinguishable from a native application by allowing the OS
to treat it as equivalent to a native application. This includes, but
is not limited to, integration with OS facilities such as the task
switcher and doing away with browser UI chrome (the address bar,
forward/back buttons, etc.).
</p>
<p>
Some browser makers have long acknowledged this as something developers
want and that users could benefit from: iOS's Safari has had the
capability to add a website to the homescreen since early 2008 (as of
version 1.1.3, as shown in the figure below); the Android's stock
browser has provided the capability to "add to homescreen" since at
least 2009. Windows 8 also provides a similar capability, called
"pinning", which we discuss in more detail below.
</p>
<figure>
<img src="images/early_addtohomescreen.jpg" alt="iOS 1.1.3">
<figcaption>
iOS's Safari has almost always provided a way for users to add
websites to the home screen of the device. Once the user presses
"add", the icon for the Web application is placed along side other
native application icons.
</figcaption>
</figure>
<p>
The ability to add a web site to the homescreen didn't automatically
make a web application look, feel, or integrate into the operating
system in the same way as native applications did. For instance,
originally in iOS, launching a web application that had been added to
the homescreen took the user back into Safari; in other words, it
worked just like a traditional bookmark. It was only with the release
of iOS 2.2 in September 2008 that applications that had been added to
the home screen gained the capability to be displayed full screen
(i.e., doing away with Safari's application chrome, as shown below).
Apple did this by introducing a proprietary bit of HTML which
developers could make use of if they so chose to. The result of using
this proprietary switch is shown below.
</p>
<figure>
<img src="images/side-by-side.jpg" alt=
"Variety in iOS's Safari on the left, and variety as an installed app on the right">
<figcaption>
A side-by-side comparison of <cite>Variety</cite>'s web application
running in Safari next to the same application once added to the
homescreen, on the left and right respectively. Variety's web
application makes use of Apple's proprietary switch so to make sure
that once it's launched from iOS's homescreen the application
integrates with the OS. As seen on the right, this means that browser
chrome, including the navigation buttons, ability to bookmark, and
the URL and search bar, have all been removed by iOS.
</figcaption>
</figure>
<p>
Windows 8 also provides similar capabilities, but in two different
forms: one allows a user to "Add site to Apps", meaning that a shortcut
icon to a web application is added amongst natively installed
applications. This is shown below.
</p>
<figure>
<img src="images/add_to_apps.png" alt="">
<figcaption>
In Windows 8, "adding a site to apps" makes a website appear amongst
other apps. Once added, the launch icon is treated identically from
other applications. Once clicked, the web application is opened in
Internet Explorer.
</figcaption>
</figure>
<p>
The second type of bookmarking supported by Internet Explorer is
pinning: this adds the site as a "live tile" to the homescreen. To best
support this functionality, the developer needs to include some
proprietary metadata for the icons and for how often the tile should be
updated. The site is not actually presented in the live tile, but an
RSS feed is used instead.
</p>
<figure>
<img src="images/pin.jpg" alt="">
<figcaption>
On the left, the facility that allows a site to be "pinned" to the
Windows 8 homescreen. On the right, the result of pinning a site is
shown. Note that the content shown in the tile comes from an RSS
feed, and not from the HTML of the site itself.
</figcaption>
</figure>
<figure>
<img src="images/pin_wp.png" alt="Windows Phone Pin to Start">
<figcaption>
Windows Phone 8 comes with the "Pin to Start" feature as well,
however, the mobile version only displays a static thumbnail of the
web site, and the metadata for the "live tile" is not available.
</figcaption>
</figure>
<p>
What initially started as a way to add a link to the homescreen has
incrementally evolved to diminish the functional differences between a
web application and a native application. This has not happened on the
OS level alone: progress on the web platform, such as the ability to
make content available off-line, performance gains through hardware
acceleration, and <a href=
"http://www.html5rocks.com/en/tutorials/forms/html5forms/">integration
with native form controls</a>, has assisted in diminishing these
differences.
</p>
<p>
But it should be noted that being able to have bookmarks outside the
web browser is not something particularly new or noble. Desktop
browsers have had that capability for possibly over a decade. However,
giving developers the choice to tightly integrate their web
applications into the OS directly from the Web browser is still
somewhat new (hence all the proprietary switches and fragmentation in
this space). This is different from packaged applications (zipped-up
HTML applications) or hybrid application (applications that are
distributed as native applications, but rely on a Webview), in that
they applications are "installed" directly from the browser itself
rather than from an app store.
</p>
<table border="1">
<caption>
Examples of add to homescreen on mobile browsers
</caption>
<tr>
<th scope="col">
iOS 7's Safari
</th>
<th scope="col">
Android's Stock browser
</th>
<th scope="col">
Firefox OS 1.1
</th>
</tr>
<tr>
<td>
<img src="images/addtohomescreen/addtohome_ios.png" alt=".">
</td>
<td>
<img src="images/addtohomescreen/addtohome_android.png" alt=".">
</td>
<td>
<img src="images/addtohomescreen/addtohome_fxos.png" alt=".">
</td>
</tr>
</table>
<section>
<h3>
Key components of the "standalone" web application
</h3>
<p>
Web Applications that opt-into being run standalone have somewhat
different requirements to web applications a user has bookmarked to
the homescreen. This is because OS level facilities of interacting
with and controlling native applications are different from those of
a web browsers.
</p>
<p>
In order for a web application to be "installed" in such a way that
it provides a user experience that is indistinguishable from that of
a native application, a number of key things are needed. This list
compliments the list of things needed for bookmarking:
</p>
<dl>
<dt>
Standalone switch:
</dt>
<dd>
If a developer feels that their web application is analogous to a
native application (e.g., it works offline, doesn't need a
navigation bar, etc.), then they use some kind of switch (e.g.,
through markup) to indicate this to the OS when the application is
added to the homescreen. Otherwise, the installed web application
is treated as a regular bookmark and launched in the appropriate
browser.
</dd>
<dt>
Name:
</dt>
<dd>
The ability for a user to find an application through its name.
Some OSs allow native applications to be found by using multiple
names.
</dd>
<dt>
Icons:
</dt>
<dd>
Generally a small graphic that functions as an application's unique
visual identifier amongst a list of installed applications. An
application's icon can also be used in other contexts such a
settings screen, dialogs, notifications and other menus. Because of
the various contexts that a application's icon can appear in an OS,
applications typically need to provide a range of icons at
different sizes and, more recently, specifically targeted at
different device pixel densities.
</dd>
<dt>
Orientation:
</dt>
<dd>
Applications, such as games, require that they be started in a
particular orientation to function effectively.
</dd>
<dt>
Self awareness:
</dt>
<dd>
The application is aware through script that it was launched
"standalone", rather than in the context of a Web browser. This
differs from native applications, which always run stand alone.
</dd>
<dt>
Start page:
</dt>
<dd>
As a web application can be added to the homescreen at any point
the user desires.
</dd>
<dt>
Security:
</dt>
<dd>
Different cookie jar. Is it blank slate? are cookies copied over?
webSQL data?
</dd>
<dt>
Privacy:
</dt>
<dd>
In web browsers, user's are generally able to control privacy
settings for a particular website through "site preferences" or
through the browser's settings. When a web application is taken out
of the browser context, it needs to either integrate with the
privacy settings at the OS level or some other intermidiary
application needs to provide this capability.
</dd>
<dt>
Navigation:
</dt>
<dd>
Applications are generaly composed of one ore more panes, which
together provide the capabilities of the application. Users
generally navigate around different panes depending on what they
are trying to achieve. Web applications, on the othe hand,
generally rely on hyperlinking from one document to another.
</dd>
<dt>
UI behavior:
</dt>
<dd>
Unlike web pages, applications generally don't allow users to
select every span of text on the page.
</dd>
</dl>
</section>
</section>
<section>
<h2>
Indication that the application can work standalone
</h2>
<p>
As already discussed, web applications can be added to the homescreen
of a device in such a manner that they behave just like bookmarks. That
is, once added to the homescreen, when the icon of the web application
is activated, a web browser is launched and the desired web page is
loaded.
</p>
<p>
However, through various proprietary opt-in mechanisms, developers are
able to inform the browser that the application is able to work
"standalone": that is, it is able to function without the user
interface chrome of a browser - which typically means an web
application will be launched in full screen. Depending on the OS and
browser, these opt-in mechanisms can have various side-effects. One
such web application, <a href="http://forecast.io">Forecast.io</a>, is
shown below running in iOS.
</p>
<figure>
<img src="images/ios_integration.jpg" alt="">
<figcaption>
The figure shows how the <cite><a href=
"http://forecast.io">Forecast.io</a></cite> web application
integrates with iOS 7's task switcher. Note also the web
application's launch icon is indistinguishable from those of other
applications.
</figcaption>
</figure>
<section>
<h3>
iOS7 Safari
</h3>
<p>
In iOS, then means by which an application developer indicates that
their application can be run "standalone" is by using a meta element
that takes the following form:
</p>
<pre class="example highlight">
<meta name="apple-mobile-web-app-capable" content="yes">
</pre>
<p>
By declaring the above in a document, iOS will launch an application
that has been added to the home page in fullscreen (without any
browser chrome).
</p>
<p>
If the meta tag is omitted, and a user adds a page to the home
screen, then the web application simply opens in a tab within Safari.
</p>
<p>
We analysed the <a href="https://gist.github.com/7454160">October
data set</a> and found 844 sites declared
"apple-mobile-web-app-capable".
</p>
<p>
TODO: Discuss that a side effect is the following practice, which can
range from the annoying to the just bad and requires browser sniffing
(so you know where to point the "add to home screen" arrow, which is
different on every browser). Having an API might help with this
problem, but allowing developers to be a bit more descrete about
adding to homescreen.
</p>
<figure>
<img src="images/addtohomescreen.jpg" alt="The website, forecast.io">
<figcaption>
The figure shows web applications that asks the end-user to add the
web application to the homescreen. On the left <a href=
"http://forecast.io">forecast.io</a> and <a href=
"http://m.espn.go.com">ESPN</a> on the right.
</figcaption>
</figure>
</section>
<section>
<h3>
Chrome beta for Android
</h3>
<p>
Google Chrome Beta for Android reuses Apple's convention of using a
meta tag whose name is "<code>apple-mobile-web-app-capable</code>".
It also introduces it's own value
"<code>mobile-web-app-capable</code>".
</p>
<pre class="example highlight">
<meta name="mobile-web-app-capable" content="yes">
</pre>
<p>
By declaring the above in a document, Chrome will launch an
application that has been added to the home page in fullscreen
(without any browser chrome).
</p>
<p>
If the <code>meta</code> element is missing, then the site is
launched as a tab within Chrome.
</p>
<p>
We analysed the <a href="https://gist.github.com/7454160">October
data set</a> and found 9 sites declared "mobile-web-app-capable". 4
of those websites declared "apple-mobile-web-app-capable" too.
</p>
</section>
<section>
<h3>
Firefox OS
</h3>
<p>
Firefox OS lacks a way to declaratively indicate to the Web browser
that the application can run standalone when launched. Instead,
Firefox OS relies on an API to provide this functionality. The
<code>mozApps.install()</code> method takes a url to a JSON file as
an argument. The JSON file supplies Firefox OS with the relevant
metadata (e.g., application's name, URLs for the icons, etc.) needed
to make installation possible.
</p>
<pre class="highlight">
navigator.mozApps.install(pathToManifest);
</pre>
</section>
</section>
<section data-include="sections/names.html"></section>
<section>
<h2>
Icons
</h2>
<p>
The <a href="http://whatwg.org/c">Web platform</a> provides two
standardized means to associate icons with a Web application: one being
the <code>link</code> element with the <code>icon</code> link
relationship, and two being the <code>favicon.ico</code> - which is a
graphical resource that a developer places at the root of a site, and
which user agents will automatically attempt to fetch after a document
has loaded.
</p>
<p>
Unfortunately, despite the above two standardized solutions being part
of the platform since at least 2008, support for the above is lacking
and so various proprietary solutions have emerged and continue to
proliferate. This is particularly the case for user agents that support
adding applications to the home screen of a device. For example:
</p>
<dl>
<dt>
iOS:
</dt>
<dd>
For "add to home screen", does not support either of the two standard
solutions. Instead, iOS relies on <code>link</code> elements whose
relationship is "<code>apple-touch-icon</code>". It also
automatically searches the root of a website for specially named
files (e.g., "apple-touch-icon-57x57-precomposed.png").
</dd>
<dt>
Android - Chrome Beta:
</dt>
<dd>
Will use iOS's "<span class=
"example highlight"><code>apple-touch-icon</code>" links if it
encounters them in a HTML document, but it will not automatically
scan the root of a site for those icons.</span>
</dd>
<dt>
Windows 8:
</dt>
<dd>
For "pinned sites", Windows 8 relies on proprietarily-named
<code>meta</code> elements described below. <span class=
"example highlight">Like with iOS, when a site is pinned, it also
automatically scans the root of a site for specifically named files
to use as icons.</span>
</dd>
</dl>
<section>
<h3>
The <code>icon</code> link relationship
</h3>
<p>
To associate an icon with a web application, HTML recommends using a
<code>link</code> element whose link relationship is
"<code>icon</code>". For example:
</p>
<pre>
<link rel="icon" sizes="196x196" href="icon">
</pre>
<p>
As stated in the [[!HTML] specification:
</p>
<blockquote>
<q>Icons could be auditory icons, visual icons, or other kinds of
icons. If multiple icons are provided, the user agent must select the
most appropriate icon according to the type, media, and sizes
attributes. If there are multiple equally appropriate icons, user
agents must use the last one declared in tree order at the time that
the user agent collected the list of icons. If the user agent tries
to use an icon but that icon is determined, upon closer examination,
to in fact be inappropriate (e.g. because it uses an unsupported
format), then the user agent must try the next-most-appropriate icon
as determined by the attributes.</q>
</blockquote>
<p>
Allowing user agents to discriminate depending on media type, media
query, and size potentially provides a complete responsive solution
for icons: in that the user agent can use these data points to select
the most appropriate icon for a particular context (see the <a href=
"http://usecases.responsiveimages.org/">use cases for responsive
images</a>).
</p>
<p>
Despite what the [[!HTML]] specification recommends, support for
discriminating on media, sizes, and type is limited: Given a set of
icons, Gecko-based user agents will use the last known good icon (as
per the [[HTML]] spec). However, no attempt is made to discriminate
on size (via the link element's <code>sizes</code> attribute).
Additionally, Firefox for Android stylizes the icon when a web
application is added to the home screen.
</p>
<p>
Support in Mac OS's Safari is also spotty: given multiple icon
choices, where the last is unavailable, Safari does not attempt to do
any error recovery to find alternative icons. In addition, on iOS,
link <code>rel=icon</code> is not used for "add to homescreen" either
- only the proprietary "apple-touch-icon" solution is supported
(discussed below).
</p>
<p>
Furtunately, <<code>link rel=icon</code>> is fairly well
supported on Chrome on both desktop and on iOS and Android, as is
support in Windows 8: in the aformentioned user agents, the browser
follows the [[HTML]] specification and select appropriate icons based
on the sizes attribute. Both browsers also support error handling.
Unfortunately, in Chrome Beta, when adding to home screen Chrome still
selects the last icon in set, instead of discriminating on size -
this can lead to the wrong icon being selected for the available icon
size of the home screen.
</p>
</section>
<section>
<h3>
Favicon
</h3>
<p>
Favicons are small graphical icons commonly used by web browsers to
help user's identify a site in the browser's user interface. They
typically appear on tabs, in bookmark lists, and when viewing a
browser's history. As favicons were a Microsoft creation, the
proprietary <a href=
"http://en.wikipedia.org/wiki/ICO_%28file_format%29">ICO file
format</a> is a common format used for them. However, browsers are
not restricted to the .ICO format, and all typical file formats used
on the Web are supported (i.e., JPEG, PNG, and GIF).
</p>
<figure>
<img src="images/favicons.png" alt="">
<figcaption>
Visual favicons of various websites, as shown in the browser tabs
of Google Chrome (above) and Firefox on MacOS below.
</figcaption>
</figure>
<p>
A <a href="http://en.wikipedia.org/wiki/Favicon">comprehensive
history of favicons</a> can be found on Wikipedia, as well as a
description of the <a href=
"http://en.wikipedia.org/wiki/ICO_%28file_format%29">ICO file
format</a>. Relevant to this document is the level of
interoperability of favicons in the platform: all user agents support
favicons both through using a link relationship and by a developer
placing a resource called "favicon.ico" at the root of a web site
(i.e., at "/favicon.ico").
</p>
<figure>
<img src="images/favicon.png" width="791" height="394" alt=
"Favicon at different sizes">
<figcaption>
Because of a constraint in the ICO file format, favicons are
limited to dimensions of 256 x 256 pixels (though icons are not
required to be square). However, they can hold any range of icons
below those sizes. This limitations make favicons unsuitable for
context that require very large icons, but makes them suitable for
most contexts in which icons appear in current OSs.
</figcaption>
</figure>
<p>
When an application is added to the home screen of a device, and in
the absence of dedicated proprietary icon declarations within a
document, all user agents tested except iOS make use of favicons.
</p>
<p>
However, Gecko will only ever use the smallest icon in a set of
favicons. Chrome and IE will most of the time select an approprietely
sized icon for the context in which the icon is to be displayed.
</p>
</section>
<section>
<h3>
iOS - Touch icons
</h3>
<p>
In iOS, Apple provides a proprietary declarative solution for
including icons in a HTML document - known as "touch icons". Apple
iOS has supported touch icons since iOS 1.1.3 and other browsers,
such as Chrome on Android, will also make use of these icons as a
fallback when they are available.
</p>
<p>
For example:
</p>
<pre class="example highlight">
<link rel="apple-touch-icon" href="apple-touch-icon.png">
</pre>
<p>
On iOS, when a web page doesn't specify a custom touch icon, the OS
takes a screenshot of the webstie and creates an icon from it. This
is shown below.
</p>
<figure>
<img src="images/ios_icon_screenshot.png" width="320" height="212"
alt="adding to homescreen without a touch icon">
</figure>
<p>
When an application is bookmarked, iOS automatically adds some visual
effects to an icon so that it integrates more effectivly with the
built-in icons on the home screen (as it does with application
icons). Specifically, iOS adds:
</p>
<ul>
<li>Rounded corners
</li>
<li>Drop shadow
</li>
<li>Reflective shine
</li>
</ul>
<p>
As of iOS 2.0, a developer can prevent the addition of these effects
by using the precomposed keyword:
</p>
<pre>
<link rel="apple-touch-icon-precomposed" href="apple-touch-icon-precomposed.png">
</pre>
<p>
If no icons are specified in the HTML, iOS Safari will search the
website’s root directory for icons with the apple-touch-icon or
apple-touch-icon-precomposed prefix. For example, if the appropriate
icon size for the device is 57 × 57 pixels, iOS searches for
filenames in the following order:
</p>
<ul>
<li>apple-touch-icon-57x57-precomposed.png
</li>
<li>apple-touch-icon-57x57.png
</li>
<li>apple-touch-icon-precomposed.png
</li>
<li>apple-touch-icon.png
</li>
</ul>
<p>
So, for iOS, it’s not necessary to use HTML to add touch icons to a
site, even if one wants to use multiple resolution-specific icons.
This helps avoid having to use proprietary <code><link
rel="apple-touch-icon"></code> elements on every single HTML page.
A developer just needs to create different versions of the icon, use
the correct file names and place them in the root of the website.
</p>
</section>
<section>
<h3>
Android
</h3>
<p>
Android has a default system provided icon, and, as already mention,
it will fall back to using a favicon if it’s available.
</p>
<p>
Although Android is able to fallback to using the iOS icons, the
no-HTML approach doesn’t work on the Android browser (tested in 2.3
Gingerbread, 3 Honeycomb, 4.1 Jelly Bean), although there is
anectodotal evidence <a href=
"https://twitter.com/puntlino/status/312289586736951296">it does work
in and 4.2 Jelly Bean’s default browser</a>.
</p>
</section>
<section>
<h3>
Windows
</h3>
<p>
Web applications intended to be "pinned" rely on meta elements whose
name is "<code>msapplication-square{w}x{h}logo</code>", where
<var>{w}</var> and <var>{h}</var> are the width and height of the
logo.
</p>
<p>
Like iOS, when the proprietary declarations are missing, Windows will
also search the root of a website for specifically named files that
follow the afformentioned file name pattern. If no suitabile icons
are found, Windows will fall back to using a favicon.
</p>
<p>
According to the <a href=
"http://blogs.msdn.com/b/ie/archive/2012/06/08/high-quality-visuals-for-pinned-sites-in-windows-8.aspx">
<cite>IE Blog</cite></a>, Internet Explorer "only downloads the tile
image when the user pins the site to his or her Start screen so sites
don’t incur additional bandwidth costs.
</p>
</section>
</section>
<section>
<h2>
Security and privacy
</h2>
<p>
The act of adding an application to the home screen serves as a cue to
alter the security policy of an application. For example, in iOS, and
application that has been added to the home screen will no longer share
cookies, localStorage, IDB, etc. with the Safari Web browser. The OS
will also reset all its API permissions, so, for example, any
previously granted permission to access location services that occurred
in the browser are forgotten once the application is added to the
homescreen - the end-user will need to re-enable such permission again
after the application is launched from the homescreen.
</p>
<p>
Furthermore, by adding the application to the home screen, the
application gains its own independent privacy settings in iOS's privacy
menus. This is shown in the figure below.
</p>
<figure>
<img src="images/ios_privacy.png" alt=
"iOS's privacy for location settings">
<figcaption>
iOS privacy settings for location services. Shown is Forecast, which
is an installed web application as well as the Safari Web browser.
Here, users can disable the . More importantly, disabling location
services for the Web browser does not affect the ability of Forecast
to access location services.
</figcaption>
</figure>
</section>