I18n comments on mobileOK Basic Tests 1.0

Lead reviewer

Felix Sasaki

Notes

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.

Comments

ID	Location	Subject	Comment	Followup	Ed. / Subs.
1	3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE	use of e.g.	[[ `Content-Type` header (e.g. "application/xhtml+xml;charset=UTF-8") XML declaration (e.g. "<?xml encoding="UTF-8"?>") `meta` element that is the first child of the document's `head` element, and whose `http-equiv` attribute is "Content-Type", and whose `content` attribute specifies a character encoding as above (e.g. "<meta http-equiv="Content-Type" content="application/xhtml+xml;charset=UTF-8"/>) ]] 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

Location

Subject

Comment

Followup

Ed. /
Subs.

Other threads