Internationalization Comments on HTML5

Dates of comments: feb 2008 to sep 2010

The WG column indicates whether these are comments on behalf of the Internationalization Core WG. The "Owner" column indicates who has taken the responsibility of tracking discussions on a given comment. Orange shading signifies that the comment is unresolved.

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. Click on the icons in the right-most column to see email discussions.

You can edit this page by clicking on Edit Table (right), then using the buttons that appear in the right-most column and the forms below the table. It doesn't actually change the text on the server. For that, hit the Create Source Code button near the bottom of the page and use the resulting text to edit the page or send to someone for editing.

ID	Location	Subject	Comment	Owner	WG	Ed. / Subs.
1	3.2.3.5 The dir attribute	Rendering bidi without a style sheet	"The processing of this attribute depends on the presentation layer. For example, CSS 2.1 defines a mapping from this attribute to the CSS 'direction' and 'unicode-bidi' properties, and defines rendering in terms of those properties." We think that HTML 5, like HTML 4, should be able to render bidirectional text without a style sheet. It would break backwards compatibility to remove the ability of a browser to do so without CSS. Therefore in our opinion, HTML 5 has to describe the expected behavior in at least the detail of HTML 4 rather than leave it up to the "presentation layer". Note that we do not want to impose a requirement on implementations of HTML 5 to implement CSS, but you could describe the expected behaviour by just referencing CSS and defining a default stylesheet fragment. This would just mean that an HTML 5 implementation has to make things behave as if it used this CSS default stylesheet fragment	RI	Y	S
2	4.6.21 The bdo element	bdo element doesn't leave rendering up to presentation layer	"If the element has the dir attribute set to the exact value ltr, then for the purposes of the bidi algorithm, the user agent must act as if there was a U+202D LEFT-TO-RIGHT OVERRIDE character at the start of the element, and a U+202C POP DIRECTIONAL FORMATTING at the end of the element." "If the element has the dir attribute set to the exact value rtl, then for the purposes of the bidi algorithm, the user agent must act as if there was a U+202E RIGHT-TO-LEFT OVERRIDE character at the start of the element, and a U+202C POP DIRECTIONAL FORMATTING at the end of the element." The section about the <bdo> element does not leave the expected behavior completely up to the presentation layer - which is confusing. Content authors need to know if they should use CSS, if CSS would override the specified behavior etc.	RI	Y	S
3	3.2.3.5 The dir attribute	Add note about using bidi constructs in content	We propose that you add a note making clear that using the directional markup provided by HTML5 is is better than attaching CSS styling to arbitrary markup such as <p> etc., since information encoded in this way will apply to the content whether the CSS is used or not.	RI	Y	E
4	3.2.3.5 The dir attribute	rlo and lro attribute values	Please consider allowing two new attribute values for the "dir" attribute: 'rlo' and 'lro' for dir. You do not need to remove the bdo element, but the new values will allow content authors to proceed to a scenario we described in the ITS 1.0 specification, It will also provide some additional power to the authors, since they will be able to attach dir="lro" to a block element.	RI	Y	S
5	4.2.5.3 Pragma directives	what's the language of a document	Our proposal is as follows and is based on the text of the following sections: http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#document-wide-default-language http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#the-lang-and-xml:lang-attributes [1] Explain clearly that declarations in the http header and the meta element refer to the document as an object, rather than the text in a specific element (this is what makes the distinction between single and multiple values sensible). [2] Continue to recommend that the document-wide default language be defined by a lang attribute on the html tag, but say that if the lang attribute is missing and there is a language defined in the http or meta, then those language declarations can be used to guess the language of the text, if they contain a single value. [3] Establish the precedence between http vs meta. [4] Establish the rule that multiple values in the place that has precedence equates to lang="". This is very close to what we already have, but doesn't try to make the meta declaration a different thing than the http declaration, or change it so that multiple values are no longer valid. At the same time, it allows either the http or the meta to provide language information for text-processing, if the declaration is useable. We also feel that the spec seems to restrict the use of the term 'document-wide default language' to refer only to a language declared using the meta, and this is rather odd. We feel that in fact the lang attribute on the html element also establishes a document-wide default language. (See the text: "Until the pragma is successfully processed, there is no document-wide default language.") Update: This comment became part of ISSUE-88.	RI	Y	S
6	4.6.18 The ruby element	ruby code samples	The code samples in the ruby section are misleading because they show white-space between the components that should not be there. eg. ... <ruby> 漢 <rt> かん </rt> 字 <rt> じ </rt> </ruby> ... Either show the examples as the code should look, eg. ... <ruby>漢<rt>かん</rt>字<rt>じ</rt></ruby> ... or add a note to say that the extra white space is there to show the structure clearly, but should not be copied. Similar comments apply to the examples in the rp section that follows.	RI	-	E
7	4.6.18 The ruby element	Please add support for rb	In all the web sites that we looked at that currently use ruby markup in the wild, over 90% of code uses the rb tag. The current HTML5 model for ruby simplifies the code generally, but making the rb element obsolete will make most existing ruby code non-conformant and make it more difficult to copy code that follows the Ruby Annotation model, from XML or other formats, into HTML5. Please allow optional use of the rb element as part of the HTML5 model.	RI	-	E
8	4.2.5.5 Specifying the document's character encoding	Allow utf-16 encoding declarations	Currently you are not allowed to use <meta charset="utf-16"> or the equivalent pragma directive in utf-16 encoded documents. While logically it is not needed to identify the character encoding, it introduces a special case for authors to remember, and almost certainly many authors will be unaware that this is disallowed and will do it. In addition, in-document declarations of this kind are particularly useful for developers, testers, or translation production managers who want to visually check the encoding of a document (since the bom cannot be seen). Furthermore, there would appear to be no risk incurred by allowing this, since the document would be encoded in utf-16 anyway. Note that the ask is not that the encoding of the document be determined by the meta element - the bom remains the way of determining that information - solely that no error or warning be raised if the meta element is used. Please make an exception in the spec for utf-16 so that it is allowed to use <meta charset="utf-16"> or the equivalent pragma directive in utf-16 encoded documents.	RI	-	E

