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

Quick access to LC-1690 LC-1691 LC-1692 LC-1693 LC-1694 LC-1695 LC-1696 LC-1697 LC-1698 LC-1699 LC-1700 LC-1701 LC-1702 LC-1703 LC-1704 LC-1705 LC-1706 LC-1707 LC-1708 LC-1709 LC-1710 LC-1711 LC-1712 LC-1713 LC-1714 LC-1715 LC-1716 LC-1717 LC-1718 LC-1719 LC-1720 LC-1721 LC-1722 LC-1723 LC-1724 LC-1725 LC-1726 LC-1727 LC-1728 LC-1729 LC-1730 LC-1731 LC-1732 LC-1733 LC-1734 LC-1735 LC-1736 LC-1737 LC-1738 LC-1739 LC-1740 LC-1741 LC-1742 LC-1743 LC-1744 LC-1745 LC-1746 LC-1747 LC-1748 LC-1749 LC-1750 LC-1751 LC-1752 LC-1753 LC-1754 LC-1755 LC-1756 LC-1757 LC-1758 LC-1759 LC-1760 LC-1761 LC-1762 LC-1763 LC-1764 LC-1765 LC-1766 LC-1767 LC-1781 LC-1782 LC-1783 LC-1786

Comment LC-1690

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 25 May 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 Validity of the Tests 2.2 Testing Outcomes 2.3 Conduct of Tests 2.3.1 Order of Tests 2.3.2 HTTP Request 2.3.3 HTTP Response 2.3.4 Meta http-equiv Elements 2.3.5 CSS Style 2.3.6 Included Resources 2.3.7 Included Style Sheet Resources 2.3.8 Visible Linked Resources 2.3.9 Validity 2.3.10 White Space 3 mobileOK Basic Tests 3.1 AUTO_REFRESH (partial) 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 (partial) 3.15 OBJECTS_OR_SCRIPT (partial) 3.16 PAGE_SIZE_LIMIT 3.17 PAGE_TITLE (partial) 3.18 POP_UPS 3.19 PROVIDE_DEFAULTS (partial) 3.20 STYLE_SHEETS_SUPPORT (partial) 3.21 STYLE_SHEETS_USE 3.22 TABLES_ALTERNATIVES 3.23 TABLES_LAYOUT (partial) 3.24 TABLES_NESTED A Acknowledgements(Non-Normative) B References(Non-Normative) BestPractices CSS GIF JPEG POWDER RFC2617 Techniques UTF-8 utf8_perl 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:

First, section 2.3.2 HTTP Request states:

> *
>
> Include an |Accept| header indicating that Internet media types
> understood by the default delivery context are accepted by
> sending exactly this header:
>
> Accept: application/xhtml+xml,text/html;q=0.1,application/vnd.wap.xhtml+xml;q=0.1,text/css,image/jpeg,image/gif
>
>

I think this is incorrect, text/css should NOT be included in the Accept
header, and image/jpeg and image/gif ONLY if the UA is expected to
support showing these images independantly of a document (the mobileOK
tests should explicitly check whether this is supported). The client
after all does not know how to handle a text/css file independently of
XML markup.

Instead, it should send an "Accept: text/css" header when the CSS files
that are linked using <link rel="stylesheet">, <?xml-stylesheet?> or
@include. Similarly, images referenced from <img> should send an
"Accept: image/jpeg,image/gif" header. Aside from checking the Accept
header for the main page, the mobileOK tests should also check that
Accept headers send these values for stylesheet and image requests.

Related issues: (space separated ids)

WG Notes: It's an interesting point. RFC 2616 says in 14.1 that Accept *can* indicate desired types this way, and 10.4.7 says that servers can even return a type not listed in the Accept header in some cases. I bring it up to make the point that Accept seems to be advice, and doesn't have to exactly enumerate acceptable types. It seems standard practice that user agents send a fixed string listing all of what they support each time. Finally it's conceivable that one might vary a document a little bit based on other types in the Accept header, like linking to JPEG versus PNG images in an <img> tag. I don't know that this is at all common though. If it's not wrong, and mimics real-world user agents a little more, we'd very slightly prefer to keep the fixed Accept header as-is.

Resolution: We do not think it is wrong to specify the headers in the way we do, however we accept that we do not properly check that the right sort of content has come back in response to the request. In other words, if the request is made because of an img tag then the response should be an image. We did not test for that in the draft you reviewed and we will amend accordingly. In particular, in 3.4, <img> tags that retrieve valid CSS delivered as text/css should for example FAIL too.

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