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

Quick access to LC-442 LC-443 LC-444 LC-445 LC-446 LC-447 LC-448 LC-449 LC-450 LC-451 LC-452 LC-453 LC-454 LC-455 LC-456

Comment LC-442

Comment Shortname:

Commenter: Ian B. Jacobs <ij@w3.org>

Message-id:

Section of the document concerned:

[Free text description]Document as a wholeMobile Web Best Practices 1.0 Basic Guidelines W3C Working Draft 12 April 2006 Abstract Status of this Document Table of Contents Appendices List of Best Practices 1 Introduction 1.1 Purpose of the Document 1.2 How the Best Practices are Organized 1.3 Audience 1.4 Scope 1.4.1 Phasing 1.5 Relationship to other Best Practices and recommendations 1.6 Longevity and Versioning 2 Requirements 2.1 Presentation Issues 2.2 Input 2.3 Bandwidth and Cost 2.4 User Goals 2.5 Advertising 2.6 Device Limitations 2.7 Advantages 3 Delivery Context 3.1 One Web 3.2 Background to Adaptation 3.3 Adaptation Implementation Model 3.4 Assumptions about Adaptation 3.5 Establishing Context 3.6 Choice of User Experience 3.7 Default Delivery Context 4 Structure of Best Practice Statements [EXAMPLE] This is a ... 5 Best Practice Statements 5.1 Overall Behavior 5.1.1 Thematic Consistency of Resource Identified by a URI [THEMATIC_CONSISTENC... 5.1.1.1 What it means 5.1.2 Exploit Client Capabilities [CAPABILITIES] Explo... 5.1.2.1 What it means 5.1.3 Work around Deficient Implementations [DEFICIENCIES] Take ... 5.1.3.1 What it means 5.1.4 Testing [TESTING] Carry out ... 5.1.4.1 What it means 5.1.4.2 How to do it 5.2 Navigation and Links 5.2.1 URIs of Site Entry Points [URIS] Keep the URIs... 5.2.1.1 What it means 5.2.1.2 How to do it 5.2.2 Navigation Bar [NAVBAR] Provide onl... 5.2.2.1 What it means 5.2.2.2 How to do it 5.2.3 Balanced Structure [BALANCE] Take into ... 5.2.3.1 What it means 5.2.4 Navigation Mechanisms [NAVIGATION] Provide... 5.2.4.1 What it means 5.2.4.2 How to do it 5.2.4.3 References 5.2.5 Access Keys [ACCESS_KEYS] Assign... 5.2.5.1 What it means 5.2.5.2 What to test 5.2.5.3 References 5.2.6 Link Target Identification [LINK_TARGET_ID] Cle... [LINK_TARGET_FORMAT]... 5.2.6.1 What it means 5.2.6.2 How to do it 5.2.6.3 What to test 5.2.6.4 References 5.2.7 Image Maps [IMAGE_MAPS] Do not ... 5.2.7.1 What it means 5.2.7.2 How to do it 5.2.7.3 What to test 5.2.7.4 References 5.2.8 Refreshing, Redirection and Spawned Windows [POP_UPS] Do not cau... [AUTO_REFRESH] Do no... [REDIRECTION] Do not... 5.2.8.1 What it means 5.2.8.2 What to test 5.2.8.3 References 5.2.9 Externally Linked Resources [EXTERNAL_RESOURCES]... 5.2.9.1 What it means 5.2.9.2 How to do it 5.2.9.3 What to test 5.3 Page Layout and Content 5.3.1 Page Content [SUITABLE] Ensure th... [CLARITY] Use clear ... [LIMITED] Limit cont... 5.3.1.1 What it means 5.3.1.2 What to test 5.3.1.3 References 5.3.2 Page Size [PAGE_SIZE_USABLE] D... [PAGE_SIZE_LIMIT] En... 5.3.2.1 What it means 5.3.2.2 How to do it 5.3.2.3 What to test 5.3.2.4 References 5.3.3 Scrolling [SCROLLING] Limit sc... 5.3.3.1 What it means 5.3.3.2 How to do it 5.3.3.3 What to test 5.3.4 Navigation Bars etc. (Extraneous material) [CENTRAL_MEANING] En... 5.3.4.1 What it means 5.3.4.2 How to do it 5.3.4.3 What to test 5.3.4.4 References 5.3.5 Graphics [GRAPHICS_FOR_SPACIN... [LARGE_GRAPHICS] Do ... 5.3.5.1 What it means 5.3.5.2 What to test 5.3.6 Color [USE_OF_COLOR] Ensur... [COLOR_CONTRAST] Ens... 5.3.6.1 What it means 5.3.6.2 What to test 5.3.6.3 References 5.3.7 Background Images [BACKGROUND_IMAGE_RE... 5.3.7.1 What it means 5.3.7.2 What to test 5.4 Page Definition 5.4.1 Title [PAGE_TITLE] Provide... 5.4.1.1 What it means 5.4.1.2 What to test 5.4.2 Frames [NO_FRAMES] Do not u... 5.4.2.1 What it means 5.4.2.2 What to test 5.4.2.3 References 5.4.3 Structural Elements [STRUCTURE] Use feat... 5.4.3.1 What it means 5.4.3.2 How to do it 5.4.4 Tables [TABLES_SUPPORT] Do ... [TABLES_NESTED] Do n... [TABLES_LAYOUT] Do n... [TABLES_ALTERNATIVES... 5.4.4.1 What it means 5.4.4.2 How to do it 5.4.4.3 What to test 5.4.4.4 References 5.4.5 Non-Text Items [NON-TEXT_ALTERNATIV... [OBJECTS_OR_SCRIPT] ... 5.4.5.1 What it means 5.4.5.2 How to do it 5.4.5.3 What to test 5.4.5.4 References 5.4.6 Image Size [IMAGES_SPECIFY_SIZE... [IMAGES_RESIZING] Re... 5.4.6.1 What it means 5.4.6.2 What to test 5.4.7 Valid Markup [VALID_MARKUP] Creat... 5.4.7.1 What it means 5.4.7.2 What to test 5.4.7.3 References 5.4.8 Measures [MEASURES] Do not us... 5.4.8.1 What it means 5.4.8.2 How to do it 5.4.8.3 What to test 5.4.9 Style Sheets [STYLE_SHEETS_USE] U... [STYLE_SHEETS_SUPPOR... [STYLE_SHEETS_SIZE] ... 5.4.9.1 What it means 5.4.9.2 How to do it 5.4.9.3 What to test 5.4.9.4 References 5.4.10 Minimize [MINIMIZE] Use terse... 5.4.10.1 What it means 5.4.10.2 How to do it 5.4.10.3 What to test 5.4.11 Content Types [CONTENT_FORMAT_SUPP... [CONTENT_FORMAT_PREF... 5.4.11.1 What it means 5.4.11.2 How to do it 5.4.11.3 What to test 5.4.12 Character Encoding [CHARACTER_ENCODING_... [CHARACTER_ENCODING_... 5.4.12.1 What it means 5.4.12.2 How to do it 5.4.12.3 What to test 5.4.12.4 References 5.4.13 Error Messages [ERROR_MESSAGES] Pr... 5.4.13.1 What it means 5.4.13.2 How to do it 5.4.13.3 What to test 5.4.14 Cookies [COOKIES] Do not rel... 5.4.14.1 What it means 5.4.14.2 How to do it 5.4.14.3 What to test 5.4.15 Cache Headers [CACHING] Provide ca... 5.4.15.1 What it means 5.4.15.2 How to do it 5.4.15.3 What to test 5.4.15.4 References 5.4.16 Fonts [FONTS] Do not rely ... 5.4.16.1 What it means 5.4.16.2 How to do it 5.4.16.3 What to test 5.5 User Input 5.5.1 Input [MINIMIZE_KEYSTROKES... [AVOID_FREE_TEXT] Av... [PROVIDE_DEFAULTS] P... [DEFAULT_INPUT_MODE]... 5.5.1.1 What it means 5.5.1.2 How to do it 5.5.1.3 What to test 5.5.1.4 References 5.5.2 Tab Order [TAB_ORDER] Create a... 5.5.2.1 What it means 5.5.2.2 How to do it 5.5.2.3 What to test 5.5.3 Labels [CONTROL_LABELLING] ... [CONTROL_POSITION] P... 5.5.3.1 What it means 5.5.3.2 What to test 5.5.3.3 References 6 Conformance and mobileOK 6.1 Classes of Products 6.2 Extensibility A Sources (Non-Normative) B Acknowledgements (Non-Normative) C References (Non-Normative) C.1 MWI References Scope Techniques mobileOK C.2 Sources WCAG iMode Opera OpenWave Nokia-MP Nokia-VR LSD C.3 Device Independence DIP DCODI DIGLOSS C.4 Web, Protocols and Languages WebArch XML XHTML-Basic CSS HTTP1.0 HTTP1.1 UTF-8 CHARSET1 CHARSET2 C.5 Other References UAPROF TOMCAT APACHE IIS T-MOB MF
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:

1) 5.1.3 Work around deficient implementations.

Question: If I conform to standards without looking further,
do I satisfy this practice?

If the answer is "yes" then I am satisfied and ask only that
this be made clear in the document.

If the answer is "no, you have to do more than conform to
standards," then I have an issue. I think it places an
unreasonable burden on authors to have to learn about the
diverse landscape of browsers, platforms, and bugs. There may
be large organizations that have resources to do this, but I
believe that for the millions of individuals or small
organizations that will likely wish to satisfy this document
(or be required to, who knows), this is an unreasonable
burden.

Instead, I suggest: "Even if it means that you have to deviate
from standards, you MAY work around deficient
implementations." I realize that the group is creating "best
practices" and considers this to be good practice. However,
even if satisfying this requirement is possible for a few
content providers, I think it will be very difficult for
ordinary authors.

If content that conforms to the standards that define the
default delivery context satisfies this requirement, then
please make that abundantly clear. However, because authors
are asked to do more than design for the default delivery
context (practice #2), it still sounds like one is forced to go
beyond the defaults in order to conform.

Lastly, I believe a desirable property of conforming content
is that once it conforms, it always conforms. Because browser
bugs vary over time, content that once conformed may not
conform in the future. One way to handle this is to date
conformance claims, but that does not improve on the fact that
the content's conformance status may vary over time.

Related issues: 88
(space separated ids)

WG Notes: Jo to add text based on email. 06-05-04 Jo added comments based on email, lightly edited for context.

Resolution: The main point here is that no one is forcing anyone to do anything. So there is no implication of 'have to' and there is a strong element of it being a good thing to do. We note that it is a particular challenge to provide work-arounds and where we say that deviation may be necessary we make the point in quite a limited way [It is recognized that content providers may need to violate specific Best Practices in order to support their intentions on devices that exhibit deficiencies in implementation.] However we use very strong language to encourage standards compliance [If a device is not known to have specific limitations then content providers must comply with Best Practices.] In summary, these comments are very relevant to mobileOK and should feature largely in that thinking. However as noted above, the BP as it stands is clear enough that it is an escape hatch for those that wish to do better than the bare minimum.

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