This document:Public document·View comments·Disposition of Comments·
Nearby:Web Applications Working Group Other specs in this tool
Quick access to LC-1982 LC-1983 LC-1993 LC-1994 LC-2061 LC-2062 LC-2099 LC-2100 LC-2101 LC-2102
Previous: LC-2102 Next: LC-2062
Marcos, Here are my comments on the Requirements (W3C Working Draft 23 June 2008) > 1. Introduction > [...] This document does not address the requirements of "web widgets", such as iGoogle Gadgets or Windows Live Gadgets. I Think we can add a wording at the end of the sentense to read: ³..., although this version of the widget specification, the Working group will address the web widget in the next iteration of the widgets specifications.² > 3. Design Goals > Longevity: ... I think in this chapter we should talk about the versioning of a widget. I¹m not sure it should be presented as a specific item, or if it can be added inside the logevity section in relation to the longevity of the content provided and related updates it will need over time. > R7. Internationalization Guidelines > Rationale: [...] (e.g. 'resources/en/' for all English content, 'resources/en-au/' for further localized Australian-English content, and so on). Insert an ³and² in between the 2 english example to stress the need to allow both >R15 & R16 Is there a reason why they should not be ³must² instead of ³should²? > R19. Iconic Representations > Rationale: [...] For example, an a small graphic of a calendar may represent a calendar widget. ³an a² should be corrected But I propose to add the following after: ³And a small graphic of today¹s calendar page may also represent this same calendar widget² > R27. Widget State Change Events This requirement must be available both ways, you should be able to capture the change of state when it happens, but you should also be able as an author to force the state change as well. I propose the following text: ³A conforming specification must also allow the author to programmatically change the state of the widget to allow a change in the view of the instantiated widget.² > R28. Network State Change Events In the specific case of a network drop, the author will need to know when the network works again, in order to not have to code a checking loop, it is important to put together a mechanisme whereby it¹s the widget engine that wakes up the widget when the network is back on. What do you think? > R29. Modal Priority > [...] (or any of its windows) should to categorize itself ³should to...² should be corrected > 4.5 User Agents > R39. End-user Declared Proxy > A conforming specification should recommend that widget user agents allow end-users to explicitly input a proxy server through which all HTTP-based request are made. This requirement should include at the end ³, or in case of availability, that the system wide proxy is used.² This requirement should be a ³Must² >R40. Automatic Updates This requirement should be a ³Must² >R41. Persistent Storage of Preferences > A conforming specification must recommend that a widget user agent implement a means to persistently store user preferences for each instantiated widget. The following should be added after the first sentence: ³This Storage mechanism must allow to keep the preferences after restart of the widget or on the restart of the user agent. > Rationale: To allow widgets to be closed and re-instantiated without the end-user having reset the preferences for an instantiated widget. For example, when using a weather widget, the end-user will want to store the preferred location for weather information, and not be asked to input that information again every time the widget is re-instantiated. And again at the end of this sentence: ³The same would apply if the user has setup 2 instances of the same widget and would like to view 2 different cities. After closing the widgets, open 2 instances of this weather widget would automatically pick up the 2 pre-set cities. > R41 and R42 I would switch them arround so that the notion of the multiple instance can be used in the Preference Storage Requirement. > R44. Runtime Security Exceptions A conforming specification must specify runtime exceptions for when the API attempts to perform an action it it not authorized to perform. Correct ³it it² Best Regards, Benoit > > Benoit Suzanne > Widget Factory Project Manager - Orange Labs - FT/RD/SIRP/SOL/SLAM > t. +33 (0)145 298 198 - m. +33 (0)680 287 553 > benoit.suzanne@orange-ftgroup.com > > > Benoit Suzanne > Widget Factory Project Manager - Orange Labs - FT/RD/SIRP/SOL/SLAM > t. +33 (0)145 298 198 - m. +33 (0)680 287 553 > benoit.suzanne@orange-ftgroup.com >