- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 21 Feb 2006 18:49:55 +0000 (UTC)
- To: Steve K Speicher <sspeiche@us.ibm.com>
- Cc: public-cdf@w3.org
On Mon, 20 Feb 2006, Steve K Speicher wrote: > > Due to the nature of constrained devices within the mobile industry, > many vendors have coordinated such subset profiles and therefore will > depend on CDF profiles to provide interoperable rich content to such > devices. ...which has nothing to do with the Web (since such devices wouldn't interoperate with existing Web content) and therefore shouldn't be in scope of the W3C. This does not satisfy my concerns. I fear that CDF is encouraging, or justifying, a "split Web" situation with multiple profiles, which is directly counter to the device-independent design of the Web and of W3C's design principles. > > * http://www.w3.org/TR/2005/WD-CDR-20051219/#child-to-parent-dom-access > > > > The ReferencedDocument interface requires that implementations perform > > security checks at the element level. Historically, implementations > > have only needed to perform checks at the Document/Window boundary. > > Changing this will introduce a very high potential for security bugs. > > > > Please do not introduce the ReferencedDocument interface. > > > > Instead, the Window.parent member can be used in existing UAs to get > > to the parent Window context. > > > > Please coordinate with the new Web APIs group in creating > > specifications for the Window interface. > > Since the CDF Framework document addresses generic DOM-based markups, we > can not rely on the HTML DOM (where Window.parent resides) and this > doesn't satisfy a need to determine the element in the parent document > that is the doing the referencing. Window.parent does not live in the HTML DOM. (It is of some concern to me that the CDF working group would make this mistake.) > We have discussed with the Web APIs WG. They have reviewed our proposal > and recommend we progress with what we have specified. We will continue > to coordinate with Web APIs WG as at some point they may adopt this. I have not seen any such recommendation and have indeed heard from Web API members that there has not been any such recommendation. This does not satisfy my request. Please do not specify new DOM APIs that require an increase of complexity in the security model of the Web. The current security model is already extremely complex. > > * http://www.w3.org/TR/2005/WD-CDR-20051219/#event-propagation > > > > Please define what "events targetted at the document shall propagate > > to the parent document" means, in particular in terms of the DOM3 > > Events capture phase. > > This may read better as "events targeted at the child document shall > propagate to the parent document". An event can bubble or be targeted > from the child document to its parent document(depending on the > propagate attrib). This doesn't even remotely address my issue. Please address my issue by defining it _in terms of the DOM3 Events model_, for example stating how capture works, how bubbling works, how cross-document security works, and so forth. This is required because the DOM3 Events model does not in any way define cross-document event handling. > > * http://www.w3.org/TR/2005/WD-CDR-20051219/#event-related-legacy-markup > > > > "what phases it supports" implies that some events may support less > > than all the phases. This is incorrect. > > > > Please remove the mention of "what phases it supports". > > It is possible to not participate in bubble phase Though the text will > be updated from: "what phases it supports (capture, target, bubble)" to > "whether it supports the bubble phase" "Supports" is not the right word here, since any event type can be dispatched with or without bubbling. The correct terminology would be "whether it bubbles", or some such. (Of course that entire section is redundant, since any spec must define all these details regardless of the CDF spec.) Your other responses are satisfactory. Cheers, -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 21 February 2006 18:50:10 UTC