W3C home > Mailing lists > Public > public-cdf@w3.org > January 2007

Re: comments on WICD Mobile DOM section

From: Anne van Kesteren <annevk@opera.com>
Date: Wed, 31 Jan 2007 19:35:38 +0100
To: "Svante Schubert" <Svante.Schubert@sun.com>, public-cdf@w3.org
Message-ID: <op.tm069ovn64w2qv@id-c0020.nomadprime.subscribe.loganwifi.com>


On Wed, 31 Jan 2007 19:09:53 +0100, Svante Schubert  
<Svante.Schubert@Sun.COM> wrote:
>> These are some last call comments regarding  
>> http://www.w3.org/TR/2006/WD-WICDMobile-20061122/#dom ...
>> Section 3.6.6 introduces new features for "focus traversel". I don't  
>> think a mobile profile is the right place to introduce such APIs. I'm  
>> not even sure if the CDF WG is the right place to develop such APIs. I  
>> think it would be better if the Web APIs WG developed an API for this  
>> based on existing practices.
> If we do not keep this in the spec., how long will it take for the  
> feature to be defined by the Web API WG.

I'm not sure. You could ask them though.

> We should rather take up the action to add this to the Web API spec. and  
> we will reference the definition if it is done on time.
> I suggest that once this is defined by Web API, we could deprecate the  
> use in the spec.
>> Section 3.6.10 states "org.w3c.dom.AbstractView" must be an  
>> implementation of the Window interface. I don't really understand that  
>> sentence. For one, note that Window, as defined by the Window Object  
>> 1.0 specification, inherits from AbstractView.
> The spec. says that the AbstractView associated with a DocumentView  
> (i.e., its defaultView attribute/member) must implement the Window  
> interface. So this is saying that the value of defaultView must be a  
> Window implementation, not just an AbstractView implementation. I would  
> welcome a better wording if one is proposed.

Yes, and I'm saying Window, as defined, inherits from AbstractView. So  
objects implementing AbstractView implementing Window doesn't make much  
sense to me.

>> Section 3.6.11 should probably be more detailed on how exactly the  
>> contents of such an attribute are interpreted as event listener.  
>> http://www.whatwg.org/specs/web-apps/current-work/#event-handler-attributes  
>> contains language that goes into direction of the detail you would need  
>> in order to implement such features.
> What would be your suggestion of wording?

The wording of the document I referenced would be fine with me.

>> What section 3.6.12 is trying to say is not clear to me either. Is it  
>> an informative section?
> What these two sections 3.6.11 & 3.6.12 say is that the event attributes  
> in XHTML or SVG (like onload, onmouseup etc..) map to the registration  
> of an even listener for a specific DOM Level 3 event. Section 3.6.11  
> gives the mapping for XHTML and 3.6.12 gives the mapping for SVG. For  
> example, we should be able to test that if we dispatch a 'mousedown'  
> event, the listener contained in a 'onmousedown' attribute is invoked  
> during the proper phase (bubble).

I meant that we already normatively reference SVG. As such, I'm wondering  
what section 3.6.12 is for. If it's just to clarify how this works for  
SVG, the section should probably be clearly marked non-normative.


Anne van Kesteren
Received on Wednesday, 31 January 2007 18:35:55 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:02:22 UTC