Re: [widgets-reqs] Comments on 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
variance in UIDL currently seen in the wild. If we were to recommend
any, it would likely be HTML+CSS and not some new UIDL. However, we
feel that mandating HTML+CSS may be problematic for many vendors
because of the high level of complexity in implementing HTML+CSS-based
rendering.

Regarding accessibility, we assume that the UIDL supported by the
widget engine provides the accessible aspects. Regardless, I have gone
ahead and added a new section to the Requirement document to make
accessibility a requirement of any UIDL, no matter what it is (see
seciton 3.4 in [2]; I still need to expand this section). We also hope
that the base Widget API will also provide the base functionality on
all devices. How this will happen is an open issue within the group
and requires further research and feedback from the public and
vendors.

> A widget, being a program, will necessarily be less device-independent
> than an HTML document (you can't realistically print it and use it on
> paper), but as long as you have an interactive computer with some input
> device and some output device, the widget should be functional (which
> isn't the same as user-friendly or useful, of course).

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?

Kind regards,
Marcos

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

Received on Wednesday, 2 May 2007 04:53:51 UTC