Location

Subject

Comment

Owner

Ed. /
Subs.

Mail

3.2.3.5 The dir attribute

Rendering bidi without a style sheet

"The processing of this attribute depends on the presentation layer. For example, CSS 2.1 defines a mapping from this attribute to the CSS 'direction' and 'unicode-bidi' properties, and defines rendering in terms of those properties."

We think that HTML 5, like HTML 4, should be able to render bidirectional text without a style sheet. It would break backwards compatibility to remove the ability of a browser to do so without CSS. Therefore in our opinion, HTML 5 has to describe the expected behavior in at least the detail of HTML 4 rather than leave it up to the "presentation layer".

Note that we do not want to impose a requirement on implementations of HTML 5 to implement CSS, but you could describe the expected behaviour by just referencing CSS and defining a default stylesheet fragment. This would just mean that an HTML 5 implementation has to make things behave as if it used this CSS default stylesheet fragment

4.6.21 The bdo element

bdo element doesn't leave rendering up to presentation layer

"If the element has the dir attribute set to the exact value ltr, then for the purposes of the bidi algorithm, the user agent must act as if there was a U+202D LEFT-TO-RIGHT OVERRIDE character at the start of the element, and a U+202C POP DIRECTIONAL FORMATTING at the end of the element."

"If the element has the dir attribute set to the exact value rtl, then for the purposes of the bidi algorithm, the user agent must act as if there was a U+202E RIGHT-TO-LEFT OVERRIDE character at the start of the element, and a U+202C POP DIRECTIONAL FORMATTING at the end of the element."

