W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2010

Re: Comments on the http://www.w3.org/TR/widgets/

From: Marcos Caceres <marcosc@opera.com>
Date: Mon, 1 Nov 2010 18:17:20 +0100
Message-ID: <AANLkTi=Bn=rFL_gfSk5o1+Xxo+fsyJLG59snprCRu_tM@mail.gmail.com>
To: viji <viji@borqs.com>
Cc: public-webapps@w3.org
Hi Viji,

Sorry for taking sooo long to respond... I've attempted to address
your feedback below.

For the "disposition of comments" for this specification, it is
important that you respond to this email with confirmation that you
are either satisfied or dissatisfied with the changes I have made.
The W3 process C requires the we attempt to record that the commenter
is satisfied with the changes.

On Tue, Oct 19, 2010 at 2:40 PM, viji <viji@borqs.com> wrote:
> All
>
>  Here are some of the comments on http://www.w3.org/TR/widgets/ W3C Working
> Draft 5 October 2010
>
> 1. 7.9.2. The email Attribute
>
> mentions that email is a keyword attribute where
>
> A keyword is a string that is reserved for the purpose of this
> specification. The value of a keyword attribute is a keyword  that is one of
> a finite set specified in the attribute's definition in the case given in
> this specification.
>
> Does this mean that the finite set will be defined in the specification ? or
> the spec assumes that there will be a finite set based on the attributes
> definition in the specification.

No, sorry about the confusion. I used erroneously defined it as a
keyword attribute to stop the parsing algorithm from applying dir to
it. I have defined a new type of attribute which is simply a "string
attribute". The spec now reads:

[[
String attribute
The value of a string attribute is any string that conforms to [XML]
as a valid string for an XML attribute. The purpose of this attribute
type is to classify strings that are not affected by the dir
attribute, such as the email attribute (i.e., these attributes will
not treated as displayable strings during Step 7).
]]

I have updated the email attribute, as well as the param element's attributes.

> This would mean that the email attribute can only hold emails and not any
> other string ?

As above, it is now any string, so long as it does not break XML parsing rules.

> For param element's name and value attributes, how is the finite set defined
> ? Do we let the feature defined specify the set ?

As above. It is now any valid string so long as it does not break XML.

> 2. 9.1.9. Rule for Getting Text Content with Normalized White Space
>
>  In the example given, is the dir attribute for Dude ignored ?

No, dir is applied. Dude would be presented right-to-left. If it was
HTML, it would be marked up like this:

The Awesome Super  <bdo dir="rtl">Dude</bdo>Widget

> The sentence
> "The resulting widget name would be "The Awesome Super Dude Widget" but
> represented as a localizable string that retains" does not seem complete

I've removed "that retains". I've said: "(please note that "Dude" is
rendered right-to-left)"

> 3.  7.11. The icon  Element and its Attributes
>
>  Attributes:
>    Global attributes, src, width, height.
>
>  global attributes, xml.lang does not apply as mentioned in the spec.
>  dir also would not apply to icon element ?
>  Is Global attributes required as an attribute to icon element.
>
>  Same thing applies to content element, feature element, param element

i have added the following clarification to 7.5. Global Attributes:

"Although global attributes can be used on any element in this
specification, they sometimes have no effect on the element on which
they are used. For example, applying dir attribute on an icon element
will have no effect on the icon elements or any of its attributes.
What effect specifying a global attribute has on an elements is
determined by Step 7 of this specification."

Does that help?

-- 
Marcos Caceres
Opera Software ASA, http://www.opera.com/
http://datadriven.com.au
Received on Monday, 1 November 2010 17:18:17 GMT

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