Last Comment Bug 542058 - implement window.matchMedia API for matching CSS media queries (like window.evaluateMediaQuery proposal and earlier window.styleMedia.matchMedium draft spec)
: implement window.matchMedia API for matching CSS media queries (like window.e...
Status: RESOLVED FIXED
: dev-doc-complete
Product: Core
Classification: Components
Component: DOM: CSS Object Model (show other bugs)
: Trunk
: All All
: P4 normal with 3 votes (vote)
: mozilla6
Assigned To: David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch)
:
Mentors:
Depends on: 750438 652317
Blocks:
  Show dependency treegraph
 
Reported: 2010-01-25 13:06 PST by David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch)
Modified: 2013-01-07 16:51 PST (History)
15 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
simple demo page (1.24 KB, text/html; charset=UTF-8)
2010-01-25 13:07 PST, David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch)
no flags Details
patch 1: given infallible malloc, stop checking for failed CSS parser allocation (13.49 KB, patch)
2011-04-20 23:05 PDT, David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch)
bzbarsky: review+
Details | Diff | Splinter Review
patch 2: allow null media query cache key where needed (4.58 KB, patch)
2011-04-20 23:06 PDT, David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch)
bzbarsky: review+
Details | Diff | Splinter Review
patch 3: implement and test window.matchMedia() (40.79 KB, patch)
2011-04-20 23:06 PDT, David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch)
no flags Details | Diff | Splinter Review
patch 3: implement and test window.matchMedia() (42.19 KB, patch)
2011-04-20 23:34 PDT, David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch)
bzbarsky: review+
Details | Diff | Splinter Review

Description David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2010-01-25 13:06:33 PST
We should implement a DOM API for matching CSS media queries. This would be useful both for our chrome (e.g., would make bug 498312 easier and more accurate) and useful for Web authors.

It's already possible by adding style sheets and then querying computed style, but it's quite a bit of work (and probably slow for many uses).

There are two proposals I've seen for such an API:

http://webkit.org/specs/MediaQueriesExtensions.html#DOM-Window has a proposal for window.evaluateMediaQuery()

http://dev.w3.org/csswg/cssom-view/#dom-media-matchmedium has a proposal for window.media.matchMedium()

It looks like trunk WebKit (including chromium) has implemented window.media.matchMedium, which I think means the first proposal is obsolete.  (And I hope the rest of that document is obsolete too.)
Comment 1 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2010-01-25 13:07:46 PST
Created attachment 423404 [details]
simple demo page
Comment 2 Anne (:annevk) 2010-03-17 08:42:08 PDT
It is now http://dev.w3.org/csswg/cssom-view/#dom-stylemedia-matchmedium

