- From: Marcin Hanclik <Marcin.Hanclik@access-company.com>
- Date: Mon, 7 Dec 2009 15:00:56 +0100
- To: Arthur Barstow <art.barstow@nokia.com>, public-webapps <public-webapps@w3.org>
- CC: Yael Aharon <Yael.Aharon@nokia.com>
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. >> >>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? >> >>3. The descriptions of the attributes "type" and "ontypechanged" >>under the IDL definition are swapped. Fixed. >>Interface ViewCSS: >> >>1. Interface ViewCSS is also defined in DOM2-CSS (2.2.1), and the >>definition is not consistent. I think it should be defined in one >>spec, and the other spec should refer to that. Since CSSOM is to replace DOM2CSS, I assume we should refer to CSSOM. I think we need to discuss this: DOM2CSS is CR, CSSOM is ED. >>= 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. >>2. I do not understand the use case of creating a >>MediaTypeChangedEvent from JavaScript. This comment applies to all >>the events that are defined in this specification. It is quite underspecified at present. In general the events are triggered once something happens to the UA and UA is aware of that (e.g. from OS). E.g. MediaTypeChangeEvent could be triggered if the UA gets connected to the projector. In such a case my assumption is (not discussed yet in the group) a few events would be triggered (order unknown), since not only media type changed but also potentially resolution, orientation etc. So my immediate and temporary idea could be to issue just one event (instead of the current few events) and let the script check what actually happened by means of CSSOM. Any thoughts on that? On the other hand, this question may be related to appendMedium/deleteMedium when setting mediaText. >> >>3. The pragmas of the links behind "Event.initEvent()" are wrong. >>They lead to the top of the document DOM3-Events, instead of to the >>correct section. Fixed for initEvent(). initXXXEventNS() were removed from D3E as of its version 1.99 (proposed as a new feature, links broken there as well). Since this is a discussion point, I will keep the initXXXEventNS() BROKEN as they are; I marked them as a proposal (in yellow as is D3E). >> >>= 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). 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. >> >>= Section 3.5: >> >>1. Copy/paste error in multiple places where "media type" is used >>instead of "orientation". This was fixed as of VMI 1.3 [2]. >> >>2. iphone's orientation events use degrees instead of >> "landscape"/"portrait". That allows developers to know if the handset >>is held upside-down. Good point. I think CSS / CSSOM should be upgraded first. The general model is that VMI refers to CSSOM wherever possible to keep consistency. Thanks, Marcin [1] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0764.html [2] http://dev.w3.org/cvsweb/~checkout~/2006/waf/widgets-vm/vm-interfaces.src.html?rev=1.3&content-type=text/html;%20charset=iso-8859-1 ________________________________________ 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 Monday, 7 December 2009 14:01:44 UTC