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

Quick access to LC-1854 LC-1855 LC-1856 LC-1857 LC-1858 LC-1859 LC-1896 LC-1897 LC-1898 LC-1899 LC-1900 LC-1901 LC-1902 LC-1903 LC-1904 LC-1905 LC-1906 LC-1907 LC-1908 LC-1909

Comment LC-1859

Comment Shortname:

Commenter: Laurens Holst <lholst@students.cs.uu.nl>

Message-id:

Section of the document concerned:

[Free text description]Document as a wholeW3C mobileOK Basic Tests 1.0 /**/ code { font-... W3C mobileOK Basic Tests 1.0 W3C Working Draft 28 September 2007 Abstract Status of this Document Table of Contents Appendices 1 Introduction 1.1 Levels of mobileOK 1.1.1 mobileOK Basic 1.1.2 mobileOK Pro 1.1.3 Out of Scope 1.1.4 Beyond mobileOK 1.2 Applicability 1.3 Claiming mobileOK conformance 2 Conformance 2.1 Use of Terms must, should etc. 2.2 Validity of the Tests 2.3 Testing Outcomes 2.4 Conduct of Tests 2.4.1 Order of Tests 2.4.2 HTTP Request 2.4.3 HTTP Response 2.4.4 Meta http-equiv Elements 2.4.5 CSS Style 2.4.6 Included Resources 2.4.7 Linked Resources 2.4.8 Validity 2.4.9 White Space 3 mobileOK Basic Tests 3.1 AUTO_REFRESH and REDIRECTION 3.2 CACHING 3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE 3.4 CONTENT_FORMAT_SUPPORT and VALID_MARKUP 3.5 DEFAULT_INPUT_MODE 3.6 EXTERNAL_RESOURCES 3.7 GRAPHICS_FOR_SPACING 3.8 IMAGE_MAPS 3.9 IMAGES_RESIZING and IMAGES_SPECIFY_SIZE 3.10 LINK_TARGET_FORMAT 3.11 MEASURES 3.12 MINIMIZE 3.13 NO_FRAMES 3.14 NON-TEXT_ALTERNATIVES 3.15 OBJECTS_OR_SCRIPT 3.16 PAGE_SIZE_LIMIT 3.17 PAGE_TITLE 3.18 POP_UPS 3.19 PROVIDE_DEFAULTS 3.20 STYLE_SHEETS_SUPPORT 3.21 STYLE_SHEETS_USE 3.22 TABLES_ALTERNATIVES 3.23 TABLES_LAYOUT 3.24 TABLES_NESTED A Acknowledgments (Non-Normative) B References (Non-Normative) BestPractices CSS GIF JPEG POWDER RFC2119 RFC2617 Techniques UTF-8 WCAG XHTMLBasic11 XHTMLModularization XML10 XML11 C Relationship between Best Practices and mobileOK Tests (Non-Normative)
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:

Jo Rabin schreef:
>
> Laurens
>
>
>
> Thanks for your further reply on this. Ref RFC2616
>
>
>
> Accept headers *can* be used to specify certain media
>
> types which are acceptable for the response. …
>
>
>
> Not “should” or “must”.
>

I think you’re misinterpreting that sentence, it “can” be used because
the Accept header is optional. It does not imply the Accept header can
be used differently than described, and that you can just put any kind
of nonsense in there and still expect it to work.

> And if the server needs to respond with a 3xx, 4xx or 5xx response
> code, in principle it would not know how to do that if the request did
> not contain a range of content types.
>

I don’t understand how that would be. Different content types are just
different representations of data. A single resource can be represented
by several content types. If you’re going to indicate to the server that
you accept certain representations, then the server can send any of
them. However regardless of the content type, the server knows perfectly
well when a response of 3xx, 4xx or 5xx is needed for that resource
(e.g. when it has moved or is unavailable). They’re two separate things,
and unrelated.

I do not understand the resistance against just sending the correct
Accept headers. That is how the protocol is designed, and it’s also how
browsers implement it.

Also, you’re completely glossing over my statement that sending
incorrect Accept headers *breaks* servers which correctly handle content
negotiation, because the accepted content types are not correctly
indicated by the test. Thus, with this test the W3C would force web
sites to not use content negotiation if they want to get your label for
‘correctness’.

Related issues: (space separated ids)

WG Notes: Long thread on this. I (srowen) tend to agree. The change would be to specify that requests for <img src="..."/> only list image types in the accept header and so on. Propose that we rationalize this as an editorial bug fix, *or* accept this as a substantive change if there are already unavoidable other substantive changes, *or* punt if this is the only thing holding up final publication. 2007-10-31: I note that the following message from Laurens is the final exchange we had with Laurens regarding this comment, and in that message, he states, "But I still think it should be fixed." http://lists.w3.org/Archives/Public/public-bpwg-comments/2007OctDec/0001.html So we need to record this as "Commenter objected to disposition" and we need to be prepared to exmplain to the Director and others our rationale for not changing it it spite of the final objection from the commenter.

Resolution: Behavior as specified does not contravene HTTP. In practice, it is consistent with most mobile UAs behavior and is desirable on practical grounds for a tester to emulate. It should not be inferred from the way the checker behaves that real browsers either should or should not behave that way.

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