Edit comment LC-2294 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-2294

Comment Shortname:

Commenter: Robin Berjon <robin@berjon.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:

3.3: "Browsers may have access to information such as: • Pictures, music, and video clips; • Contacts, calendar (PIM data); • Call history; • System data (battery, coverage, roaming, location); • Media recording (record audio/video clip, get new picture); • Device context (e.g. location, connectivity, profile setting)."

I am not aware that there are any plans to grant browsers access to such information gratuitously. They may be granted within web runtimes, but even then with clear restrictions. In general this seems to address implementers more than authors.

Related issues: (space separated ids)

WG Notes: Resolution: http://www.w3.org/2009/12/09-bpwg-minutes.html#added09 FD: text clarified. The discussion on implementers vs. authors remains. RESOLUTION: Add to 3.3 the into text: Where possible rely on the browser's native functionality to implement the confirming featues described in this section

Resolution: The best practices of this document do not address implementers. We have added some text in section 3.3 to explain that the best practices in this section provide further advice on appropriate application behaviour in situations where the native functionality of the browser may not be sufficient.

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