Edit comment LC-2265 for Mobile Web Best Practices Working Group

Quick access to LC-2265 LC-2266 LC-2271 LC-2272 LC-2273 LC-2274 LC-2275 LC-2276 LC-2277 LC-2278 LC-2279 LC-2280 LC-2281 LC-2282 LC-2283 LC-2284 LC-2285 LC-2286 LC-2287 LC-2288 LC-2290 LC-2291 LC-2292 LC-2293 LC-2294 LC-2295 LC-2296 LC-2297 LC-2298 LC-2299 LC-2300

Comment LC-2265

Comment Shortname:

Commenter: Arthur Barstow <art.barstow@nokia.com>

Message-id:

Section of the document concerned:

[Free text description]Document as a wholeMobile Web Application Best Practices W3C Working Draft 6 October 2009 Abstract Status of this Document Table of Contents Appendices List of Best Practices 1 Introduction 1.1 Purpose of the Document 1.2 Audience 1.3 Scope 1.3.1 Best Practices 1.3.2 Web Application 1.3.3 Mobile Context 1.3.4 Delivery Context 1.4 Relationship to other Best Practices and recommendations 1.5 Terminology 2 Structure of Best Practice Statements 3 Best Practice Statements 3.1 Application Data 3.1.1 Use Cookies Sparingly 3.1.1.1 What it means 3.1.2 Use Appropriate Client-Side Storage Technologies for Local Data 3.1.2.1 What it means 3.1.2.2 How to do it 3.1.3 Replicate Local Data To A Server If Necessary 3.1.3.1 What it means 3.1.3.2 How to do it 3.2 Security and privacy 3.2.1 Do not Execute Unescaped or Untrusted JSON data 3.3 User Awareness and Control 3.3.1 Inform the User About Automatic Network Access 3.3.1.1 What it means 3.3.1.2 How to do it 3.3.2 Provide Sufficient Means to Control Automatic Network Access 3.3.2.1 What it means 3.3.2.2 How to do it 3.3.3 Ensure the User is Informed About Use of Personal and Device Information 3.3.3.1 What it means 3.3.3.2 How to do it 3.3.4 Enable Automatic Sign-in 3.3.4.1 What it means 3.3.4.2 How to do it 3.4 Conservative use of resources 3.4.1 Use Transfer Compression 3.4.1.1 What it means 3.4.1.2 How to do it 3.4.2 Minimize Application and Data Size 3.4.2.1 What it means 3.4.2.2 How to do it 3.4.3 Avoid Redirects 3.4.3.1 What it means 3.4.3.2 How to do it 3.4.4 Optimize Network Requests 3.4.4.1 What it means 3.4.4.2 How to do it 3.4.5 Minimize External Resources 3.4.6 Aggregate Static Images into a Single Composite Resource (Sprites) 3.4.7 Include Background Images Inline in CSS Style Sheets 3.4.8 Cache Resources By Fingerprinting Resource References 3.4.9 Cache AJAX Data 3.4.10 Don't Send Cookie Information Unnecessarily 3.4.11 Keep DOM Size Reasonable 3.4.11.1 What it means 3.4.11.2 How to do it 3.5 User Experience 3.5.1 Optimize For Application Start-up Time 3.5.1.1 What it means 3.5.1.2 How to do it 3.5.2 Minimize Perceived Latency 3.5.2.1 What it means 3.5.2.2 How to do it 3.5.3 Design for Multiple Interaction Methods 3.5.3.1 What it means 3.5.3.2 How to do it 3.5.4 Preserve Focus on Dynamic Page Updates 3.5.4.1 What it means 3.5.4.2 How to do it 3.5.5 Use Fragment IDs to Drive Application View 3.5.6 Make Telephone Numbers "Click-to-Call" 3.5.6.1 What it means 3.5.6.2 How to do it 3.5.6 Ensure Paragraph Text Flows 3.5.8 Ensure Consistency Of State Between Devices 3.5.9 Consider Mobile Specific Technologies for Initiating Web Applications 3.5.9.1 What it means 3.5.9.2 How to do it 3.5.10 Consider Use of Canvas Tag or SVG For Dynamic Graphics 3.5.10.1 What it means 3.5.10.2 How to do it 3.5.11 Use viewport Meta Tag To Identify Desired Screen Size 3.5.11.1 What it means 3.5.11.2 How to do it 3.6 Handling Variations in the Delivery Context 3.6.1 Prefer Server-Side Detection Where Possible 3.6.1.1 What it means 3.6.1.2 How to do it 3.6.2 Use Client-Side Capability Detection Where Necessary 3.6.2.1 What it means 3.6.2.2 How to do it 3.6.3 Use Device Classification to Simplify Content Adaptation 3.6.3.1 What it means 3.6.3.2 How to do it 3.6.4 Support a non-JavaScript Variant if Appropriate 3.6.4.1 What it means 3.6.4.2 How to do it 3.6.5 Offer Users a Choice of Interfaces 3.6.5.1 What it means 3.6.5.2 How to do it Appendix: Best Practice Dependent Device Properties A Related Reading (Non-Normative) B References (Non-Normative) B.1 MWI References B.2 Device Independence B.3 Web, Protocols and Languages B.4 Other References
or

Refinement of the section concerned:

Status:

open proposal pending resolved_yes resolved_no resolved_partial other assigned to Nobody

Type: substantive editorial typo question general comment undefined

Resolution status:

Response drafted Resolution implemented Reply sent to commenter

Response status:

No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):

Comment:

Re Status of the Document (SotD) section: given this document is
purely non-normative, why is this document "expected to become a W3C
Recommendation" rather than a Working Group note? For example, how
would this document ever be able to meet the following entrance
criteria for Proposed Recommendation:

[[
http://www.w3.org/2005/10/Process-20051014/tr.html#cfr

2. Shown that each feature of the technical report has been implemented.
]]

Related issues: (space separated ids)

WG Notes: Resolution: http://www.w3.org/2009/12/09-bpwg-minutes.html#added03

Resolution: We will follow the precedent set by various Recommendations which are guidelines, e.g. the Mobile Web Best Practices, and have Exit Criteria which shows that each Best Practice is implemented and therefore implementable. Precise Exit Criteria have not been agreed upon as of today. The group expects to ask for at least two independently sourced implementations of each Best Practice.

(Please make sure the resolution is adapted for public consumption)