Additional Requirements for Bidi in HTML - open issues

The following is a highly summarized, hopefully exhaustive list of all open
issues, objections, suggestions, etc. made on the
public-i18n-bidi@w3c.orglist for the proposals in Additional
Requirements for Bidi in
HTML<http://www.w3.org/TR/html-bidi/#vertical-scrollbar-body>.
Please forgive (and point out) any inadvertent omissions.

(Let me also add an apology for not having answered a number of important
messages in the last couple of months. I intend to rectify that in the
coming weeks.)

The discussion has been extremely lively and useful! However, for this
proposal to actually come to fruition, we need to start hammering out
consensual solutions to the issues that have been raised. I hope that the
summary below will help us do that - on the list and at the face-to-face
meeting in June.

The list is organized by the proposal's section numbers. I would like to
suggest that further discussion on the list include the section number(s)
being discussed in each message's subject line, and not deal with multiple
sections in a single message or thread unless there is a shared issue.

And so - the open issues:

2.1 (Support bidi isolation of inline element content)

a. Attribute name: bdi is too cryptic and easy to confuse with bidi.
Suggestions: sce, dirsep.
Suggested resolution: choose a different name.

b. The standard approach to binary values would be the attribute name and
attribute absence only. However, we need an explicit "no" value because
sometimes the default is yes.
Suggested resolution: no change. Note that if we allow specifying different
varieties of separation (see c  below), the issue goes away.

c. Instead of bdi=yes element acting on what surrounds it as strongly in the
base direction, should its effect on the surrounding text be neutral? This
is cleaner and safer, could make it possible to apply bdi=yes automatically
to <a> elements, and be useful for display:inline-block (see 3.3 below).
However, it may be significantly more difficult to implement, and would
require a different solution for <br> (3.1), since it would no longer have
any effect there. Should both behaviors be available and specifiable?

d. Make default yes for certain other elements that are clearly separate
entities, e.g. <a>? Dangerous unless bdy=yes is redefined to have a neutral
effect on the surrounding text.

e. There needs to be a CSS equivalent. If it is a new value for the
unicode-bidi property, e.g. unicode-bidi:separate, there is a collision with
the unicode-bidi:embed implied by using a dir attribute on the element,
which is the usual way to use bdi=yes. One way to resolve this is to say
that both unicode-bidi:separate and the bdi=yes include starting a new
embedding level, even if the dir attribute is not specified.


2.2 (Support auto-direction)

a. Is it really essential to support more than one algorithm? Most users
would probably have trouble deciding between them. If it is essential, how
should the algorithm be specified? Suggestions:
- Support more than one. However, the dir attribute gets just one new value,
"auto". Choose algorithm through another attribute, perhaps autodirmethod
("word-count", "first-strong").
- auto[0-9]*, specifying a limit on the number of strongly-directional words
scanned. auto1 is thus equivalent to first-strong and auto99 to word-count.
Just "auto" - TBD.
- Come up with a single one-size-fits-all algorithm. Perhaps any rtl in
first K characters or words? Seems to have the same pitfall as regular
any-rtl: rtl term or name in first K of otherwise ltr string.

b. Put a limit on the number of characters scanned to protect performance?
Suggested resolution: ok, unless auto[0-9]* is chosen, which takes care of
this. How many characters?

c. The treatment of LRE|RLE|LRO|RLO+PDF areas inside the text being
estimated is important, because it is the only way that title, option,
input, textarea and dialog text can declare embedded opposite-dir strings.
The UBA's spec for it, to ignore the special characters but not what they
bracket, is suboptimal: the overall direction does not affect the display of
the bracketed string, and the direction of the bracketed string is most
likely the opposite of the overall string.
Suggested resolution: ignore the both the special characters and the strings
they bracket. However, if the whole string is bracketed with either LRE or
RLE, return that direction.

d. Possible word-count "tweaks"?
- Give a full, explicit definition of "word"
- Count characters, not words
- Modify the 40% threshold, optimally on the basis of real data where the
LTR component is not limited to English.
- If the text starts with a leading LRM or RLM, skip counting words and
return the direction indicated by LRM or RLM. What are the use cases,
though? And if leading unbracketed LRE/RLE will have this effect anyway (see
c above), is it necessary to also support leading LRM/RLM?

