- From: Marcos Caceres <marcosc@opera.com>
- Date: Sat, 6 Mar 2010 20:12:26 +0100
- To: "Phillips, Addison" <addison@amazon.com>
- Cc: Scott Wilson <scott.bradley.wilson@gmail.com>, public-webapps <public-webapps@w3.org>, "public-i18n-core@w3.org" <public-i18n-core@w3.org>
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