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

Comment Shortname:

Commenter: Jonathan Jeon <hollobit@etri.re.kr>

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:

3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE

The DDC is defined to support only UTF-8 encoding, which means that this test fails if a resource cannot be encoded in UTF-8. It is reasonable to recommend that default character encoding should use UTF-8. But it is not good that all of another character encoding except UTF-8 should be FAIL.

In many cases, if some country does not use English as a native language, they are using various character encoding schemes. For example, EUC is a multibyte character encoding system used primarily for Japanese, Korean, and simplified Chinese. The EUC-KR and EUC-JP(ISO-2022) encoding is heavily used in Korea and Japan. [1]

UTF-8 is not widely used in Korea. EUC-KR is more popular character encoding scheme in Korea (maybe more than 90% of Wired and Mobile web contents). It is the most widely used legacy character encoding in Korea on all three major platforms. Therefore, if we support only UTF-8, more than 90% of sites and contents will be ‘FAIL’.

So, it is proposed to consider additional character encodings. It is proposed to modify the section 3.3 as below:

PROPOSED TEXT:
------------------------
If the HTTP Content-Type header specifies a character encoding:
If character encoding is default-character-encoding, PASS
If character encoding is not default-character-encoding, warn
If the HTTP Content-Type header does not specify a character encoding:
If there is no XML declaration, or default character encoding or any character encoding is not specified in the XML declaration, FAIL
If the HTTP Content-Type header specifies an Internet media type starting with "text/":
If there is no meta element with http-equiv attribute that specifies default character encoding or any character encoding, FAIL
If character encoding is specified in more than one way, and not all values are the same, FAIL
If the document is not valid default character encoding or any character encoding (see 2.3.9 Validity), FAIL
For each resource specified by 2.3.6 Included Resources:
Request the resource
If the HTTP Content-Type header value of the response starts with "text/" but does not specify default character encoding or any character encoding character encoding, warn
PASS
------------------------

[1] http://lists.w3.org/Archives/Member/member-bpwg/2007Jul/0047.html

Related issues: (space separated ids)

WG Notes: Is it clear? It is not true that using another character encoding causes you to fail. mobileOK does *not* say you must use UTF-8 all the time. You could return EUC-KR to every single request except for the tester. It only says you must be able to do if necessary. Turned around, a site that can't return UTF-8 is unlikely to have a character encoding in common with devices outside its target market, and so will not be able to serve those devices at all. One goal of mobileOK is to promote interoperability. Great point -- phones designed for North America may not even have a Korean character set, in which case this is a moot point entirely. But the test is not for devices, but for the site; the requirement is to be able to return UTF-8 *if requested*, so that the site is taking all possible steps to communicate its content to the user agent. These ISSUEs should be turned into last call comments actually, which we can do, since mobileOK Basic Tests is in (second) last call at this point. I do not think the document will change on this point since the tests correspond to the Best Practices document which has long since been finalized, and it defines the assumed Default Delivery Context as supporting UTF-8 but not necessarily anything else.

Resolution: mobileOK Basic does not require use of UTF-8 in all cases; the test only verifies that you *can* use UTF-8 when requested. At this point we are not in a position to revise the DDC description in Mobile Web Best Pratices, and mobileOK Basic is intended to reflect what is in MWBP. It is useful to encourage all sites to support globally-interoperable encodings like UTF-8, even if they also support a more appropriate local encoding.

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