Re: [widgets] dir and span elements

Hi Addison, All,

On Mon, Mar 1, 2010 at 11:47 PM, Phillips, Addison <addison@amazon.com> wrote:
>>
>> 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?
>

So you are saying that "dir" affects:

1.  all child nodes (text, elements, etc.).
2.  _only_ the attributes of child nodes (and _not_ the attributes of
the element on which it is declared).

I'll note that that behavior is inconsistent with xml:lang, which I
understand applies to the element's attributes on which it is declared
as well as child notes. So, everything below is in English:

<x y="foo" z="bar" xml:lang="en">
   <bar>English</bar>
</x>

but, unless I missed something, I still seem to have a problem (see
second <name>):

<widget dir="rtl">

<name short="I'm rtl text, because widget said so" dir="ltr">
   Some ltr text because name said so... <span dir="rtl">I am rtl
again!</dir> more ltr.
</name>

<name short="i want to be ltr? but widget says rtl!" xml:lang="en">
   Some rtl text.
</name>

</widget>

I've defined a new rule that is supposed to emulate the behavior of
your example above:

[[
==Rule for Getting a Bidi Attribute Value==
The rule for getting an Internationalized single attribute value is
given in the following algorithm. The algorithm always returns a
string, which can be empty.

1. Let /element/ be the element that contains the attribute to be processed.
2. Let result be the value of the attribute to be processed.
3. If /element/ has a parent element with a dir attribute, then
process result in accordance to the [Widgets-Bidi] specification.
4. In result, replace any sequences of space characters (in any order)
with a single U+0020 SPACE character.
5. In result, remove any leading or trailing U+0020 SPACE characters.
6. Return result.
]]


AFAICT, this rule would only apply to name element's short attribute.
However, I need i18n WG to evaluate the other attributes. To make this
task easy, I've added a table that lists the elements and their
attributes with links:

 http://dev.w3.org/2006/waf/widgets/#table-of-elements-and-their-attributes

So, together with the modified Rule for Getting Text Content, which now reads:

"If input has a dir attribute, or has a parent element with a dir
attribute, or has any child elements that contain a dir attribute,
then process input and its descendant text nodes in accordance to the
[Widgets-Bidi] specification and return the resulting string."

We now generally have a solution for both processing elements and
attributes so that BIDI strings can be used for display purposes.

>> 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 would prefer to leave directionality of the <content> element to the
whatever its source attribute points to (i.e., always leave it up to
the start file).

Kind regards,
Marcos

-- 
Marcos Caceres
http://datadriven.com.au

Received on Saturday, 6 March 2010 19:13:19 UTC