Re: [widgets] dir and span elements
On 12/03/10 7:27 PM, Richard Ishida wrote: I agree with Felix. Note also for example that the HTML 4.01 spec also says This attribute specifies the base direction of directionally neutral text ... in an element's content *and attribute values*. (my emphasis). Ok, I've rewritten the following algorithms to make sure a direction is always associated with a string (as well as the language): http://dev.w3.org/2006/waf/widgets/#rule-for-determining-directionality http://dev.w3.org/2006/waf/widgets/#rule-for-getting-a-single-attribute-valu http://dev.w3.org/2006/waf/widgets/#rule-for-getting-text-content-with-norma There are, of course, some problems with applying directionality to attributes where their base direction is different than that of the element content or they contain text which needs to have embeddings applied to just a part of the text. These are some of the reasons that we and the ITS spec always advise against using user readable text in attributes - use elements for that stuff. Yeah, we kinda stuffed up in a few places then: version attribute of the widget element, the short attribute of the widget name, and possibly the email attribute of the author element. If we find that they start to cause problems in the wild, we might deprecate them in the future in favor of element-based equivalents. Kind regards, Marcos -- Marcos Caceres Opera Software
Re: [widgets] dir and span elements
Hi Addison, Richard, and i18 WG, On Sat, Mar 6, 2010 at 8:12 PM, Marcos Caceres marc...@opera.com wrote: Hi Addison, All, On Mon, Mar 1, 2010 at 11:47 PM, Phillips, Addison addi...@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 PC 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 barEnglish/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=rtlI 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 Upon reflection on the discussion above, I think the dir attr must behave the same as xml:lang - meaning that the value of dir is applied to the element, all its attributes, and its child nodes. It is then left to the specification of a given element to define if the rendering of the value of an attribute or the text content of a node is affected (as is the case with the name element and its short attribute VS the feature element's name attribute, which is an IRI... which is something I've been wanting to ask, can IRIs be rendered rtl?). Rationale through example: Below, the
Re: [widgets] dir and span elements
Hi Marcos, 2010/3/10 Marcos Caceres marc...@opera.com Hi Addison, Richard, and i18 WG, [snip] Upon reflection on the discussion above, I think the dir attr must behave the same as xml:lang - meaning that the value of dir is applied to the element, all its attributes, and its child nodes. Correct. This is also how the element is defined in ITS, see the inheritance column at http://www.w3.org/TR/its/#datacategories-defaults-etc : Textual content of element, *including* attributes and child elements, the same as language information in the same table (a mediator for xml:lang). Best, Felix
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 PC 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 ofwidget, 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. Thecontent element could have a default base directionality set (eachcontent 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
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 PC 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 ofwidget, 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. Thecontent element could have a default base directionality set (eachcontent 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
Re: [widgets] dir and span elements
Hi Marcos, On 26 Feb 2010, at 17:44, Marcos Caceres wrote: Hi i18n WG, I've added the dir attribute and span elements to the Widgets PC Specification, as well as a bunch of examples (which are wrong, so I would really appreciate some help with these!). The dir attribute is specified here: http://dev.w3.org/2006/waf/widgets/#global-attributes The span element is specified here: http://dev.w3.org/2006/waf/widgets/#the-span-element The processing step that defers to the yet to be written [WIDGET-BIDI] specification is defined here: http://dev.w3.org/2006/waf/widgets/#rule-for-getting-text-content The specification makes it mandatory that a user agent implement the WIDGET-BIDI spec: A user agent is an implementation of this specification that also supports [XML], [XMLNS], [UTF-8], [DOM3CORE], [SNIFF], [WIDGETS-BIDI], and [ZIP]... We would appreciate your review and any assistance you can provide. In particular, we would appreciate your guidance into what would go into the Widgets Bidi specification (i.e., how processing is done for dir and span). At the moment, we only have the following text for such a specification (based on HTML5's bdo element): [[ If an element has the dir attribute set to the exact value ltr, then for the purposes of the bidi algorithm, the user agent must act as if there was a U+202D LEFT-TO-RIGHT OVERRIDE character at the start of the element, and a U+202C POP DIRECTIONAL FORMATTING at the end of the element. If the element has the dir attribute set to the exact value rtl, then for the purposes of the bidi algorithm, the user agent must act as if there was a U+202E RIGHT-TO-LEFT OVERRIDE character at the start of the element, and a U+202C POP DIRECTIONAL FORMATTING at the end of the element. The requirements on handling the span element for the bidi algorithm may be implemented indirectly through the style layer. ]] I can live with this, with a few comments: 1. dir is now an (optional?) attribute of every element; however, previously its usage was limited to elements that contain human- readable text content: author, license, description, and name. Is there a reason for making it global in this manner? E.g. would it not make more sense to specify dir attributes on these four specific PC elements? I don't see anyone putting dir on (e.g.) the height attribute, nor would we want to include a test for it for compliance with optional spec features. 2. span should be allowed as a child element of the license element as well as for name, description and author. Thanks again for all your time and help! Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au smime.p7s Description: S/MIME cryptographic signature
RE: [widgets] dir and span elements
Hi Scott, One reason to make 'dir' available on higher-level elements is that 'dir', like 'xml:lang', has scope. It is often useful to specify a base directionality for an entire document or block of elements rather than having to repeat it over-and-over on each affected element. I can agree that it might not make sense on every element and perhaps we should look at which structural elements in PC make sense as a place to set a base directionality or directionality override. I also agree about making span available inside license. In fact, it is probably the *most* useful inside the license element. Addison Addison Phillips Globalization Architect -- Lab126 Internationalization is not a feature. It is an architecture. -Original Message- From: public-i18n-core-requ...@w3.org [mailto:public-i18n-core- requ...@w3.org] On Behalf Of Scott Wilson Sent: Monday, March 01, 2010 9:44 AM To: marc...@opera.com Cc: public-webapps; public-i18n-c...@w3.org Subject: Re: [widgets] dir and span elements Hi Marcos, On 26 Feb 2010, at 17:44, Marcos Caceres wrote: Hi i18n WG, I've added the dir attribute and span elements to the Widgets PC Specification, as well as a bunch of examples (which are wrong, so I would really appreciate some help with these!). The dir attribute is specified here: http://dev.w3.org/2006/waf/widgets/#global-attributes The span element is specified here: http://dev.w3.org/2006/waf/widgets/#the-span-element The processing step that defers to the yet to be written [WIDGET- BIDI] specification is defined here: http://dev.w3.org/2006/waf/widgets/#rule-for-getting-text-content The specification makes it mandatory that a user agent implement the WIDGET-BIDI spec: A user agent is an implementation of this specification that also supports [XML], [XMLNS], [UTF-8], [DOM3CORE], [SNIFF], [WIDGETS- BIDI], and [ZIP]... We would appreciate your review and any assistance you can provide. In particular, we would appreciate your guidance into what would go into the Widgets Bidi specification (i.e., how processing is done for dir and span). At the moment, we only have the following text for such a specification (based on HTML5's bdo element): [[ If an element has the dir attribute set to the exact value ltr, then for the purposes of the bidi algorithm, the user agent must act as if there was a U+202D LEFT-TO-RIGHT OVERRIDE character at the start of the element, and a U+202C POP DIRECTIONAL FORMATTING at the end of the element. If the element has the dir attribute set to the exact value rtl, then for the purposes of the bidi algorithm, the user agent must act as if there was a U+202E RIGHT-TO-LEFT OVERRIDE character at the start of the element, and a U+202C POP DIRECTIONAL FORMATTING at the end of the element. The requirements on handling the span element for the bidi algorithm may be implemented indirectly through the style layer. ]] I can live with this, with a few comments: 1. dir is now an (optional?) attribute of every element; however, previously its usage was limited to elements that contain human- readable text content: author, license, description, and name. Is there a reason for making it global in this manner? E.g. would it not make more sense to specify dir attributes on these four specific PC elements? I don't see anyone putting dir on (e.g.) the height attribute, nor would we want to include a test for it for compliance with optional spec features. 2. span should be allowed as a child element of the license element as well as for name, description and author. Thanks again for all your time and help! Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: [widgets] dir and span elements
On 1 Mar 2010, at 17:58, Phillips, Addison wrote: Hi Scott, One reason to make 'dir' available on higher-level elements is that 'dir', like 'xml:lang', has scope. It is often useful to specify a base directionality for an entire document or block of elements rather than having to repeat it over-and-over on each affected element. I can agree that it might not make sense on every element and perhaps we should look at which structural elements in PC make sense as a place to set a base directionality or directionality override. Thanks Addison - and yes, I think this makes a lot of sense for a content-style spec like HTML, however as the Widgets PC is a configuration document most of which is IRIs, integers and so on rather than text content its less of a clear case. 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 also agree about making span available inside license. In fact, it is probably the *most* useful inside the license element. Addison Addison Phillips Globalization Architect -- Lab126 Internationalization is not a feature. It is an architecture. -Original Message- From: public-i18n-core-requ...@w3.org [mailto:public-i18n-core- requ...@w3.org] On Behalf Of Scott Wilson Sent: Monday, March 01, 2010 9:44 AM To: marc...@opera.com Cc: public-webapps; public-i18n-c...@w3.org Subject: Re: [widgets] dir and span elements Hi Marcos, On 26 Feb 2010, at 17:44, Marcos Caceres wrote: Hi i18n WG, I've added the dir attribute and span elements to the Widgets PC Specification, as well as a bunch of examples (which are wrong, so I would really appreciate some help with these!). The dir attribute is specified here: http://dev.w3.org/2006/waf/widgets/#global-attributes The span element is specified here: http://dev.w3.org/2006/waf/widgets/#the-span-element The processing step that defers to the yet to be written [WIDGET- BIDI] specification is defined here: http://dev.w3.org/2006/waf/widgets/#rule-for-getting-text-content The specification makes it mandatory that a user agent implement the WIDGET-BIDI spec: A user agent is an implementation of this specification that also supports [XML], [XMLNS], [UTF-8], [DOM3CORE], [SNIFF], [WIDGETS- BIDI], and [ZIP]... We would appreciate your review and any assistance you can provide. In particular, we would appreciate your guidance into what would go into the Widgets Bidi specification (i.e., how processing is done for dir and span). At the moment, we only have the following text for such a specification (based on HTML5's bdo element): [[ If an element has the dir attribute set to the exact value ltr, then for the purposes of the bidi algorithm, the user agent must act as if there was a U+202D LEFT-TO-RIGHT OVERRIDE character at the start of the element, and a U+202C POP DIRECTIONAL FORMATTING at the end of the element. If the element has the dir attribute set to the exact value rtl, then for the purposes of the bidi algorithm, the user agent must act as if there was a U+202E RIGHT-TO-LEFT OVERRIDE character at the start of the element, and a U+202C POP DIRECTIONAL FORMATTING at the end of the element. The requirements on handling the span element for the bidi algorithm may be implemented indirectly through the style layer. ]] I can live with this, with a few comments: 1. dir is now an (optional?) attribute of every element; however, previously its usage was limited to elements that contain human- readable text content: author, license, description, and name. Is there a reason for making it global in this manner? E.g. would it not make more sense to specify dir attributes on these four specific PC elements? I don't see anyone putting dir on (e.g.) the height attribute, nor would we want to include a test for it for compliance with optional spec features. 2. span should be allowed as a child element of the license element as well as for name, description and author. Thanks again for all your time and help! Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au smime.p7s Description: S/MIME cryptographic signature
RE: [widgets] dir and span elements
Thanks Addison - and yes, I think this makes a lot of sense for a content-style spec like HTML, however as the Widgets PC 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
