W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2010

Re: [widgets] ITS in Widgets

From: Marcos Caceres <marcosc@opera.com>
Date: Mon, 1 Mar 2010 10:02:36 +0100
Message-ID: <b21a10671003010102g1b703110vd5c2826e20969bb0@mail.gmail.com>
To: Scott Wilson <scott.bradley.wilson@gmail.com>
Cc: "public-i18n-core@w3.org" <public-i18n-core@w3.org>, public-webapps <public-webapps@w3.org>
On Mon, Feb 22, 2010 at 10:59 PM, Scott Wilson
<scott.bradley.wilson@gmail.com> wrote:
>
> On 22 Feb 2010, at 18:11, Marcos Caceres wrote:
>
>> Dear i18n core,
>>
>> I'm writing on behalf of the Web Apps WG about the possibility of
>> conducting a joint teleconference to discuss some issues with the ITS [1]
>> features in the Widgets 1.0 Family of Specifications.
>>
>> Basically, we would like to discuss:
>>
>> 1. Moving ITS functionality out of the Widgets Packaging and Configuration
>> specification to a separate specification.
>>
>> 2. Clarifying some aspects of how content that uses ITS functionality is
>> processed, so to address an API issue that is discussed below.
>>
>> As you may recall, the WebApps WG collaborated with i18n to integrate ITS
>> functionality into the Widgets Packaging and Configuration (P&C)
>> specification [2]: namely, the <its:span> element and its:dir attribute. We
>> now have approximately 10 vendors claiming to implement P&C. Unfortunately,
>> we have not managed to get a single vendor to implement the ITS features;
>> and, as far as we know, none of these implementations intend to implement
>> the ITS features.
>
> As I understood it there is the its:span element and/or the its:dir
> attribute.
>
> Many P&C elements can have an its:dir attribute, and we've implemented all
> of these though not yet all consistently. For example, if you set its:dir on
> license, then you'll get that info in the Wookie widget catalogue with ITS
> attribute, but we haven't ensured that the same is true for description and
> longname (though this mail has reminded me to go and fix it...)

Hold up fixing anything, as we are moving to defining the ITS behavior
in the P&C spec.

> The its:span element is trickier as its an exception then to the general
> rules for processing content in P&C and requires special handling as it
> would be the only case where markup is allowed inside content.

This is correct. We are going to create a specification just for this
case. We are hopefully going to work with the i18n WG to get this
specified quickly.

>> The lack of commitment by vendor's to support the ITS specification in the
>> P&C specification is blocking us from progressing the P&C to Proposed
>> Recommendation. We must state that this is not a criticism of ITS, and we
>> are unclear as to why implementers are choosing not to support it. Vendors
>> have indicated that they do, however, support the appropriate Unicode
>> characters to control directionality.
>>
>> As we are fully committed to having a suitable i18n solution for P&C, the
>> Web Apps working group would like to co-ordinate with i18n to address this
>> issue at the markup level. We want to discuss the creation of a new
>> specification that would add the span/dir functionality in the widget
>> namespace. We are only proposing this because various members (Opera
>> included) have expressed that they would be more willing to implement the
>> ITS functionality if it was defined in the widget namespace.
>
>> The working group has also identified a potential issue with how ITS data
>> is passed to one of our APIs [3]. The issue of accessing ITS marked-up
>> content through an API is important, as currently if one has <name>Foo <span
>> dir='rlt'>esrever</span> Bar</name>, one gets a string back in the API that
>> loses the direction information. The Web Apps Working Group believes that an
>> orthogonal specification could address this issue.
>
> I think solving this issue may resolve others, as you then have a reason for
> parsing the ITS information correctly in the P&C stage and can more readily
> demonstrate functionality for it.

Agreed. Both the i18n WG and the Web Apps WG feel it would be better
for authors if this was an integral part of the configuration document
vocabulary. Dropping the its namespace is also helpful for authors and
implementers. We hope that by making these changes we won't break
existing implementations and will allow the dir attr and span element
to be neatly included into the spec.

-- 
Marcos Caceres
http://datadriven.com.au
Received on Monday, 1 March 2010 09:03:29 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:37 GMT