Marcos Caceres | 2 May 06:53 2007
Picon
Picon

http://www.w3.org/TR/2007/WD-widgets-reqs-20070209


Hi Bert,
Members of the working group took time during our recent face-to-face
meeting to discuss and address the comments you sent us (see April
17th minutes [1]).
I the hope of generating further discussion about the requirements for
the widget spec, I have split my responses to your comments into
multiple emails. Also, I have omitted comments marked as typos and
some comments that were editorial in nature. Editorial issues you
pointed out have been addressed in the latest editor's draft of the
Requirements document [2]. Thank you again for your thorough review of
the document.

> Here are my comments on the February WD of widgets-reqs. On the whole, I
> think the document is easy to read and the requirements are good, but
> not ambitious enough.
>
> The biggest omissions are (requirements on) the UIDL and the details of
> device independence & accessibility. Only R17 talks about alternative
> manifestations, but then only mentions fallbacks and doesn't require
> that a widget's functionality (i.e., everything except its interface)
> should be available on all interactive devices, big or small screen,
> graphical or not.

To be able to mandate that complete widget functionality be available
on all devices would require that we specify a complete solution for
widgets. So far, we have focused mainly on packaging, bootstrapping,
and a base APIs. The working group feels it is beyond the scope of the
charter to specify a complete solution for widgets. We have
deliberately avoided mandating requirements of the UIDL because of the
(Continue reading)

Picon

http://www.w3.org/TR/2007/WD-widgets-reqs-20070209


Marcos, WG,

On 5/2/07 7:53 AM, "ext Marcos Caceres" <m.caceres <at> qut.edu.au> wrote:

> Our experience is that HTML+CSS-based widgets are in fact HTML
> documents and not "programs" (by program I assume you means something
> like a Windows .exe that may have some arbitrary
> inaccessible/unprintable representation). If a widget is created using
> HTML+CSS, then it is the author making the aesthetic choice of making
> the widget look and feel like a program. In such a case, I would argue
> that is up to an author to decide how device-independent they want
> their widget to be as there is no reason not to include, for instance,
> a print style-sheet that makes the widget printable. If, as in most
> cases, a widget is really just a small HTML document that is scripted
> to respond to events and otherwise manipulate the DOM tree, then there
> is no reason why a widget cannot be printed or otherwise made as
> device independent as any other HTML+CSS document.
> 
> Regardless, you make an important point which needs further feedback
> from the community:
> 
> * should the widget specification recommend a UIDL?
> * If yes, should it be HTML+CSS? What happens if a vendor does not
> support HTML+CSS?
> 
Would it really help if the spec recommended HTML+CSS+JavaScript ?
Pro:
- The W3C might argue that a W3C spec should give direction to the industry
and promote other W3C specs.
(Continue reading)

Jon Ferraiolo | 7 May 03:07 2007
Picon

http://www.w3.org/TR/2007/WD-widgets-reqs-20070209

One approach to take with this issue is that the Widgets spec itself is UIML-independent but there is an appendix or separate document that defines a particular profile of Widgets that requires particular versions of HTML+CSS+etc. These profiles greatly promote the ability of content developers to achieve write-once, run-anywhere, which provides great efficiencies to the industry. The CDF WG is taking an approach like this. It has a generic CDF specification [1] that talks about compound document issues independent of any particular markup language. It also defines two profiles, WICD Mobile [2] and WICD Full [3], that specify particular combinations of HTML, ECMAScript, CSS, DOM, and SVG.

I strongly encourage a profile that aligns well with WebKit's and/or Mozilla's support for W3C standards. This would allow leverage of all of the existing Ajax industry for developing widgets. Regarding any vendors that have proprietary UIMLs, they can author their own profiles.

[1] Compound Documents By Reference - http://www.w3.org/TR/2006/WD-CDR-20061122/
[2] WICD Mobile - http://www.w3.org/TR/2006/WD-WICDMobile-20061122/
[3] WICD Full - http://www.w3.org/TR/2006/WD-WICDFull-20061122/

Jon

Jon Ferraiolo <jferrai <at> us.ibm.com>
Web Architect, Emerging Technologies
IBM, Menlo Park, CA
Mobile: +1-650-926-5865

"Grassel Guido (Nokia-NRC/Helsinki)" <guido.grassel <at> nokia.com>


          "Grassel Guido (Nokia-NRC/Helsinki)" <guido.grassel <at> nokia.com>
          Sent by: public-appformats-request <at> w3.org

          05/02/2007 09:27 AM


To

ext Marcos Caceres <m.caceres <at> qut.edu.au>, Bert Bos <bert <at> w3.org>, "WAF WG (public)" <public-appformats <at> w3.org>

