- From: Jon Ferraiolo <jferrai@us.ibm.com>
- Date: Sun, 6 May 2007 18:07:25 -0700
- To: "Grassel Guido (Nokia-NRC/Helsinki)" <guido.grassel@nokia.com>
- Cc: Bert Bos <bert@w3.org>, ext Marcos Caceres <m.caceres@qut.edu.au>, "WAF WG (public)" <public-appformats@w3.org>, public-appformats-request@w3.org
- Message-ID: <OF06842E04.6A17D534-ON882572D4.00053CA5-882572D4.00062C53@us.ibm.com>
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@us.ibm.com> Web Architect, Emerging Technologies IBM, Menlo Park, CA Mobile: +1-650-926-5865 "Grassel Guido (Nokia-NRC/Helsin ki)" To <guido.grassel@no ext Marcos Caceres kia.com> <m.caceres@qut.edu.au>, Bert Bos Sent by: <bert@w3.org>, "WAF WG (public)" public-appformats <public-appformats@w3.org> -request@w3.org cc Subject 05/02/2007 09:27 Re: [widgets-reqs] Comments on AM http://www.w3.org/TR/2007/WD-widget s-reqs-20070209 Marcos, WG, On 5/2/07 7:53 AM, "ext Marcos Caceres" <m.caceres@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@nokia.com
Attachments
- image/gif attachment: graycol.gif
- image/gif attachment: pic21176.gif
- image/gif attachment: ecblank.gif
Received on Monday, 7 May 2007 01:07:49 UTC