-
Notifications
You must be signed in to change notification settings - Fork 3
/
index.html
292 lines (292 loc) · 12.9 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
<!DOCTYPE html>
<html xmlns='http://www.w3.org/1999/xhtml' lang='en'>
<head>
<meta charset='utf-8'/>
<title>Core Mobile Web Platform — Level 0</title>
<script class='remove'>
var respecConfig = {
specStatus: "ED"
, shortName: "coremob-0"
, editors: [
{ name: "Tobie Langel"
, company: "Facebook"
, companyURL: "http://facebook.com/" }
, { name: "Robin Berjon"
, url: "http://berjon.com/"
, company: "Robineko"
, companyURL: "http://robineko.com/" }
]
, edDraftURI: "http://coremob.github.com/level-0/index.html"
, copyrightStart: 2012
, noIDLIn: true
, wg: "Core Mobile Web Platform Community Group"
, wgURI: "http://www.w3.org/community/coremob/"
, wgPublicList: "public-coremob"
, wgPatentURI: "XXX"
, isRecTrack: false
, isNoTrack: true
};
</script>
<script src='http://respec.specifiction.com/js/profiles/w3c-common.js' class='remove'></script>
</head>
<body>
<p style="background: black; color: white; font: 900 1.2em serif; padding: 0.5em 1em; border: dotted yellow 0.3em;">
The Core Mobile Web Platform Community Group is not currently pursuing
work on this document. Please treat this document with caution and do
not reference it or use it as the basis for any implementation or contribution.
</p>
<section id='sotd'>
<p>
Development of this document happens on <a href='https://github.com/coremob/level-0'>GitHub</a>.
Please file well-scoped <a href='https://github.com/coremob/level-0/issues'>issues</a> and send
<a href='https://github.com/coremob/level-0/pulls'>pull requests</a> directly on GitHub. Please
send comments to the mailing list as described below.
</p>
</section>
<section id='abstract'>
<p>
This specification describes the core set of technologies that define the baseline platform
for mobile Web applications to target. It does not create any new technology but rather syndicates
them into a globally coherent view of the Web platform as available on mobile devices.
</p>
<p>
This is Level 0, the first iteration. As the platform evolves and new technologies become broadly
available, additional levels, which are guaranteed to remain backwards compatible, will be layered
on top of the present one.
</p>
</section>
<section>
<h2>Philosophy</h2>
<p>
This document is not mobile-specific, but rather mobile-scoped. This is to say that there is no part
of its content that applies solely to mobile terminals, or to any particular device class; all of its
recommendations work and apply equally well across the entire Web. It does however focus on addressing
issues commonly found in developing Web applications on mobile devices.
</p>
<p>
It does so by taking a platform view of Web application development in the mobile ecosystem. As things
currently stand, there is a large body of diverse specifications at varied degrees of maturity that
are supported on mobile devices. These specifications are designed to work together, but also to be
implementable separately. Because of this, and because of the great variety of vendors involved in
the mobile platform, we currently have an ecosystem in which different vendors have elected to support
different subsets of the complete group of technologies currently in development. This fragmentation makes
it particularly difficult for developers to know which features they may rely on in creating applications,
which in turn hurts the development of the entire Web ecosystem.
</p>
<p>
By taking the platform view, this document defines a common baseline that is expected to be universally
available to developers (or sufficiently close to that to be useful). It does not replace any existing
specification, be it considered stable or in continuous development. Its only goal is to define a baseline
target platform that vendors can align on.
</p>
<p>
In no case should this be considered a cap on the features that an application may use — developers are
considered to know what they are doing and to be naturally free to use any functionality not included in
this core baseline according to their own judgement. It is not intended to be the final word on the
Web platform either, rather the intent of the group in charge of this document is to produce multiple
levels in quick succession that will layer atop one another as parts of the platform that are reliably
usable stabilise sufficiently and can be driven to adoption and deployment. For this first level, we
have started off the intersection of what is available in the most popular mobile platforms. Future levels
will assume more of a driving role.
</p>
<p>
Our focus in writing this series of documents is entirely driven by developer needs. There may at times
be some corner case issues that would require deep exegesis of this or that specification were we to address
them. But unless a demonstrated interoperability issue can be exposed that concerns a real-world
use case for such corner case behaviours, such exegesis will not take place and we will gladly ignore
these darker corners. At times some choices may be messy, or even against known best practices. But if they
are the most pragmatic option, they will be chosen.
</p>
<!-- Froyo or Gingerbread + iOS5 -->
</section>
<section>
<h2>Markup</h2>
<p>
This section describes requirements for markup languages and related features.
</p>
<p>
User agents MUST support the following parts from HTML 5 [[!HTML5]]:
</p>
<ul>
<li>The HTML Syntax [§8]</li>
<li>XHTML served as <code>application/xhtml+xml</code></li>
<li>Offline Web applications, also known as Application Cache [§5.6]</li>
<li>The <code>audio</code> [§4.8.7] and <code>video</code> [§4.8.6] elements</li>
<li>Session history and navigation [§5.4], notably the <code>History</code> interface and the <code>hashchange</code> event</li>
<li>DOM tree accessors [§3.1.4], notably <code>getElementsByClassName</code></li>
<li>The elements from Sections [§4.4], Grouping [§4.5], Text-level semantics [§4.6], and Edits [§4.7]</li>
</ul>
<p>
For video, user agents MUST support the ITU-T VCEG H.264 codec.
</p>
<p>
For audio, user agents MUST support MPEG-2 Audio Layer III.
</p>
<p class='issue'>
Obviously the two above taken on their own don't give you much. Into how much detail do we need to go?
</p>
<p class='issue'>
Not certain that AppCache is Level 0.
</p>
<p class='issue'>
Codecs are evil. Thoughts?
</p>
<section>
<h2><code>meta</code> Elements</h2>
<p>
User agents MUST support CSS Device Adaptation [[!CSS-ADAPTATION]] as specified through a <code>meta</code>
viewport element.
</p>
<p class='issue'>
Not sure that this is clear enough, and it probably requires more than what is supported.
</p>
</section>
</section>
<section>
<h2>Style</h2>
<p>
This section defines which support for styling with CSS is required at this level.
</p>
<p>
It is particularly important to note that <em>at this level</em> and depending on future decisions
quite possibly <em>at this level only</em> a user agent is considered to support the features required
in this section even if they are only available behind vendor prefixes.
</p>
<p>
User agents MUST support CSS 2.1 [[!CSS21]]. Implementers should pay special attention to:
</p>
<ul>
<li>all selectors</li>
<li>generated content</li>
<li><code>position: fixed</code></li>
<li>min-/max- properties</li>
<li>Display values for inline-block and tables</li>
</ul>
<p>
User agents MUST support CSS Media Queries [[!CSS3-MEDIAQUERIES]] for the following media features:
width, height, device-width, device-height, and orientation (including their min-/max- variants
where applicable).
</p>
<p>
User agents MUST support CSS Backgrounds and Borders [[!CSS3-BG]].
</p>
<p>
User agents MUST support CSS Animation [[!CSS3-ANIMATIONS]].
</p>
<p>
User agents MUST support CSS Color [[!CSS3COLOR]], specifically the <code>opacity</code> property,
and RGBA and HSLA values.
</p>
<p>
User agents MUST support CSS Fonts [[!CSS3-FONTS]]. Both the TTF and OTF formats are required.
</p>
<p>
User agents MUST support CSS 2D Transforms [[!CSS3-2D-TRANSFORMS]].
</p>
<p>
User agents MUST support CSS Transitions [[!CSS3-TRANSITIONS]].
</p>
<p>
User agents MUST support CSS User Interface [[!CSS3UI]], specifically <code>text-overflow</code>,
<code>box-sizing</code>, and <code>pointer-events</code>.
</p>
<p>
User agents MUST support Flexible Box Layout [[!FLEXBOX]].
</p>
<p>
User agents MUST support CSS Multi-column Layout [[!CSS3COL]].
</p>
<p>
User agents MUST support CSS Image Values and Replaced Content [[!CSS-IMAGEVAL]] for gradients.
</p>
<p>
User agents MUST support CSS Text [[!CSS3TEXT]], notably the <code>word-wrap</code> property
(now called <code>overflow-wrap</code>, either naming is acceptable) and <code>text-shadow</code>.
</p>
<p class='issue'>
I doubt that we want all of CSS Text just yet.
</p>
<p>
User agents MUST support the <code>rem</code> unit from CSS Values [[!CSS3VAL]].
</p>
<p>
User agents MUST support PNG alpha transparency.
</p>
</section>
<section>
<h2>Scripting</h2>
<p>
This section defines which scripting support in language and APIs are required at this level.
</p>
<p>
User agents MUST support ECMAScript ed3 [[!ECMA-262]] in full, plus all the parts from ed5 that
can be shimmed, including native JSON. Notably, user agents MUST support callable host objects
using <code>apply()</code>.
</p>
<p class='issue'>
The "can be shimmed" criterion seems like a good one, but it ought to be more precisely defined.
If you implement JS in JS you can shim pretty much anything.
</p>
<p>
User agents MUST support the Canvas2D API [[!CANVAS-2D]].
</p>
<p>
User agents MUST support the Geolocation API [[!GEOLOCATION-API]].
</p>
<p>
User agents MUST support the DeviceOrientation Event [[!DEVICE-ORIENTATION]].
</p>
<p>
User agents MUST support Touch Events version 1 [[!TOUCH-EVENTS]].
</p>
<p class='issue'>
Need to check if Touch isn't for Level 1.
</p>
<p>
User agents MUST support the Web Messaging API [[!POSTMSG]].
</p>
<p>
User agents MUST support the XMLHttpRequest API level 2 [[!XMLHTTPREQUEST2]], notably support for
Progress Events [[!PROGRESS-EVENTS]].
</p>
<p class='issue'>
We require Progress Events which are in XHR level 2, but all the rest of XHR2 is for CoreMob level 1.
</p>
<p>
User agents MUST support the Selectors API level 2 [[!SELECTORS-API2]].
</p>
<p>
User agents MUST support the Web Storage API [[!WEBSTORAGE]].
</p>
<p class='issue'>
Obviously there are quite a few more. DOM4?
</p>
</section>
<section>
<h2>Network</h2>
<p>
This section defines which networking protocols are required at this level.
</p>
<p>
User agents MUST support HTTP 1.1 [[!HTTP11]].
</p>
<p class='issue'>
I would assume that such support may be partial at best for some of the more obscure parts of HTTP.
Do we care? Are there known interoperability issues here?
</p>
<p>
User agents MUST support Cross-Origin Resource Sharing [[!CORS]].
</p>
<p class='issue'>
What do we need to specify for HTTPS/SSL/TLS?
</p>
<p>
User agents SHOULD support dispatching the following URI schemes to the appropriate applications
<code>tel:</code>, <code>sms:</code>, <code>mmsto:</code>, and <code>mailto:</code>.
</p>
<p>
User agents MUST support <code>data:</code> URLs.
</p>
</section>
</body>
</html>