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

Re: [widgets] ITS in Widgets

From: Scott Wilson <scott.bradley.wilson@gmail.com>
Date: Mon, 22 Feb 2010 21:59:44 +0000
Cc: "public-i18n-core@w3.org" <public-i18n-core@w3.org>, public-webapps <public-webapps@w3.org>
Message-Id: <B9954074-2375-42D6-9BA9-975A3C903300@gmail.com>
To: Marcos Caceres <marcosc@opera.com>

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...)

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.

> 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.

>
> Although short notice, it would be helpful if members from the i18n  
> WG could join our weekly teleconf taking place on Feb 25 (starts at  
> 3pm Paris time). We will send the agenda to this list on the 24th.
>
> Kind regards,
> Marcos
>
> [1] http://www.w3.org/TR/its/
> [2] http://www.w3.org/TR/widgets/
> [3] http://www.w3.org/TR/widgets-apis/
>



Received on Monday, 22 February 2010 22:00:21 GMT

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