cc


Subject

Re: [widgets-reqs] Comments on http://www.w3.org/TR/2007/WD-widgets-reqs-20070209


Marcos, WG,


On 5/2/07 7:53 AM, "ext Marcos Caceres" <m.caceres <at> qut.edu.au> wrote:

> Our experience is that HTML+CSS-based widgets are in fact HTML
> documents and not "programs" (by program I assume you means something
> like a Windows .exe that may have some arbitrary
> inaccessible/unprintable representation). If a widget is created using
> HTML+CSS, then it is the author making the aesthetic choice of making
> the widget look and feel like a program. In such a case, I would argue
> that is up to an author to decide how device-independent they want
> their widget to be as there is no reason not to include, for instance,
> a print style-sheet that makes the widget printable. If, as in most
> cases, a widget is really just a small HTML document that is scripted
> to respond to events and otherwise manipulate the DOM tree, then there
> is no reason why a widget cannot be printed or otherwise made as
> device independent as any other HTML+CSS document.
>
> Regardless, you make an important point which needs further feedback
> from the community:
>
> * should the widget specification recommend a UIDL?
> * If yes, should it be HTML+CSS? What happens if a vendor does not
> support HTML+CSS?
>
Would it really help if the spec recommended HTML+CSS+JavaScript ?
Pro:
- The W3C might argue that a W3C spec should give direction to the industry
and promote other W3C specs.

Cons:
- We know of at least one popular Widget run-time that uses its own UIML.
- We all know too well that different browser engines utilized by
commercially available Widget run-times support various versions of HTML,
JavaScript, DOM and to a various extend. Or how would you described the
situation with IE, Mozila, Opera and WebKit engines ...
- I see a lot of benefit of XBL2 for Widgets, but are we ready to recommend
XBL2 in widget 1.0 ? - I am not sure?

Regards
- Guido

> [1] http://www.w3.org/2007/04/17-waf-minutes.html
> [2] http://dev.w3.org/cvsweb/~checkout~/2006/waf/widgets-reqs/Overview.html
>

-----
Guido Grassel, Nokia Research Center, guido.grassel <at> nokia.com



Anne van Kesteren | 7 May 09:49 2007
Picon

http://www.w3.org/TR/2007/WD-widgets-reqs-20070209


On Mon, 07 May 2007 03:07:25 +0200, Jon Ferraiolo <jferrai <at> us.ibm.com>  
wrote:
> I strongly encourage a profile that aligns well with WebKit's and/or
> Mozilla's support for W3C standards. This would allow leverage of all of
> the existing Ajax industry for developing widgets. Regarding any vendors
> that have proprietary UIMLs, they can author their own profiles.

Yeah, I think it would make sense to mandate support for particular web  
formats as well for web browsers implementing widgets.

--

-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Jon Ferraiolo | 7 May 22:45 2007
Picon

http://www.w3.org/TR/2007/WD-widgets-reqs-20070209

Hi Anne,
No one asked for an apology, but nevertheless, to you and your colleagues, I wanted to apologize for appearing to omit Opera when I said Webkit and/or Mozilla. Maybe I can excuse myself by saying everyone knows that of course Opera has world-class support of W3C standards. But the main reason I listed WebKit and Mozilla was because I wanted to point out that there are two open source browser projects that implements W3C standards faithfully, one of which has proven to be suitable for mobile phones, so there is no excuse (such as licensing fees) for a company that provides a widget system to not implement W3C document format standards. But people should not forget that Opera is also there should there be a need for a partner, and Opera also runs on mobile phones.

Jon

"Anne van Kesteren" <annevk <at> opera.com>


          "Anne van Kesteren" <annevk <at> opera.com>
          Sent by: public-appformats-request <at> w3.org

          05/07/2007 12:49 AM


To

Jon Ferraiolo/Menlo Park/IBM <at> IBMUS

cc

"WAF WG (public)" <public-appformats <at> w3.org>

Subject

Re: [widgets-reqs] Comments on http://www.w3.org/TR/2007/WD-widgets-reqs-20070209


On Mon, 07 May 2007 03:07:25 +0200, Jon Ferraiolo <jferrai <at> us.ibm.com>  
wrote:
> I strongly encourage a profile that aligns well with WebKit's and/or
> Mozilla's support for W3C standards. This would allow leverage of all of
> the existing Ajax industry for developing widgets. Regarding any vendors
> that have proprietary UIMLs, they can author their own profiles.

Yeah, I think it would make sense to mandate support for particular web  
formats as well for web browsers implementing widgets.


--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>



Gmane