http://www.w3.org/TR/2007/WD-mobileOK-basic10-tests-20070130/
Felix Sasaki
These are comments on behalf of the I18N Core WG, unless otherwise stated. The Owner column indicates who has been assigned the responsibility of tracking discussions on a given comment.
We recommend that responses to the comments in this table use a separate email for each point. This makes it far easier to track threads.
To track discussion on a comment, search the public-i18n-list for the subject in the 3rd column. If the discussion breaks off into other relevant threads with a different subject, add appropriate search text to the last column.
ID | Location | Subject | Comment | Followup | Ed. / Subs. |
Other threads |
---|---|---|---|---|---|---|
1 | 3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE | use of e.g. |
[[
Since this test is testing for UTF-8 support, it should be made clearer that the reason 'e.g.' is used rather than 'i.e.' has to do with the other parts of the construct, rather than the encoding declaration itself. |
RI | E | |
2 | 3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE | UTF8 should be explicit |
[[If character encoding is not explicitly specified in at least one of these ways, FAIL]] Given the goals of this test, shouldn't this say "If the UTF-8 character encoding is not explicitly specified..." ? |
RI | S | |
3 | 3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE | encoding="ISO639" |
[[If character encoding is specified in more than one way, and not all values are the same, FAIL]] I'm not personally familiar with transcoding scenarios, but I've heard people often quoting them as justification for using the HTTP header to declare encodings and for the HTTP declaration to have higher precedence in HTML than the in-document declarations. As I understand it, the rationale is that a transcoding server can change the encoding of the document as it passes through, but doesn't change in the internal encoding declaraction. Since HTTP declarations beat in-document declarations, this is supposed to be OK. I've also heard that this kind of thing happens particularly when serving documents to mobile devices. If this is true, then I guess there must be occasions when it is permissible for the HTTP header declaration to be different from the other two? |
RI | S | |
4 | 3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE | Specifying script info |
[[If any character encoding specified is not "UTF-8", FAIL If the document is not valid UTF-8, FAIL]] How are people to test this? |
RI | S | |
5 | 3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE | Ref Multilingual Forms article |
It would be great if you could add a reference to the article Multilingual Forms. It contains among others a Perl regular expression testing for UTF-8. |
RI | S | |
6 | 3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE | 6.3.1 Annotation element |
A personal comment from Felix Sasaki, not endorsed by the i18n core WG. [[For each external resource as defined in 2.3.5 Included Resources: Request the URI indicated by the href attribute If the HTTP response Content-Type header value specifies an Internet media type starting with "text/" but does not specify UTF-8 encoding (e.g. "text/css" only instead of "text/css;charset=UTF-8"), warn PASS]] Should a @charset rule in an included CSS stylesheet be taken into account? I.e., should there also be a warning if such a rule specifies an encoding different that UTF-8? |
FS | S |
Version: $Id: Overview.html,v 1.4 2007/07/25 17:05:54 rishida Exp $