- 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