W3C home > Mailing lists > Public > www-style@w3.org > August 2010

Re: [cssom-view] comments on StyleMedia interface

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>
Message-ID: <op.vhbi65pl64w2qv@anne-van-kesterens-macbook-pro.local>
On Sun, 18 Jul 2010 01:18:55 +0200, L. David Baron <dbaron@dbaron.org>  
> 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  

>   # 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
Received on Thursday, 12 August 2010 19:15:00 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:13:49 UTC