- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Mon, 03 Sep 2012 16:04:53 -0400
- To: Glenn Adams <glenn@skynav.com>
- CC: www-style@w3.org
On 9/3/12 1:38 AM, Glenn Adams wrote: > I've drafted this behavior at [1][2]. Your review would be appreciated. Looking at deleteRule[1], some comments: 1) An exception in Step 1 of the algorithm is impossible: since the WebIDL says the argument is unsigned long, WebIDL will guarantee that this algorithm only sees nonnegative values. 2) At least some UAs will throw if you try to delete a rule from a stylesheet that's not done loading yet. Not sure whether this should be in the spec or not... 3) At least some UAs do a same-origin check on deleteRule calls and disallow deleting a rule from different-origin sheets. Not sure whether they all do and whether there's a real security hole involved if that's not done, but worth checking. 4) In step 4 of the algorithm, it's not clear whether what needs to happen is an actual invocation of the cssRules ES getter on the object in question followed by the invocation of the .item() method on the return value of that getter, or whether that step refers to the "canonical" cssRules getter and item() method, ignoring any page modifications. The correct behavior is to do the latter. 5) In step 5, same issue: it's not obvious clear that this is just referring to the internal state of the rule as opposed to the API (in which parentStyleSheet is readonly). It may be a good idea to distinguish between internal states and API invocations, in general. Other than that, deleteRule is fine. Looking at parentStyleSheet[2], I think the first Note is overconstraining. For example, it contradicts any other specification defining a way to create rules outside stylesheets. It's not clear to me whether the second Note matches implementation reality; that should be tested. If it does _not_, it's worth asking implementors whether they plan to change their implementations here. My understanding is that the circular references implementing this requires are a serious problem for some implementations. In either case, being Notes, these are non-normative statements, and as a non-normative statement Note 2 doesn't make that much sense to me. If you want the spec to actually require this (which is not obvious to me), it needs to be a normative requirement. As long as I was here, one more comment. The ownerNode [3] on a stylesheet can in fact be null. This happens for @imported sheets, and also when the href of a <link rel="stylesheet"> is changed: the old sheet no longer has the <link> as its ownerNode at that point in at least Gecko. -Boris [1] http://dvcs.w3.org/hg/csswg/raw-file/tip/cssom/Overview.html#remove-a-css-rule [2] http://dvcs.w3.org/hg/csswg/raw-file/tip/cssom/Overview.html#widl-CSSRule-parentStyleSheet [3] http://dvcs.w3.org/hg/csswg/raw-file/tip/cssom/Overview.html#widl-StyleSheet-ownerNode
Received on Monday, 3 September 2012 20:05:27 UTC