James M Snell wrote: > I wrote: > > My hypothesis is that an implementation ignorant of BIDI issues is > > more likely to preserve the formatting characters than > > Atom/XHTML/HTML BIDI markup, especially when the effects of > > those formatting characters never span multiple nodes in the > > document. > > Have you tested this hypothesis using real editors?
To clarify, I was thinking more of how aggregators and other non-interactive processors will treat markup vs. formatting codes. In my limited testing, I was able to get formatting codes to be preserved by AtomPub servers but I not always able to get the "dir" attribute preserved. > >> Also, imagine a case where we have a feed with 100 > >> entries, each with about 5 atom:category elements. > >> Let's stay that the feed is generally all RTL. Using > >> your approach, that's at least 1000 extra > >> characters in the feed, and 500 opportunities for the > >> embedding to be screwed up. > > > > The category labels are almost always going to be composed > > of strong RTL and strong LTR characters (only), so the > > BIDI algorithm will work correctly. And, when it doesn't > > work, it is unlikely that it will be > > due to the wrong base directionality--in these cases, formatting > > characters are going to be needed no matter what. Right? > > "almost always" is not "always". The Atom bidi draft covers > the cases where "always" is more desirable than "almost always". Here, I meant that using formatting codes would not result in 1000 extra characters, but almost no extra characters. Also, it is unlikely that errnoeously placed embedding characters will cause major problems since they are all localized to attribute values and atom:name in my suggested mechanism, and there is no cascading/inheritance of directionality that mechanism. In other words, any improper embedding will be limited and very localized. - Brian
