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
smime.p7s
Description: S/MIME cryptographic signature
