W3C   W3C Internationalization (I18n) Activity: Making the World Wide Web truly world wide!

Related links

Other reviews

Review radar

Core WG home page

Manage page

Internationalization Comments on HTML5

Date of latest comments: 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.
Mail  
1undefinednew attribute: ubi

Expose in HTML the new "isolate" value added to the unicode-bidi style in CSS3 (http://dev.w3.org/csswg/css3-text-layout/#unicode-bidi), by adding an element attribute tentatively named ubi, for "Unicode Bidi Isolate", as in <span dir="rtl" ubi>.

This is a part of the proposals made by the "Additional Requirements for Bidi in HTML" W3C First Public Working Draft. For a full description of the use cases, please see http://www.w3.org/International/docs/html-bidi-requirements/#bidi-isolation. Here is the proposal made there:

The ubi attribute directionally isolates an inline-display element from its surroundings: neither will affect the bidi ordering of the other, and no part of the surrounding content will get ordered between parts of the element's content. Furthermore, the effects of LRE, RLE, LRO, RLO, and PDF characters appearing in the element never extend beyond it.

This is achieved (via unicode-bidi:isolate) by treating the contents of the element as a separate, independent "paragraph" or paragraphs for the purposes of the bidi resolution within the element. These paragraphs' base direction is the element’s computed direction. For the purpose of the bidi resolution of the element as a whole in its containing paragraph (if any), the element is treated as if it were an Object Replacement Character (U+FFFC).

The attribute would take three values:

- "off", specifying no special action. This is the default except in the two cases indicated below (for which "off" would have to be explicitly specified when no isolation is desired). There is no inheritance.

- "ubi", specifying isolation. (Alternatively, this value could be named "on". We chose "ubi" for similarity with pre-HTML5 boolean attributes, e.g. selected. It is up to the HTML WG to decide which is better.) It is implemented by setting the unicode-bidi CSS property for the element to "isolate" - or "isolate bidi-override" for a <bdo> element. It is the default value for:

  * Elements whose dir attribute value is "auto" (which is being proposed in a separate bug).

  * Block elements with CSS display:inline (for discussion, see http://www.w3.org/International/docs/html-bidi-requirements/#blocks-as-separators).

- empty string, specifying isolation just like the "ubi" value. The empty string value allows specifying the attribute without a value for conciseness, e.g. <span dir="rtl" ubi>.

Applications generating HTML would use ubi routinely on elements that wrap an inserted data string (usually in conjunction with indicating its direction using the dir attribute). In particular, it will be recommended to use ubi on the <a> element once any browsers support it. It is the anticipated frequency of use that mandated the somewhat cryptic but blessedly short name and syntax: ubi.

Although in theory unicode-bidi:isolate could be used directly to achieve the same effect as ubi, the recommended approach will be to use ubi, since the bidi properties of content are an intimate part of the content and should be specified directly on it as HTML mark-up. They are not simply an issue of presentation that should properly be specified separately in CSS. The new unicode-bidi:isolate CSS property value has been added because, like the dir attribute, the ubi attribute has to be implemented via CSS.

BUG 10807

Implementation status

ALYS Link to mail thread
2undefinednew dir attribute value: auto, and a new attribute: autodirmethod

Make simple direction estimation functionality available in the browser by allowing the dir attribute to take on a new "auto" value indicating that the user agent is responsible for estimating the direction of the element's contents according to an algorithm specified by a new attribute, autodirmethod=first-strong|any-rtl.

This is a part of the proposals made by the "Additional Requirements for Bidi in HTML" W3C First Public Working Draft. For a full description of the use cases and the details of this proposal, please see http://www.w3.org/International/docs/html-bidi-requirements/#auto-direction.

In addition, also allow a third autodirmethod value, "plaintext", which would estimate the direction of each UBA paragraph in the element separately. This is intended primarily for the <textarea> and <pre> elements, where taking as input and displaying (mostly plain) text consisting of paragraphs with different directions is a fairly common need. The CSS3 spec already provides support for this feature via a new unicode-bidi value, "plaintext" (http://dev.w3.org/csswg/css3-text-layout/#unicode-bidi). However, some aspects of the feature still need to be worked out at this time.

BUG 10808

BUG 11734

Implementation status

ALYS Link to mail thread
3undefinednew attribute: submitdir

This is a part of the proposals made by the "Additional Requirements for Bidi in HTML" W3C First Public Working Draft. For a full description of the use cases, please see http://www.w3.org/International/docs/html-bidi-requirements/#reporting-direction. Here is the proposal made there:

Support a new attribute, tentatively named submitdir, in <input> and <textarea>. Its presence will specify that when the element is a "successful control" (i.e. its value is to be included in the form submission), then the value of the element's computed direction (at submission time) is also to be included in the submission, as an additional "successful control". (Reminder: the computed direction is the bottom-line "ltr" or "rtl" being used to display the element; it never takes on any other value. It is available as the value of the CSS direction property for the element.)

The additional control's name is to be the element's control name suffixed with "_dir". If the form contains other control(s) with the same control name as the additional control, the additional control will still be submitted alongside them; it is up to the application to sort out what the different control values mean.

The value of the submitdir attribute is immaterial; it would normally be an empty string (when the attribute is present without a value) or "submitdir".

For example, let's assume that a dir attribute value to indicate direction estimation is "auto", and an RTL page contains the following form:

<form action="foo" method="get">

<input type="text" name="mytest" dir="auto" submitdir />

</form>

Then, if the user typed in the LTR value "hello", the submission URL would be "foo?mytest=hello&mytest_dir=ltr".

BUG 10809

Implementation status

ALYS Link to mail thread
4undefinednew attribute: bidibreak

This is a part of the proposals made by the "Additional Requirements for Bidi in HTML" W3C First Public Working Draft. For a full description of the use cases, please see http://www.w3.org/International/docs/html-bidi-requirements/#br-as-separator. Here is the proposal made there:

Support a new HTML element attribute, bidibreak=hard|soft. On a <br> element, the "soft" value means that the <br> is to be treated as a UBA bidi class WS (whitespace) character, as was required in HTML 4. The "hard" value means that the <br> is to be treated as UBA bidi class B, i.e. paragraph break. If neither is specified, the bidibreak attribute value is inherited from the parent. Thus, when specified on an element other than <br>, bidibreak serves to determine the behavior of descendant <br> elements. For the root element, the default is "hard" (which, of course, spreads to every <br> element in the document, unless an intervening element sets bidibreak otherwise).

Alternatively, if and only if all major browser makers reach unanimous consensus that the default value for the root element should be "soft" and commit to implementing it as such to the HTML WG prior to the new HTML specification publication, that too would be fine.

When the author wants to use <br> just to wrap a line without adding bidi separation, <br bidibreak="soft"> will do the trick.

Reasonable use cases for specifying bidibreak="soft" on non-<br> elements would include an element containing poetry, as well as the root element of a document that relies on the bidi behavior specified for <br> by HTML 4.

When <br> introduces a UBA paragraph break, the base direction of the new UBA paragraph will be determined by the computed direction of the nearest ancestor element whose bidi properties require its contents to be in a separate UBA paragraph (or sequence of paragraphs), e.g. a block element or an element directionally isolated by the ubi attribute (which is being proposed in a separate bug). Furthermore, for every element between there and the <br> that results in the creation of an embedding or override level, e.g. a <bdo> element or any element with a dir attribute or a value other than "normal" for the unicode-bidi CSS property, the correspondeng embedding or override level is re-introduced at the start of the new UBA paragraph (to be closed at the end of the element or the UBA paragraph, whichever comes first).

BUG 10828

BUG 11211

Implementation status

ALYS Link to mail thread
5undefinedU+2028 and U+2029 in textarea and pre elements

This is a part of the proposals made by the "Additional Requirements for Bidi in HTML" W3C First Public Working Draft. For a full description of the use cases, please see http://www.w3.org/International/docs/html-bidi-requirements/#newline-as-separator. Here is the proposal made there:

In elements where line breaks are not collapsed, e.g. <textarea> and elements with white-space:pre|pre-line|pre-wrap, the LINE SEPARATOR (U+2028) and PARAGRAPH SEPARATOR (U+2029) characters should also break lines. PARAGRAPH SEPARATOR characters in these elements should constitute UBA paragraph breaks, while LINE SEPARATOR characters should constitute UBA whitespace.

When PARAGRAPH SEPARATOR introduces a UBA paragraph break, the base direction of the new UBA paragraph will be determined by the computed direction of the nearest ancestor element whose bidi properties require its contents to be in a separate UBA paragraph (or sequence of paragraphs), e.g. a block element or an element directionally isolated by the ubi attribute (which is being proposed in a separate bug). Furthermore, for every element on the path in between that results in the creation of an embedding or override level, e.g. a <bdo> element or any element with a dir attribute or a value other than "normal" for the unicode-bidi CSS property, the correspondeng embedding or override level is re-introduced at the start of the new UBA paragraph (to be closed at the end of the element or the UBA paragraph, whichever comes first).

BUG 10810

Implementation status

ALYS Link to mail thread
6undefinedU+2028 and U+2029 in dialog text

This is a part of the proposals made by the "Additional Requirements for Bidi in HTML" W3C First Public Working Draft. For a full description of the use cases, please see http://www.w3.org/International/docs/html-bidi-requirements/#newline-as-separator. Here is the proposal made there:

The LINE SEPARATOR (U+2028) and PARAGRAPH SEPARATOR (U+2029) characters in the plain text displayed by the page's scripts using functions such as Javascript's alert() and confirm() should break lines. PARAGRAPH SEPARATOR characters in these elements should constitute UBA paragraph breaks, while LINE SEPARATOR characters should constitute UBA whitespace, as defined by the Unicode standard.

BUG 10811

Implementation status

ALYS Link to mail thread
7undefinedline breaks in textarea and pre elements

This is a part of the proposals made by the "Additional Requirements for Bidi in HTML" W3C First Public Working Draft. For a full description of the use cases, please see http://www.w3.org/International/docs/html-bidi-requirements/#newline-as-separator. Here is the proposal made there:

In elements where line breaks are not collapsed, e.g. <textarea> and elements with white-space:pre|pre-line|pre-wrap, line breaks should constitute UBA paragraph breaks.

When a line break introduces a UBA paragraph break, the base direction of the new UBA paragraph will be determined by the computed direction of the nearest ancestor element whose bidi properties require its contents to be in a separate UBA paragraph (or sequence of paragraphs), e.g. a block element or an element directionally isolated by the ubi attribute (which is being proposed in a separate bug). Furthermore, for every element on the path in between that results in the creation of an embedding or override level, e.g. a <bdo> element or any element with a dir attribute or a value other than "normal" for the unicode-bidi CSS property, the correspondeng embedding or override level is re-introduced at the start of the new UBA paragraph (to be closed at the end of the element or the UBA paragraph, whichever comes first).

BUG 10812

BUG 11502

Implementation status

ALYS Link to mail thread
8undefinedline breaks in dialog text

This is a part of the proposals made by the "Additional Requirements for Bidi in HTML" W3C First Public Working Draft. For a full description of the use cases, please see http://www.w3.org/International/docs/html-bidi-requirements/#newline-as-separator. Here is the proposal made there:

Line breaks in the plain text displayed by the page's scripts using functions such as Javascript's alert() and confirm() should constitute UBA paragraph breaks.

BUG 10813

Implementation status

ALYS Link to mail thread
9undefinedblock-display elements should act as UBA paragraph breaks

This is a part of the proposals made by the "Additional Requirements for Bidi in HTML" W3C First Public Working Draft. For a full description of the use cases, please see http://www.w3.org/International/docs/html-bidi-requirements/#blocks-as-separators. Here is the proposal made there:

An element with display:block, except when it has been taken out of document flow with CSS such as float or position:absolute, but regardless of whether it is a block element or inline element, should be specified as introducing a UBA paragraph break between the content preceding and following it. This does not present a problem for backward compatibility because there has been no browser interoperability in this respect.

If the display:block element has display:inline ancestors that have bidi properties (e.g. the dir attribute or the <bdo> element), these bidi properties should be applied to the anonymous block boxes created for these ancestors, in accordince with CSS specs for anonymous block boxes.

BUG 10814

BUG 11829

Implementation status

ALYS Link to mail thread
10undefinedblock elements with display:inline should get ubi instead of default dir

This is a part of the proposals made by the "Additional Requirements for Bidi in HTML" W3C First Public Working Draft. For a full description of the use cases, please see http://www.w3.org/International/docs/html-bidi-requirements/#blocks-as-separators. Here is the proposal made there:

At one time, all browsers treated block elements that have been given display:inline in CSS as an ordinary inline element for bidi purposes, (i.e. gave no special treatment). One use case for using display:inline on block elements is getting an inline auto-numbered list with <ol style "display:inline">. To get bidi treatment of such use cases, HTML 4 explicitly specified (http://www.w3.org/TR/REC-html40/struct/dirlang.html#style-bidi): "When a block element that does not have a dir attribute is transformed to the style of an inline element by a style sheet, the resulting presentation should be equivalent, in terms of bidirectional formatting, to the formatting obtained by explicitly adding a dir attribute (assigned the inherited value) to the transformed element". The intent was to prevent the bidi ordering within such an element from being affected by the element's surroundings, as it would not be affected if it still had block display. To date, the only browser to implement this specification is Firefox.

Unfortunately, this condition does not go far enough, since adding a dir attribute to an inline element does not prevent it from affecting the bidi ordering of its surroundings in ways that a separate block would not.

A separate bug defining the ubi attribute specifies that the default ubi attribute value for a block element with display:inline shall be "ubi", isolating the element directionally from its surroundings. This is meant as an improvement on the condition mentioned above. Thus, the condition above should be removed from the HTML specification.

A nice side-effect of this change is that when display:inline block element is explicitly given ubi=off, it will be displayed the way it had been before this condition was added to the HTML specification and the way it is currently displayed in all major browsers except Firefox.

These changes do not present a problem for backward compatibility because the HTML 4 specification was never implemented in this respect by most browsers.

BUG 10815

Implementation status

ALYS Link to mail thread
11undefineddefault ignorable code points

The HTML specification should require user agents to implement the Unicode spec re Default Ignorable Code Points (Unicode Standard version 5.2, Chapter 5 (http://unicode.org/versions/Unicode5.2.0/ch05.pdf), section 5.21), including never displaying the directional formatting characters (LRM, RLM, LRE, RLE, LRO, RLO, and PDF) inappropriately (e.g. as empty boxes or advance widths) even if the underlying platform does not handle them properly. In particular, this must be the case for script dialog text, page titles, and tooltips.

Currently, directional formatting characters are most often displayed inappropriately in these context, since user agents mostly rely on the operating system to display the text in these contexts correctly, which does not happen because most LTR users' machines do not have RTL characters support installed. As a result, web applications are unable to use directional formatting characters around LTR text to make sure it is displayed correctly in an RTL context, since doing so will make it display incorrectly in the far more common LTR context.

BUG 10816

Implementation status

ALYS Link to mail thread
12undefinedtitle element should support and inherit dir attribute

The HTML specification should explicitly state that <title> text will be displayed in the <title>'s computed direction.

This is a part of the proposals made by the "Additional Requirements for Bidi in HTML" W3C First Public Working Draft. For a full description of the use cases, please see http://www.w3.org/International/docs/html-bidi-requirements/#title-and-dir.

BUG 10817

Implementation status

ALYS Link to mail thread
14undefinedtitle and alt attribute direction and two new attributes: titledir and altdir

This is a part of the proposals made by the "Additional Requirements for Bidi in HTML" W3C First Public Working Draft. For a full description of the use cases, please see http://www.w3.org/International/docs/html-bidi-requirements/#title-and-alt. Here is the proposal made there:

Support two new attributes, titledir=ltr|rtl|auto and altdir=ltr|rtl|auto that, when present, specify the title and alt attributes' direction, respectively. (The values should have the same meaning as for the dir attribute, including the "auto" value's reliance on the autodirmethod's value.) In titledir's and altdir's absence, respectively, title and alt attribute text will be displayed in the element's computed direction, as should be stated in the specification.

BUG 10818

Implementation status

ALYS Link to mail thread
15undefinedoption element should support the dir attribute and be displayed accordingly both in the dropdown and after being chosen

This is a part of the proposals made by the "Additional Requirements for Bidi in HTML" W3C First Public Working Draft. For a full description of the use cases, please see http://www.w3.org/International/docs/html-bidi-requirements/#option. Here is the proposal made there:

The HTML specification should explicitly state that the <option> element's computed direction will take its dir attribute (explicit or inherited) into account, and will be used to display the option's text in both the dropdown and after being chosen.

BUG 10819

Implementation status

ALYS Link to mail thread
16undefinedoption element should support text-align CSS property and be displayed accordingly both in the dropdown and after being chosen

This is a part of the proposals made by the "Additional Requirements for Bidi in HTML" W3C First Public Working Draft. For a full description of the use cases, please see http://www.w3.org/International/docs/html-bidi-requirements/#option. Here is the proposal made there:

The HTML specification should explicitly state that the <option> element's alignment via CSS or the align attribute will affect its display accordingly in both the dropdown and after being chosen.

BUG 10820

Implementation status

ALYS Link to mail thread
17undefinedsetting input and textarea element direction through browser UI should set the dir attribute and trigger oninput event

This is a part of the proposals made by the "Additional Requirements for Bidi in HTML" W3C First Public Working Draft. For a full description of the use cases, please see http://www.w3.org/International/docs/html-bidi-requirements/#set-direction. Here is the proposal made there:

The HTML specification should state that when the user agent user interface allows the user to set the direction of <input> and <textarea> elements, it will:

- Set the element's dir attribute value accordingly.

- Trigger the oninput event after the dir attribute has been set. Even though no actual input took place, the user changed the recommended interpretation of the input already collected.

BUG 10821

Implementation status

ALYS Link to mail thread
18undefinedon an OS that has a widespread UI convention for setting direction, user agent should support it on input and textarea elements

This is a part of the proposals made by the "Additional Requirements for Bidi in HTML" W3C First Public Working Draft. For a full description of the use cases, please see http://www.w3.org/International/docs/html-bidi-requirements/#set-direction. Here is the proposal made there:

The HTML specification should recommended that on an OS that has a widespread convention for setting direction (such as CTRL + LEFT SHIFT for LTR and CTRL + RIGHT SHIFT for RTL on Windows), the user agent should support that convention on input and textarea elements (although it may provide other methods too).

BUG 10822

Implementation status

ALYS Link to mail thread
19undefinedwhen an input value is remembered, its direction should be remembered too

This is a part of the proposals made by the "Additional Requirements for Bidi in HTML" W3C First Public Working Draft. For a full description of the use cases, please see http://www.w3.org/International/docs/html-bidi-requirements/#remember-input-dir. Here is the proposal made there:

The HTML specification should state that whenever a user agent stores a user-provided <input> or <textarea> text value for later use (such as auto-completion), it should also store the nominal direction value the element had when displaying this value. This may be the original direction of the element, or may have been set by the user for that value via the user agent's UI, or may have been set for that value by page scripts. If the user agent later recalls and displays this value, e.g. in an auto-completion dropdown, it should be displayed in its stored direction. If the value is assigned to an element, the element's dir value should be set to its stored direction.

BUG 10823

Implementation status

ALYS Link to mail thread
20undefinedlist item marker display and position

This is a part of the proposals made by the "Additional Requirements for Bidi in HTML" W3C First Public Working Draft. For a full description of the use cases, please see http://www.w3.org/International/docs/html-bidi-requirements/#lists. Here is the proposal made there:

The HTML specification should state that, by default, the markers of all "list-style-position:outside" items should disregard the list item element's computed direction, using the list element's computed direction instead for the marker's display and positioning.

CSS will provide means to control this. If the CSS default in this respect must differ, the default stylesheet should achieve the default behavior specified above.

Furthermore, the list marker text will be directionally isolated from the list item text, appearing in its own UBA paragraph.

ALYS Link to mail thread
21undefinedlocation of user agent window's overall vertical scrollbar

This is a part of the proposals made by the "Additional Requirements for Bidi in HTML" W3C First Public Working Draft. For a full description of the use cases, please see http://www.w3.org/International/docs/html-bidi-requirements/#vertical-scrollbar. Here is the proposal made there:

The HTML and CSS specifications should state that the user agent window's overall vertical scrollbar should be located independent of the direction of any page element, despite being otherwise controlled by the style of the <body> element. (Thus, it should be located on the the "end" side relative to the user agent chrome direction.)

BUG 10825

Implementation status

ALYS Link to mail thread
22undefinedlocation of an element's vertical scrollbar when it is not the user agent window's overall vertical scrollbar

This is a part of the proposals made by the "Additional Requirements for Bidi in HTML" W3C First Public Working Draft. For a full description of the use cases, please see http://www.w3.org/International/docs/html-bidi-requirements/#vertical-scrollbar-below-body. Here is the proposal made there:

The HTML and CSS specifications should state that the vertical scrollbar of an element below <body> and of the <body> element of a document being displayed in a frame or iframe should be on the "end" side relative to the element's direction.

BUG 10826

Implementation status

ALYS Link to mail thread
23undefinedscript dialog text direction

This is a part of the proposals made by the "Additional Requirements for Bidi in HTML" W3C First Public Working Draft. For a full description of the use cases, please see http://www.w3.org/International/docs/html-bidi-requirements/#script-dialog. Here is the proposal made there:

The HTML specification should state that plain text passed by page scripts without specifying an explicit direction to whatever services script languages provide for dialog display (e.g. Javascript's alert(), confirm() and prompt()) should be displayed according to the UBA's rules P1, P2, and P3, which estimate the direction of each paragraph according to its first strong character.

BUG 10827

Implementation status

ALYS Link to mail thread

Edit/create a comment

New comment?    ID:     Status:

Location in document:    URI:

Subject:

Comments: Inline markup ok. Always escape < and >.

Owner: Working Group approved?    Editorial/Substantive?

Links: Prefix: Subject: List:

Source dump

Dump all source

Title:

Page template by Richard Ishida (ishida@w3.org).