Re: [widgets] dir and span elements

On 2 Mar 2010, at 11:28, Marcos Caceres wrote:

> 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:
>> [...]
>>
>> 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].

OK, I think allowing a global dir attribute and span element, but for  
conformance purposes implementers only having to deal with cases where  
the Rule for Getting Text Content is applied is a reasonable balance  
between future-proofing and YAGNI[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.

Well, the current text doesn't seem to be right:

"If input has 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."

Instead it should be something like:

"If input has a dir attribute, or has any child elements that contain  
a dir attribute, or has any parent 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."

The short name attribute case isn't covered here, but instead uses the  
Rule for Getting a Single Attribute Value[2]. Looking at this it would  
seem that short="<span dir='rtl'>looc</span>" would work OK as the  
rule doesn't require removing tags in the attribute value. Though it  
may be useful having a test case for it in any case.

[1] http://en.wikipedia.org/wiki/YAGNI
[2] http://dev.w3.org/2006/waf/widgets/#rule-for-getting-a-single-attribute-valu

> 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