[Bug 10807] New: i18n comment 1 : new attribute: ubi


           Summary: i18n comment 1 : new attribute: ubi
           Product: HTML WG
           Version: unspecified
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P2
         Component: HTML5 spec (editor: Ian Hickson)
        AssignedTo: ian@hixie.ch
        ReportedBy: public-i18n-bidi@w3.org
         QAContact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-wg-issue-tracking@w3.org,
                    public-html@w3.org, public-i18n-bidi@w3.org

Comment from the i18n review of:

Comment 1
At http://www.w3.org/International/reviews/html5-bidi/
Editorial/substantive: S
Tracked by: AL

Location in reviewed document:
undefined [http://dev.w3.org/html5/spec/spec.html#contents]

Comment:Expose in HTML the new "isolate" value added to the unicode-bidi style
in CSS3 (
), 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 
. 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

- 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:

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.

Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Wednesday, 29 September 2010 12:15:26 UTC