- From: Anne van Kesteren <annevk@opera.com>
- Date: Thu, 12 Aug 2010 12:24:06 +0200
- To: www-style@w3.org, "L. David Baron" <dbaron@dbaron.org>
On Sun, 18 Jul 2010 01:18:55 +0200, L. David Baron <dbaron@dbaron.org> wrote: > http://dev.w3.org/csswg/cssom-view/#extensions-to-the-window-interface > says: > # The styleMedia attribute must return the StyleMedia object > # associated with the Window object. It always returns the same > # object. > > Given the mess around what exactly is a window object, this should > probably be extra-precise, and say it returns the same object for > each Window object, but accessing it through a WindowProxy object > http://www.w3.org/TR/2010/WD-html5-20100624/browsers.html#the-windowproxy-object > will yield different results when the document is navigated. > Returning the same result for each WindowProxy would lead to > confusion of listeners between different documents in the same > browsing context, which would be bad (and might even have security > implications). Added a note. (Also for window.screen.) > http://dev.w3.org/csswg/cssom-view/#the-stylemedia-interface says: > # 2. If parsed_mq_list is null terminate these steps. > It's not clear to me what this means. [CSSOM]'s description of > "parse a list of media queries" does not return null. But if it > did, this item would need to say whether the method returns true or > false or throws an exception. A yes, removed these everywhere. Parsing a list of media queries never fails. > # 3. If parsed_mq_list matches the state of the rendered Document > # return true and terminate this algorithm. > # > # 4. Otherwise, return false. > "matches the state of the rendered Document" doesn't seem to be a > term defined anywhere, though it sort of looks like it ought to be. > I'm not sure if it's worth trying to fix, though. But perhaps these > two steps could be combined in the form "return whether ...". Merged. I was not quite sure how to define it. I took this from HTML5. This is also used for styleMedia.type by the way. If anyone has suggestions I can clarify it. > I'd also note that I find the observer mechanism somewhat awkward, > for two reasons: first, the limited amount of information provided > by the callback, and second, the need to have a query comparison > mechanism in order to add/remove listeners. The first we discussed and is addressed by using a simple closure. The second is indeed not very nice, but matches event listeners. > I can think of an alternative that would fix both of these problems, > although I'm not sure if I like it any better than what's now in the > spec. But, in case anyone else likes it, the idea is to, in place > of addMediaListener, removeMediaListener, and BooleanCallback, add a > method to StyleMedia that takes a string and returns a new > MediaQuery object, implementing: > interface MediaQuery { > // The serialized form of the query list used to create this object. > readonly attribute DOMString query; > // The current result of the query. > readonly attribute boolean result; > // add and remove listeners (should it ensure uniqueness or not?) > void addListener(MediaQueryChangeListener listener); > void removeListener(MediaQueryChangeListener listener); > }; > [Callback=FunctionOnly, NoInterfaceObject] > interface MediaQueryChangeListener { > void queryChanged(MediaQuery query); > }; I left in what we have now since nobody seems to be jumping for this :-) Though it's quite a neat API I have to say. -- Anne van Kesteren http://annevankesteren.nl/
Received on Thursday, 12 August 2010 19:15:00 UTC