I didn't know it was already implemented, but Apple told me they are updating because they agree the renaming will help avoid clashes.
Comment 3 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2010-04-01 15:13:56 PDT
One addition that could be useful here is a way to register a callback when the result of evaluating a query changes.  (We already have code to optimize such things for CSS's use of media queries, and it requires much less notification than callbacks whenever the value of any media feature changes.)
Comment 4 Anne (:annevk) 2010-04-02 11:59:10 PDT
Would that not be expensive? Anyway, put it forward on www-style?
Comment 5 Paul Rouget [:paul] 2010-04-20 08:39:36 PDT
This feature interests a lot of web dev and it would be really useful for mobile development.
Comment 6 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2010-07-14 09:53:42 PDT
There's a thread on www-style from May through to the present about this, with subject "[cssom-view] addMediumListener / removeMediumListener".
Comment 7 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2011-03-18 22:03:06 PDT
Looks like the spec is now window.matchMedia(), returning an object, rather like what I suggested in the thread in comment 6.
Comment 8 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2011-04-20 12:28:00 PDT
Sent http://lists.w3.org/Archives/Public/www-style/2011Apr/0599.html
Comment 9 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2011-04-20 14:20:09 PDT
Current work in progress (remaining work is in the TODOs at the top):
http://hg.mozilla.org/users/dbaron_mozilla.com/patches/raw-file/70e160bb8023/window-matchMedia
Comment 10 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2011-04-20 23:05:40 PDT
Created attachment 527481 [details] [diff] [review]
patch 1: given infallible malloc, stop checking for failed CSS parser allocation
Comment 11 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2011-04-20 23:06:05 PDT
Created attachment 527482 [details] [diff] [review]
patch 2: allow null media query cache key where needed
Comment 12 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2011-04-20 23:06:27 PDT
Created attachment 527483 [details] [diff] [review]
patch 3: implement and test window.matchMedia()
Comment 13 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2011-04-20 23:34:40 PDT
Created attachment 527490 [details] [diff] [review]
patch 3: implement and test window.matchMedia()

I added a few more code comments to document interesting things.
Comment 14 Boris Zbarsky [:bz] 2011-04-21 10:42:53 PDT
Comment on attachment 527481 [details] [diff] [review]
patch 1: given infallible malloc, stop checking for failed CSS parser allocation

r=me
Comment 15 Boris Zbarsky [:bz] 2011-04-21 10:44:09 PDT
Comment on attachment 527482 [details] [diff] [review]
patch 2: allow null media query cache key where needed

r=me
Comment 16 Boris Zbarsky [:bz] 2011-04-21 10:59:00 PDT
Comment on attachment 527490 [details] [diff] [review]
patch 3: implement and test window.matchMedia()

>+    // Note that we intentionally send the notifications in the order
>+    // (a) media query lists in the order created and (b) each list's
>+    // listeners in the order added.

That first "in the order" bit doesn't really make sense with what follows.... rephrase?

r=me with that nit.
Comment 17 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2011-04-21 13:30:02 PDT
Rephrased as:
    // Note that we intentionally send the notifications to media query
    // lists in the order they were created and, for each list, to the
    // listeners in the order added.
Comment 19 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2011-04-22 23:29:24 PDT
Oh, and in order to fix a test failure, I made one other change before landing, which was to change the IsSafeToRunScript assertion into:

  if (!nsContentUtils::IsSafeToRunScript()) {
    NS_ABORT_IF_FALSE(mDocument->IsBeingUsedAsImage(),
                      "How did we get here?  Are we failing to notify "
                      "listeners that we should notify?");
    return;
  }

since we do get MediaFeatureValuesChanged notifications in image documents when it's not safe to run script, since their flush implementation allows flushes through when it isn't.
Comment 20 Boris Zbarsky [:bz] 2011-04-23 00:24:56 PDT
It just occurred to me... should we be calling this MozMatchMedia?
Comment 21 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2011-04-23 09:47:20 PDT
Blogged at: http://dbaron.org/log/20110422-matchMedia

Regarding prefixes:  I'm generally somewhat skeptical about prefixing DOM APIs, especially ones in draft specs.  But do you think we should?  (And, fwiw, WebKit is currently shipping with the previous draft proposal, window.styleMedia, unprefixed.)
Comment 22 Eric Shepherd [:sheppy] 2011-04-24 19:07:04 PDT
We have prefixed some DOM APIs but not others. I personally am in favor of it, because if things change drastically it makes it easier to clarify documentation.
Comment 23 :Ms2ger 2011-04-25 00:23:55 PDT
FWIW, Chrome 12 is shipping with window.matchMedia and window.styleMedia, both unprefixed. It doesn't seem worth it to prefix here.
Comment 24 Dão Gottwald [:dao] 2011-04-25 01:09:01 PDT
(In reply to comment #23)
> FWIW, Chrome 12 is shipping with window.matchMedia and window.styleMedia, both
> unprefixed. It doesn't seem worth it to prefix here.

Isn't window.styleMedia obsolete? Seems like a bad example for introducing bleeding-edge stuff non-prefixed...
Comment 26 Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]] 2011-08-15 18:08:50 PDT
marked sec-review-needed and assigned to Jesse to make fuzzer modifications

Note You need to log in before you can comment on or make changes to this bug.