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

Comment Shortname:

Commenter: Marc Wilson <marcwilson@google.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.6.4.2
Are we really recommending to send the user back a HTTP error code
that essentially provides no information to the user as to why their
request is "Not Acceptable". I understand this may be the 'correct'
behaviour, but the UX it results in is hideous.

Related issues: (space separated ids)

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

Resolution: We agree and have removed the reference to the 406 status code.

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