The section about the <bdo> element does *not* leave the expected behavior completely up to the presentation layer - which is confusing. Content authors need to know if they should use CSS, if CSS would override the specified behavior etc.

3.2.3.5 The dir attribute

Add note about using bidi constructs in content

We propose that you add a note making clear that using the directional markup provided by HTML5 is is better than attaching CSS styling to arbitrary markup such as <p> etc., since information encoded in this way will apply to the content whether the CSS is used or not.

3.2.3.5 The dir attribute

rlo and lro attribute values

Please consider allowing two new attribute values for the "dir" attribute: 'rlo' and 'lro' for dir. You do not need to remove the bdo element, but the new values will allow content authors to proceed to a scenario we described in the ITS 1.0 specification, It will also provide some additional power to the authors, since they will be able to attach dir="lro" to a block element.

4.2.5.3 Pragma directives

what's the language of a document

Our proposal is as follows and is based on the text of the following sections:

http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#document-wide-default-language

http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#the-lang-and-xml:lang-attributes

[1] Explain clearly that declarations in the http header and the meta element refer to the document as an object, rather than the text in a specific element (this is what makes the distinction between single and multiple values sensible).

[2] Continue to recommend that the document-wide default language be defined by a lang attribute on the html tag, but say that if the lang attribute is missing and there is a language defined in the http or meta, then those language declarations can be used to guess the language of the text, if they contain a single value.

[3] Establish the precedence between http vs meta.

[4] Establish the rule that multiple values in the place that has precedence equates to lang="".

This is very close to what we already have, but doesn't try to make the meta declaration a different thing than the http declaration, or change it so that multiple values are no longer valid. At the same time, it allows either the http or the meta to provide language information for text-processing, if the declaration is useable.

We also feel that the spec seems to restrict the use of the term 'document-wide default language' to refer only to a language declared using the meta, and this is rather odd. We feel that in fact the lang attribute on the html element also establishes a document-wide default language. (See the text: "Until the pragma is successfully processed, there is no document-wide default language.")

Update: This comment became part of ISSUE-88.

4.6.18 The ruby element

ruby code samples

The code samples in the ruby section are misleading because they show white-space between the components that should not be there.

eg.

...

<ruby>

漢 <rt> かん </rt>

字 <rt> じ </rt>

</ruby>

...

Either show the examples as the code should look, eg.

...

...

or add a note to say that the extra white space is there to show the structure clearly, but should not be copied.

Similar comments apply to the examples in the rp section that follows.

4.6.18 The ruby element

Please add support for rb

In all the web sites that we looked at that currently use ruby markup in the wild, over 90% of code uses the rb tag. The current HTML5 model for ruby simplifies the code generally, but making the rb element obsolete will make most existing ruby code non-conformant and make it more difficult to copy code that follows the Ruby Annotation model, from XML or other formats, into HTML5.

Please allow optional use of the rb element as part of the HTML5 model.

4.2.5.5 Specifying the document's character encoding

Allow utf-16 encoding declarations

Currently you are not allowed to use <meta charset="utf-16"> or the equivalent pragma directive in utf-16 encoded documents. While logically it is not needed to identify the character encoding, it introduces a special case for authors to remember, and almost certainly many authors will be unaware that this is disallowed and will do it. In addition, in-document declarations of this kind are particularly useful for developers, testers, or translation production managers who want to visually check the encoding of a document (since the bom cannot be seen). Furthermore, there would appear to be no risk incurred by allowing this, since the document would be encoded in utf-16 anyway.

Note that the ask is not that the encoding of the document be determined by the meta element - the bom remains the way of determining that information - solely that no error or warning be raised if the meta element is used.

Please make an exception in the spec for utf-16 so that it is allowed to use <meta charset="utf-16"> or the equivalent pragma directive in utf-16 encoded documents.

Related links

Manage page

Internationalization Comments on HTML5

Edit/create a comment

Source dump

Dump all source