RE: [Window/View Modes] Naming + Feature vs. Query: suggested changes

Hi Marcos,

It seem to get an off-topic discussion...

>>> Do we care about "non-widgets" using view modes?
>>
>>Of course not :)  The technology should be generally applicable where possible.
I assume you meant "yes", or?

>>
>>Lets not repeat the same mistakes we made with P&C (namely calling the
>>widget element "widget" instead of something more generic, like
>>"package")
What about consistency?
Why is "widget" something else than a "package"?

[2] seems to have a problem with the definition of a widget (aka applet), so if it is so undefined, it can be regarded as generic as well, I think.

Even if some people are unhappy with widget vs. package or so, then it seems it is quite late.
It makes little sense as for me to change the naming in the middle of the specification of the whole "widget" architecture/model defined by [1].
If we keep <widget>, but remove "widget" in other places the architecture will be broken.

P&C says:

"This specification standardizes a packaging format for software known as widgets. Widgets are client-side applications ..." -> this seems to apply also to modes spec.

"This specification is part of the Widgets 1.0 family of specifications, which together standardize widgets as a whole."

"The Widgets 1.0: Media Query Extensions, which defines extensions to CSS Media Queries, and a DOM interface for querying the media features of a widget (see [Widgets-Views])."

The last statement from the above will probably have to be updated anyway.

I think we should remain around widgets and keep the related naming.
Otherwise probably the viewmodes should be co-standardized by CSS WG.

BTW: My question about WidgetViewModeChangeEvent vs. ViewModeChangeEvent remains without answer.

Thanks.

Kind regards,
Marcin

[1] http://dev.w3.org/2006/waf/widgets/#the-widget-family-of-specifications

[2] http://en.wikipedia.org/wiki/Widget


Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452  |  Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanclik@access-company.com

-----Original Message-----
From: marcosscaceres@gmail.com [mailto:marcosscaceres@gmail.com] On Behalf Of Marcos Caceres
Sent: Tuesday, August 18, 2009 2:07 PM
To: Marcin Hanclik
Cc: public-webapps@w3.org
Subject: Re: [Window/View Modes] Naming + Feature vs. Query: suggested changes

On Tue, Aug 18, 2009 at 1:27 PM, Marcin
Hanclik<Marcin.Hanclik@access-company.com> wrote:
> Hi Marcos,
>
> Thanks for your comments.
>
>>>Can we just call it "view-mode"?
>>>Again, just "viewMode"
> Actually I was thinking about it and got stick to the widget environment with view modes due to the following:
> if the spec would be generic for "any" view modes, then "view-mode" and "viewMode" would be ok. But since we remain in the context of widgets (family and title of the spec) I kept the "widget" prefix. If someone in future would use similar mechanisms with e.g. "application", she/he would use "application-view-mode" etc.
>
> To clarify your position finally:
> should this:
>
>> interface WidgetViewModeChangeEvent : Event {
>>  readonly attribute DOMString widgetViewMode;
>> ...
>> };
>
> be changed to
>
>> interface ViewModeChangeEvent : Event {
>>  readonly attribute DOMString viewMode;
>> ...
>> };
>
> (it is about the name of the interface) ??
>
> Do we care about "non-widgets" using view modes?

Of course not :)  The technology should be generally applicable where possible.

Lets not repeat the same mistakes we made with P&C (namely calling the
widget element "widget" instead of something more generic, like
"package")

--
Marcos Caceres
http://datadriven.com.au


________________________________________

Access Systems Germany GmbH
Essener Strasse 5  |  D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda

www.access-company.com

CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.

Received on Tuesday, 18 August 2009 12:38:35 UTC