The challenge is not so much with (X)HTML as it is with the plain text variants of content and Text constructs and with Language-Sensitive attributes. Currently, the bidi control characters are the only way to establish the directionality in a content/@type="text" element. Of course, that works, but allowing a dir="rtl" attribute to specify a default direction in the absence of an explicit RLO/RLE and PDF in the text content makes life a bit easier for content publishers.
just to be clear, I'm saying the following would be equivalent (where [RLO] and [PDF] represent the corresponding bidi controls) <content type="text" dir="rtl">ABCDEFG</content> <content type="text">[RLO]ABCDEFG[PDF]</content> If the default direction for the entire document is RTL, allowing that to be established at the feed or entry element level can save some effort adding the appropriate controls to every text element. - James David Powell wrote: > > Tuesday, October 3, 2006, 1:55:31 AM, I wrote: > >> As we depend on Unicode, then we can't really stop people from using >> Unicode bidi. We can't stop people from using HTML/XHTML bidi. Or even >> CSS bidi controls. I think we should think carefully before we >> introduce yet another method for bidi text. > > Hmm, that sounded a bit odd. I don't want to "stop people from using > bidi"... > > I was trying to say that implementations can support Unicode bidi and > HTML bidi today without any change to the spec, and that they seem > more powerful than an Atom bidi attribute. >
