This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html Multipage: http://www.whatwg.org/C#the-dir-attribute Complete: http://www.whatwg.org/c#the-dir-attribute Comment: The root element's directionality should be a UA-specific value Posted from: 66.207.208.98 by bzbarsky@mit.edu User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/17.0 Firefox/17.0
In particular, if dir is not set on the root, UAs currently allow user control (and in fact might have different per-locale defaults) for the directionality of the root.
The request makes no sense to me. Any given page is designed to be viewed on a particular direction. If viewed in the other direction, it is usually badly broken. It just makes no sense to view Hebrew text in LTR or English text in RTL. For example, please try: data:text/html,<html dir=ltr><div>Hello, world!</div><input type="radio">Left <input type="radio">Center <input type="radio">Right</div></html> and data:text/html,<html dir=rtl><div>Hello, world!</div><input type="radio">Left <input type="radio">Center <input type="radio">Right</div></html> 99%+ of the pages on the internet do not specify a dir on their root element but will only appear as intended in LTR. A UA that displays them some other default will simply display them broken. The concept of UA-specific default direction just makes no sense.
I'm just passing on what Simon told me: that apparently in some of our locales web pages overwhelmingly do not declare directionality and work best when rendered in RTL....
(In reply to comment #3) > I'm just passing on what Simon told me: that apparently in some of our locales > web pages overwhelmingly do not declare directionality and work best when > rendered in RTL.... I would certainly like to get more details. If these documents work best when rendered RTL, does that mean that current UAs all display then not-at-their-best, i.e. broken? And that UAs with the LTR default will still display them that way after the proposed change? Do we have examples of such documents?
Firefox doesn't always default to LTR today, is the point. It's a user preference. I was told that some locales set it to RTL by default, though I'm having a hard time finding evidence of this... You really want to talk to Simon here; I'm just the one with the bugzilla account. :(
(In reply to comment #5) > Firefox doesn't always default to LTR today, is the point. It's a user > preference. I was told that some locales set it to RTL by default, though I'm > having a hard time finding evidence of this... I'm pretty sure that we don't do this for content.
Also I'm going to ask Simon what he meant here.
bz: Which locales are these? (I'd like to test it but don't want to download six zillion builds until I find one like this...) If we do end up having to do this, we should probably enumerate the doomed locales in the same way as we enumerate which locales should default to which encodings.
bz: (also useful to know would be which sites are affected)
Again, you want to talk to Simon Montagu, not me.
smontagu: Do you have any insights on the topic here?
My attempts at contacting Simon (both here, on IRC, and by e-mail) have failed. Right now this bug is asking for a controversial change based on basically hearsay. Which isn't to say that I don't trust bz or Simon, quite the opposite in fact, but generally we rely on more than just a second-hand report of something to make a controversial change. I call it controversial because there is some disagreement about whether it should happen (q.v. comment 2). Before I can make a call one way or the other, we either need to study what popular user agents do in the main RTL locales. By "popular" I mean that they have a double-digit market share in those locales specifically. The two big RTL scripts I know about are Arabic and Hebrew. Arabic's largest country seems to be Egypt. IE, Firefox, and Chrome have significant market share in those countries. Hebrew's largest country seems to be Israel. The same browsers are popular there. To test for default directionality, I would use this demo file: http://damowmow.com/playground/demos/bidi/002.html To perform a test, one would need to install an OS native to the Israel or Egypt locales without changing its default settings, and one would then need to download and install a browser for that OS without changing its settings, and finally one would need to visit that URL and determine if the box, list item bullet, and punctuation appear on the right or left of the page.
I got screenshots of Safari and Chrome on a Hebrew-language Mac OS X, and they seem to default that page to ltr. Still investigating...
Sorry to have taken so long to comment here. I don't know of any localization of Firefox that uses the option to change the default document direction, although the possibility does exist in theory. I think comment 3 goes beyond what I said about this, especially the part about "overwhelmingly". At the other extreme, I think the "99%+ of the pages on the internet" in comment 2 is a great exaggeration. I see pages almost every day that don't use the dir attribute properly and I need to switch the document direction to read them comfortably, for example http://www.soulandgone.com/ Am I right in thinking that the controversial part here is the configurable default, and having UI to change the document direction on the fly is not controversial?
IE on a Hebrew version of Windows XP seems to display http://damowmow.com/playground/demos/bidi/002.html left-to-right. (I can't be sure which, if any, settings have been modified on the computer I tested on).
(In reply to comment #14) > I see pages almost every day that don't > use the dir attribute properly and I need to switch the document direction > to read them comfortably, for example http://www.soulandgone.com/ Either I'm missing something here, or that's not a good example at all. The soulandgone page is clearly a page that is designed to be LTR by default, with some embedded Hebrew text. It's true that the author has omitted to use dir on the Hebrew text, so things like punctuation are incorrectly aligned, but changing the default direction of the page to RTL will break all the Latin text (which is by far the majority of the text on the page) as well as probably messing up the page layout. If a browser automatically switches the default direction of the root of a page to RTL any time it contains some embedded Hebrew text, then it would create chaos. At most, what might be useful for this page is a feature that detects RTL elements based on content and applies a dir to them - but I'm not sure how easy or reliable such a feature could be. This author must surely know that the Hebrew looks wierd, but apparently hasn't bothered to do anything about it (the fix isn't rocket science) - I'm not sure we should force that upon them. I think the best solution for this bug is to make it easier for people to find educational stuff that tells them how to do bidi text correctly (such as http://www.w3.org/International/tutorials/new-bidi-xhtml/Overview-inline.en.php).
I agree with Richard about soulandgone.
I was actioned by the I18N WG [1] with replying to this bug and saying: we think that allowing the root element's directionality to be UA specific is a very Bad Idea. This would cause Web pages to display differently depending on UA or on the UA's current runtime locale, particularly the (more common) left-to-right pages that do no declare directionality anywhere. Having a default direction is a much better user experience and authors have a well-documented feature for right-to-left content. [1] http://www.w3.org/2013/04/11-i18n-minutes.html#item05 [2] I18N-ACTION-207
Thanks for all the comments above. If all browsers default to ltr (and that seems to be the case — I'm not aware of any browser in any locale that defaults to rtl in cases where the page doesn't specify the directionality), then I really don't think it makes sense for a UA to be able to default to rtl. As far as UI goes, a browser is naturally allowed to offer UI that causes the UA to subsequently violate the specifications; whether this be an "inspect element" debugging UI that allows the user to specify dir=rtl on the root element or whether it's a button in a toolbar that does the same thing, is outside the scope of the spec. Which is to say, I think this should be WONTFIX based on the above info.