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: [email protected] -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Marcos Caceres Sent: Tuesday, August 18, 2009 2:07 PM To: Marcin Hanclik Cc: [email protected] Subject: Re: [Window/View Modes] Naming + Feature vs. Query: suggested changes On Tue, Aug 18, 2009 at 1:27 PM, Marcin Hanclik<[email protected]> 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.
