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

Re: [cssom-view] comments on StyleMedia interface

From: Simon Fraser <smfr@me.com>
Date: Tue, 17 Aug 2010 15:55:58 -0700
Cc: www-style@w3.org, "L. David Baron" <dbaron@dbaron.org>
Message-id: <0B813AA7-9BA2-46A4-A38B-9D4782105C52@me.com>
To: Anne van Kesteren <annevk@opera.com>
On Aug 17, 2010, at 3:45 PM, Anne van Kesteren wrote:

> On Wed, 18 Aug 2010 00:29:15 +0200, Simon Fraser <smfr@me.com> wrote:
>> On Aug 17, 2010, at 2:56 PM, Anne van Kesteren wrote:
>>> interface MediaQuery {
>>> // The serialized form of the query list used to create this object.
>>> // (Anne: renamed query to media.)
>>> readonly attribute DOMString media;
>> I think 'query' was better, since it matches the parameter name to matchMedia() above. Media could be misinterpreted as a list of media types.
> Ah, that argument name was not really meant to mean anything. I guess it depends on whether matchMedia accepts a single media query or a list of media queries. If indeed a single I agree that query makes more sense, but then it should probably also be matchMediaQuery().
> (At which point I also wonder if maybe we should then just put it directly on the Window object and get rid of styleMedia and styleMedia.type.)

Yeah, it does feel a bit like we have one too many levels here.

>>> // add and remove listeners (should it ensure uniqueness or not?)
>>> void addListener(MediaQueryChangeListener listener);
>>> void removeListener(MediaQueryChangeListener listener);
>>> };
>> Does calling matchMedia() multiple times with the same query return a new object every time, or a reference to an existing object?
> Given what we do elsewhere I suppose the same object would be better.

The problem with that is that the UA has to then keep MediaQuery objects around for the lifetime of the document, whether or not anyone registers any listeners on them, and since you could spew thousands of different queries at matchMedia(), that would be bad.

Received on Tuesday, 17 August 2010 22:56:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:49 UTC