e. Should direction estimation be the default for <input type="text"> and
<textarea> elements? Although it would be either very useful or harmless in
most cases, it is not backward compatible. The best way to come to a
decision might be to discuss specific examples where estimation might prove
harmful, and to judge their importance.


2.3 (Support reporting the chosen direction of <input> and <textarea> in
form submissions)

a. The standard approach to binary values would be the attribute name and no
attribute only.
Suggested resolution: adopt. Instead of yes|no, the only possible value is
the name of the attribute.

b. There do not seem to be any other attributes with an underscore in the
name. Change the name to submitdir?

c. Specify what happens when there is a collision with the name of another
input.
Suggested resolution: the same as for two inputs with the same name.


2.4 (Support option for image elements to be flipped horizontally in RTL)

a. "yes" value will lead to "abuse as a general image-transformation
feature", which is something that should be done in CSS.
Suggested resolution: ok, drop "yes".

b. Make this attribute declarative, instead of instructive? That is,
imgdir=ltr means "this image is for ltr, so flip in rtl". When attribute is
absent, no flipping is done.

c. Mirroring the image is not always sufficient; two different images are
sometimes necessary, and this case should not require two versions of the
HTML. So, allow specifying two urls: one for ltr and one for rtl? Suggested
syntax: rtlflip  (%URI;|rtlflip|none) # none. Note that this conflicts with
b.

d. Specify CSS equivalent usable with background.

e. If CSS is being extended to support selectors based on computed element
direction, is 2.4 still necessary?


3.1 (<br>  should should serve as a bidi separator)

a. Have the HTML WG figure out which way browser makers are going to
converge re <br> instead of ruling on it ourselves?


3.2 (Newline characters should serve as bidi separators inside <pre>,
<textarea>, and script dialog text)

a. In <pre>, treating newlines as <br bdi=yes> was chosen over treating as a
bidi paragraph separator because they can appear inside inline elements.
However, this is not a very important consideration, since in 3.3 we allow
"embedded" block elements to act as paragraph separators even though they
may be inside elements with display:inline style. So, treat newlines as bidi
paragraph separators in <pre> too?


3.3 (Embedded block elements should serve as bidi separators)

a. The behavior of inline elements with display:block style and block
elements with display:inline style should be specified.

b. The behavior of elements with display other than block and inline should
be specified.

c. The behavior of inline elements with float, which are effectively turned
into block elements, should be specified.

d. Should block elements with absolute position, which visually leave the
context of their neighbors, really serve as bidi paragraph separators
between them?


3.4 (Script dialog text should be displayed in the page's direction)

a. Auto-estimate text direction instead?

b. Recommend adding an optional dir parameter to Javascript's alert(),
confirm(), and prompt(), and recommend a similar change in all other script
languages / APIs?


3.6 (title and alt attribute text should be displayed in the element's
direction)

a. Auto-estimate text direction instead?
Suggested resolution: no, this makes it difficult to set the direction
explicitly.

b. Add titledir attribute?
Suggested resolution: yes, this would be the cleanest solution, and CSS need
not get involved.

c. Add altdir attribute? Not really necessary on <img>, since dir on <img>
has no effect except on alt and title, but that is not the case for <input>.
What about longdesc?


3.8 (<input type="text"> and <textarea> should support compatible "set
direction" functionality)

a. Add recommendation to user agents to also support methods more
discoverable than keyboard shortcuts, e.g. a right-click menu?


3.10 (The rendering of numbering or bullets in a list should be independent
of the direction of individual <li> elements)

a. In some Arabic usage, bullet side being determined by item direction
appears to be preferred. Furthermore, CSS WG objects to this change because
all browsers in principle currently follow the item's direction.
Suggested resolution: add CSS property to determine the behavior.

b. Change the default alignment to that of the containing element, too?
Suggested resolution: if adding a CSS property for bullet location, it
should set the default alignment, too.


3.12 (The vertical scrollbar of an element below <body> should be on the
"end" side relative to the element's direction)

a. Does the direction of a <frame> or <iframe> element determine the
scrollbar location?
Suggested resolution: no, the <body> of the document inside the frame.