Re: [widgets] dir and span elements

On 1/03/10 11:47 PM, Phillips, Addison 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?
>
>
>> 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.
>

Just to clarify the rationale for the way dir and span are specified... 
Wrt global dir, although potentially painful, it serves as a useful 
extension point if we add new elements in the future. Addison also 
demonstrated the use case we had in mind above when we made it global. 
Scott raised some valid issues (i.e., not all attributes are supposed to 
be, um, "bidi'ed"), but ones intended for human consumption most 
certainly are (e.g., the short name).

With respect to <span>, I decided not to tie its use to any element 
(i.e., it can be declared inside any element). The primary reason is 
extensibility in case we decide to add new metadata elements. As Scott 
pointed out, how each element is processed is inherently tied to Step 7, 
so the specification makes it clear when a span element would be
ignored or processed as part of "9.1.7. Rule for Getting Text Content" [1].

So, the questions that remain are:

1. In Step 7 [2], what modifications need to be made in order to 
accommodate dir as a global attribute and as a local attribute?

2. In "Rule for Getting Text Content", what modifications do we need to 
make (if any) to accommodate dir as a global attribute.

Kind regards,
Marcos

[1] http://dev.w3.org/2006/waf/widgets/#rule-for-getting-text-content
[2] 
http://dev.w3.org/2006/waf/widgets/#algorithm-to-process-a-configuration-doc

Received on Tuesday, 2 March 2010 11:29:31 UTC