David Powell wrote:
>
>
> I don't have much experience with bidi. I've been having a quick read
> up on it, and there seem to be the following features. Correct me if
> I’m wrong.
>
>
> a) Unicode implicitly supports bidi. Write a span containing Hebrew
> characters, and it will be laid out right to left. We don’t need to do
> anything to support this.
>
Only if rendered using the Unicode Bidirectional Algorithm.
>
> b) <span dir="xxx"> and Unicode controls such as RIGHT-TO-LEFT
> EMBEDDING, give hints about how to layout neutral characters such as
> punctuation marks that are used between flows of ltr and rtl text. We
> don’t need to do anything to support these Unicode controls. <span
> dir> can be used in Text constructs if required, but such a mechanism
> isn’t necessary for the rest of Atom.
>
Not quite. Suppose, for instance, I have a category whose label
attribute consists of primarily (but not completely) right-to-left text.
Example taken from
http://www.w3.org/International/articles/inline-bidi-markup/#visual).
Uppercase letters represent RTL characters.
<category term="..." label="ABCDEFG, W3C" />
When displayed, using the bidi algorithm, this should be rendered as
"W3C, GFEDCBA". However, absent any directional information, it will be
incorrectly rendered as "GFEDCBA, W3C".
To get the direction correct in (x)html, we either need to wrap the
value using the unicode controls or use something like <span dir="rtl">.
In Atom, the only current option is to wrap use the numeric entity
codes, e.g.,
<category term="..." label="‫ABCDEFG, W3C‬" />
If you have multiple categories, text elements, etc that all contain
primarily RTL text, having to wrap all of the text values like this gets
to be quite annoying and problematic.
> HTML benefits from <span dir> because it is easier to type it in HTML
> source than Unicode escapes, but nobody really types Atom source by
> hand, and operating systems do support embedding of Unicode escapes
> via text widgets (eg, on Windows, install supplemental language
> support via Regional Settings control panel - I think?). Allowing dir
> to be used anywhere in Atom does not provide the same feature as <span
> dir>, because the sole purpose of it is to disambiguate mixed
> directions *within* a flow of text, and allowing @dir anywhere in Atom
> would not achieve that granularity.
>
This is precisely why the Pace gives discretion to the consuming
application on how to apply the bidi alg. The dir attribute in Atom
would serve only to specify the base directionality of neutral
characters contained in the feed (equivalent to explicitly wrapping
affected text in the equivalent unicode bidi embed codes).
>
> c) <bdo dir="xxx"> and Unicode controls such as RIGHT-TO-LEFT OVERRIDE
> allow the Unicode algorithm to be disabled and direction to be
> hard-coded. Under what circumstances is this needed? Is it
> appropriate for Atom?
>
I imagine the "lro" and "rlo" values being used very rarely, if ever.
>
> d) <div dir="xxx"> sets the base direction of the text. One of the
> effects of this is that <div dir="rtl"> makes paragraphs right
> aligned, and table columns to be laid out right-to-left.
>
> I'm not convinced that we need support for this in Atom. I'd like to
> hear more opinions. In HTML it makes sense to specify that a block of
> text is right-aligned, but in Atom there are no blocks of text; just
> fields. Isn't this largely a presentation feature?
>
Again, the Pace defers the responsibility of how to apply the bidi alg
to consuming applications. For instance, some feed readers may choose
to display a RTL title in a block element while others may choose to
display it in an in-line element; both of which will yield different
results.
> Adding an attribute that is supposed to inherit from feed elements to
> entry elements is a breaking change to Atom that is likely to lead to
> silent data-loss with existing implementations. Implementations would
> need to know to inherit the attribute down to entries and store it
> with the entries rather than with the feed, so that retrospective
> changes don't change the direction of previously polled entries.
>
Yes, but this doesn't leave us any worse off than we currently are.
Implementations that are not direction-aware should treat the new
attribute as foreign markup and drop the data on the floor. Those
implementations should continue to work as the do currently.
Further, implementors already need to deal with such issues with regards
to author, rights, xml:base and xml:lang so we're not introducing a new
problem.
> I think that inheritance is useful for a hierarchically structured
> document like HTML, but confusing for Atom, which is essentially a
> bunch of XML-ified structs with a fairly arbitrary hierarchy
> representing multiple entities with seperate life-cycles. (People deal
> with feeds containing a subset of all entries ever, not with feed
> documents)
>
>
> e) <html dir="xxx"> in IE at least, this affects not only the page,
> but the layout of browser chrome such as scrollbars and Javascript
> alerts. I don't think that this feature is appropriate for syndication
> format. The user preferences of the user-agent (probably via the OS)
> would probably be better suited to control the application layout.
>
Atom does not dictate the behavior of user agents. Adding a dir
attribute would not change that fact.
>
> So, the question is: do we need the ability to markup the "base
> direction" of text in Atom, at a block level. If so, what are the
> applications of the "base direction" in Atom's layout-agnostic fields
> such as category label?
>
Strictly speaking, we can achieve the same result by using the unicode
bidi controls but doing so can be tricky at times. The dir attribute
makes life easier.
> Also at what granularity do we need to do this? On every element, or
> would it be sufficient to use extension elements to describe the base
> direction at the entry/feed level (cf: <html dir>) ?
>
The attribute should be capable of appearing anywhere xml:lang can
appear and like xml:lang, only affects certain elements and attributes
in the feed. However, whether or not this works best as an attribute in
the Atom namespace or an attribute in some other extension namespace is
an open question.
- James
