>
> Thanks Addison - and yes, I think this makes a lot of sense for a
> "content"-style spec like HTML, however as the Widgets P&C is a
> configuration document most of which is IRIs, integers and so on
> rather than text content its less of a clear case.
>
No, I understand and don't disagree. However, there is something to be said for
making it an attribute of <widget>, for example. Then you could have an
override of directionality only when a given element has a different base
direction. In the example in the spec [1], consider how this might be cleaner:
<widget dir="rtl">
<name short="hard to make Arabic rtl here without changing enclosing element"
dir="ltr">
But ltr override here works fine.
</name>
<description>
Some rtl text.
</description>
<author href="" email="">bidi authors name</author>
<license>
...
</license>
</widget>
Compared to:
<widget> <!-- no base direction -->
<name short="can't be rtl?" dir="rtl">
Some RTL.
</name>
<description dir="rtl">
Have to include dir a lot.
</description>
<author dir="rtl">
...
</author>
<license dir="rtl">
...
</license>
</widget>
I'm not suggesting that 'dir' makes sense everywhere, but there is some utility
in allowing direction (and maybe language/locale??) in at the outermost element?
> If dir conformance is tested in relation to the Rule For Obtaining
> Text Content then this already scopes its use to the four elements
> mentioned as these are the only elements that the rule applies to.
>
I agree, but there is one more potential case. The <content> element could have
a default base directionality set (each <content> target or localized
equivalent might also override it).
I agree that a scoped 'dir' attribute is a pain to deal with
implementation-wise, so I personally would be open to not doing this. But I
think it worth considering.
Addison
[1] http://dev.w3.org/2006/waf/widgets/#example-configuration-document
