W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2009

FW: [widgets] comments re View Modes Interface spec

From: <Yael.Aharon@nokia.com>
Date: Wed, 16 Dec 2009 19:39:01 +0100
To: <Marcin.Hanclik@access-company.com>, <Art.Barstow@nokia.com>, <public-webapps@w3.org>
Message-ID: <B9B55EB1B426EA479A5B5EE9B292A67536E9C63700@NOK-EUMSG-05.mgdnok.nokia.com>
   Thanks Marcin for your response, my comments are embedded below, marked with [YA]
   
   -----Original Message-----
From: ext Marcin Hanclik [mailto:Marcin.Hanclik@access-company.com] 
Sent: Monday, December 07, 2009 9:01 AM
To: Barstow Art (Nokia-CIC/Boston); public-webapps
Cc: Aharon Yael (Nokia-D/Boston)
Subject: RE: [widgets] comments re View Modes Interface spec
   
   Hi Yael, Art,
   
   Thanks for your comments.
   
   Below are my comments and refining questions.
   Please let me know what you think.
   
   >>Below are some comments from Yael re the View Modes Interface spec:
   >>
   >>  http://dev.w3.org/2006/waf/widgets-vm/vm-interfaces.src.html
   >>
   >>-Art Barstow
   >>
   >>= Section 3.1:
   >>
   >>Interface Media:
   >>
   >>1. Interface Media is also defined in CSSOM (4.1), and the definition
   >>is not consistent.
   I cannot find the definition of the interface Media in CSSOM in section 4.1.
   Did you mean 4.4 interface MediaList (also in DOM2CSS) and mediaText attribute?
   mediaText is the same as Media, but it has just different syntax.
   Therefore I would opt for removal of the Media interface.
   
   >>I think it should be defined in one spec, and the
   >>other spec should refer to that.
   Agreed. Alignment will require discussion with Anne.
   
   [YA] Sorry, I was referring to http://www.w3.org/TR/cssom-view/ , and it already defines the Media interface. 
   
   >>
   >>2. onTypeChanged attribute is defined to be an event. Usually,
   >>onXXchanged attributes are defined as event listeners, I think this
   >>is a mistake.
   Agreed.
   I am thinking about removal of this attribute.
   The events are dispatched on the Document, therefore event handler/listener seems not needed.
   Any thoughts?
   
   [YA] Removing this attribute seems like the best option to me.
   
   
   >>= Section 3.2:
   >>
   >>1. I do not understand the use-case for changing media type.
   >>According to CSS2-Media (7.3), e.g., the act of printing a document
   >>would add a second canvas, and would not change the media type of the
   >>existing canvas.
   This depends on UA. E.g. as for printing you could switch the media type, print and switch it back.
   This use case seems to be intentionally specified as "may" to give the UAs some freedom.
   Changing media type within a media group (CSS2-Media 7.3.1) resembles e.g. changing resolution and color-depth.
   For example, you could switch between print, projection, screen, tty, tv within visual media group.
   
   
   [YA] My understanding of http://www.w3.org/TR/CSS2/media.html , " Media types are mutually exclusive in the sense that a user agent can only support one media type when rendering a document. However, user agents may use different media types on different canvases. For example, a document may (simultaneously) be shown in 'screen' mode on one canvas and 'print' mode on another canvas." , it seems to me that you don't change the Media type, but add a new canvas.
   
   
   >>
   >>= Section 3.4:
   >>
   >>1. The media feature "Resolution" is defined in CSS3-Media-Queries
   >> (4.11) as density of the pixels, e.g. DPI. It is very confusing to
   >>reuse the same name (resolution) for something completely different.
   Agreed.
   There is a related mail thread [1] in which this topic is discussed.
   Nevertheless I think that ResolutionChangeEvent would be helpful to notify about the changed resolution (in its original sense).
   
   [YA] I still don't understand the use case for changing the resolution of a device.
   
   BTW: Actually also the term "media type" has different meanings (P&C vs. CSS), but in this case I think of saying CSS media type.
   
   >>
   >>2. Would ResizeEvent be sufficient instead of adding the new event
   >>ResolutionChangedEvent ?
   What about SizeChangedEvent? Just for naming consistency.
   
   [YA] I was actually thinking about resize event as defined in <http://www.w3.org/TR/DOM-Level-2-Events/events.html> .
   
   
   Thanks, Yael
Received on Wednesday, 16 December 2009 18:59:56 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:35 GMT