Last Comment Bug 438278 - Implement getMatchedCSSRules
: Implement getMatchedCSSRules
Status: NEW
[firebug-p3]
:
Product: Core
Classification: Components
Component: DOM (show other bugs)
: unspecified
: All All
: -- enhancement with 6 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Andrew Overholt [:overholt]
Mentors:
Depends on: 536379
Blocks:
  Show dependency treegraph
 
Reported: 2008-06-09 22:13 PDT by William J. Edney
Modified: 2015-02-24 00:14 PST (History)
18 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
patch wip (9.30 KB, patch)
2010-02-16 17:53 PST, Nochum Sossonko [:Natch]
no flags Details | Diff | Splinter Review
patch wip (15.76 KB, patch)
2010-02-16 17:56 PST, Nochum Sossonko [:Natch]
no flags Details | Diff | Splinter Review

Description William J. Edney 2008-06-09 22:13:39 PDT
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_3; en-us) AppleWebKit/525.18 (KHTML, like Gecko) Version/3.1.1 Safari/525.20
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9) Gecko/2008053008 Firefox/3.0

Webkit has a very nice enhancement to its DOM - getMatchedCSSRules(), which allows JavaScript-based retrieval of all CSS rules which are currently being applied to an element.

It is documented here: http://beta.devworld.apple.com/documentation/Cocoa/Reference/WebKit/Classes/DOMDocument_WebKitAdditions/DOMDocument_WebKitAdditions.pdf

Obviously the DOM Inspector, when installed, has an API for this functionality, but it'd be great to access it without requiring XPCOM privileges.

Thanks in advance.

Cheers,

- Bill

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
Comment 1 Nochum Sossonko [:Natch] 2008-06-10 21:45:26 PDT
How's it different than the standard getComputedStyle()?

http://www.w3.org/TR/2000/REC-DOM-Level-2-Style-20001113/css.html#CSS-CSSview-getComputedStyle
Comment 2 William J. Edney 2008-06-10 22:43:21 PDT
Natch -

getComputedStyle() hands you back a single CSSStyleDeclaration programmed with the final cascaded, computed style for that element.

This method is different in that it hands you back a list of all of the rules currently applying to the element. It is very useful when introspecting on an Element to find out all of the rules in all of the various stylesheets that are applying to the Element.

Cheers,

- Bill 
Comment 3 Nochum Sossonko [:Natch] 2009-02-21 23:32:30 PST
David, would Mozilla take this extension?
Comment 4 William J. Edney 2009-02-22 07:28:04 PST
David -

Should you decide to take this (:-) ), here's an example snippet of code from both Gecko and Webkit that show how I as a JavaScripter interact with both APIs (note here that I repackage the results of both calls into an Array - 'anElement' is the element in question):

Gecko way:

queryObj = Components.classes[
                        '@mozilla.org/inspector/dom-utils;1'].getService(
                                Components.interfaces.nsIDOMUtils);

            rules = queryObj.getCSSStyleRules(anElement);

            //  Repackage this into an array for convenience.
            ruleArray = [];
            for (i = 0; i < rules.Count(); i++)
            {
                ruleArray.push(rules.GetElementAt(i));
            };

Webkit way:

        //  Note here how we *must* supply the empty string for the 'pseudo
        //  element'
        //  (elemWin here is the Window object of the element in question).
        rules = elemWin.getMatchedCSSRules(anElement, '');

        //  Repackage this into an array for convenience.
        ruleArray = [];
        for (i = 0; i < rules.length; i++)
        {
            ruleArray.push(rules[i]);
        };

The Gecko way has 2 very distinct disadvantages:

1. The DOM Inspector extension must be installed
2. XPCOM privileges must be granted.


Thanks for looking into this!

Cheers,

- Bill
Comment 5 David Baron :dbaron: ⌚️UTC-10 2009-02-22 09:42:08 PST
This sounds good to me.

I would expect a Web-accessible way only to give the rules that are in author style sheets, and not give pages access to user and UA style sheets like Inspector's DOMUtils's getCSSStyleRules does?  Is that what WebKit's implementation does?
Comment 6 Nochum Sossonko [:Natch] 2009-02-22 10:12:35 PST
Webkit has 2 versions of the function, one of them has 3 arguments, the last one being a bool specifying whether or not to return authorOnly rules. Is that fine or is there a problem in handing back ua-styles (i.e. should we force non-chrome callers to use the authorOnly mode)?

Here's the idl definitions:  http://developer.apple.com/documentation/AppleApplications/Reference/WebKitDOMRef/Document_idl/Classes/Document/CompositePage.html#//apple_ref/IDL/instm/Document/getMatchedCSSRules/CSSRuleList/(inElement,inDOMString)
Comment 7 David Baron :dbaron: ⌚️UTC-10 2009-02-22 10:25:31 PST
We'd need to give non-chrome callers only author rules.  (We could potentially consider doing otherwise if we had a way to hand back the user and UA rules in a way that the page couldn't change them; however, I'm still not sure whether I'd be ok with the information leak.)
Comment 8 William J. Edney 2009-02-22 17:28:51 PST
David -

Not sure I can make a strong case for accessibility to UA rules, given that 'breakage' of them is breakage of the UA itself.

However, I am building a JS tool that would allow page designers to see and manipulate rules on-the-fly. It'd be really great to have access to all rules, such that user rules could at least be displayed so that page authors know why, even thought they're editing a rule, it is not taking effect in the intended way.

In this mode, user rules wouldn't be editable or at least changes to them wouldn't persist.

Thoughts?

Thanks again!

Cheers,

- Bill
Comment 9 Nochum Sossonko [:Natch] 2009-02-25 21:05:10 PST
Tentatively taking but it will probably take me a while to come up with something, so feel free to steal it from me.
Comment 10 David Baron :dbaron: ⌚️UTC-10 2009-02-25 21:23:45 PST
You probably want to do something roughly like:
 * add a new method to nsIDOMNSDocument (in the idl, and bump the IID)
 * add a simple implementation of nsIDOMCSSRuleList to hold a given list of
   rules (rather than our current implementations that proxy to some other object)
 * implement it in nsDocument.cpp by:
    + calling nsInspectorCSSUtils::GetStyleContextForContent, which gives you
      a style context for the content node
    + walking up the chain of rule nodes from that style context's rule node,
      and using the rule for those that are author-level and non-!important,
      and putting those in the resulting rule list in the appropriate order
Comment 11 Nochum Sossonko [:Natch] 2009-02-26 14:37:05 PST
@Bill: Does Webkit have any docs where I can read up some specs?

@David: Should the function have a moz prefix (ie mozGetMatchedCSSRules)?
Comment 12 William J. Edney 2009-02-26 19:23:14 PST
Natch -

I haven't found any. Sorta stumbled upon the fact that Webkit could do this when I saw it and played with it a bit. I got excited about it and filed the bug here.

I did dig around in the Webkit source a bit (gosh, its been a long time since I did C...) and I found that this call on their 'DOMWindow' turns around and calls their 'CSSStyleSelector::styleRulesForElement' call. I'm sure you could poke around in there and see what they're up to:

http://trac.webkit.org/browser/trunk/WebCore/css/CSSStyleSelector.cpp

Not to speak for David, but I wouldn't assume that it would be 'mozGetMatchedCSSRules'. Those prefixes are normally reserved for the DOM equivalent of 'Mozilla only' CSS style properties when accessing through a '.style' object, like '<elemRef>.style.MozUserSelect = "text"' or some such. David, feel free to correct me here.

Thanks so much for taking on this bug, Natch!

Cheers,

- Bill
Comment 13 Boris Zbarsky [:bz] (still a bit busy) 2009-11-02 12:43:42 PST
Note that if you implement per comment 10 you better make the rules readonly somehow.  If you want to allow them to be writable, you need to force eager cloning of the stylesheet inners when you create that array of rules.  Then trigger a style reresolve.  Then rebuild your array of rules.  Or something.  You might want to talk to John J Barton about how firebug handles that....
Comment 14 Nochum Sossonko [:Natch] 2009-11-03 10:51:00 PST
So, the thing that has been holding me up a bit here is that I can't seem to find a way to get the rule out of the nsStyleContext as an nsIDOMCSSRule. Basically, I'm not very familiar with the mechanics of nsStyleContext, so all I get is the nsRuleNode out of it, but I'm pretty much stuck there. Am I suppose to fill in the nsICSSRule myself from the data provided by the nsStyleContext?

Note: nsInspectorCSSUtils was removed so I'm using the equivalent function from nsComputedDOMStyle.
Comment 15 Boris Zbarsky [:bz] (still a bit busy) 2009-11-03 11:00:01 PST
See http://hg.mozilla.org/mozilla-central/file/bbbc9c83cdf7/layout/style/nsRuleNode.h#l755
Comment 16 Boris Zbarsky [:bz] (still a bit busy) 2009-12-30 08:48:47 PST
Bug 536379 will implement the cloning thing you need here, at least for document stylesheets.
Comment 17 Boris Zbarsky [:bz] (still a bit busy) 2010-01-22 11:21:43 PST
Natch, are you still working on this?
Comment 18 David Baron :dbaron: ⌚️UTC-10 2010-01-22 12:34:46 PST
(In reply to comment #11)
> @David: Should the function have a moz prefix (ie mozGetMatchedCSSRules)?

Given that WebKit is shipping it without a prefix, no.  (But we should test that our implementation is doing basically the same thing.)
Comment 19 Nochum Sossonko [:Natch] 2010-01-23 16:00:15 PST
(In reply to comment #17)
> Natch, are you still working on this?

I started a while back, but have been very busy with personal stuff since. Unfortunately I won't be able to actively work on this in the immediate future, I'm not sure when I'll be able to finish this. I'll unassign for now, if in the future I get back around to it, I'll reassign.
Comment 20 William J. Edney 2010-01-23 16:16:08 PST
Natch -

Thanks for trying - I appreciate it.

Anyone else interested? I could *really* use this.

Thanks in advance!

Cheers,

- Bill
Comment 21 David Baron :dbaron: ⌚️UTC-10 2010-01-24 08:48:51 PST
Did you have work-in-progress that you could attach here so somebody else could continue?
Comment 22 John J. Barton 2010-01-25 09:21:43 PST
(In reply to comment #4)

> The Gecko way has 2 very distinct disadvantages:
> 
> 1. The DOM Inspector extension must be installed

This part of the reason to implement is no longer correct. Quite a long time ago this began to work:
   domUtils = CCSV("@mozilla.org/inspector/dom-utils;1", "inIDOMUtils");

> 2. XPCOM privileges must be granted.

The use case in comment #8 it for a development tool. An extension can use the existing facility without privilege issues. 



> 
> 
> Thanks for looking into this!
> 
> Cheers,
> 
> - Bill
Comment 23 William J. Edney 2010-01-25 12:50:50 PST
John -

Glad to see that DOM Inspector must no longer be installed, but that's the lesser of the 2 problems here for me.

I'm building a completely cloud-based IDE wherein I do not ask the user for any special privilege whatsoever. Right now, I can accomplish this on Webkit-based browsers without asking for any special permissions by using getMatchedCSSRules(). Without this call on Mozilla, I cannot accomplish the same end effect without packaging this as an extension, which I have no intention of doing as this is intended to be a 'cross-browser' solution.

Adding this call would bring Mozilla up to parity with Safari and Chrome and allow me to recommend Mozilla-based browsers with the same level of enthusiasm.

Cheers,

- Bill
Comment 24 Nochum Sossonko [:Natch] 2010-02-16 17:53:22 PST
Created attachment 427250 [details] [diff] [review]
patch wip

Ok, here's the patch I was working on (sorry about the lateness, haven't had any time to clean it up). It currently fails with a security failure (which I'm guessing might be coming from the |.get()| call at the end, I think it calls QI which creates the wrapper, could be totally wrong).

Left to do:

1) Handle mutations to the styles.
2) Handle UA style sheets.
3) Probably some code cleanup.
4) TESTS!!

That doesn't sound like a lot, but it probably is...

Good luck to whomever takes this up next.
Comment 25 Nochum Sossonko [:Natch] 2010-02-16 17:56:25 PST
Created attachment 427252 [details] [diff] [review]
patch wip

Sorry for the spam, forgot to hg add the new files...
Comment 26 Boris Zbarsky [:bz] (still a bit busy) 2010-02-16 18:00:59 PST
The security error is due to lack of classinfo on nsDOMCSSRuleList.

The links in comment 6 and comment 0 are both dead, so I can't tell whether this is compatible with what Webkit implements (e.g. whether they return live or non-live lists, what item 1 from comment 24 means, whether the handling of !important or rules that match a node more than once is the same, etc).
Comment 27 Nochum Sossonko [:Natch] 2010-02-16 18:04:11 PST
(In reply to comment #26)
> The security error is due to lack of classinfo on nsDOMCSSRuleList.

Indeed! Completely forgot about the classinfo stuff (although I swear this worked without a security error a couple of months ago). In any event, I won't be able to do much with this for the foreseeable future...
Comment 28 Boris Zbarsky [:bz] (still a bit busy) 2010-02-16 18:07:21 PST
I can probably pick this up and drive it in if someone can point me to docs on what webkit actually implements.
Comment 30 William J. Edney 2010-02-16 18:49:06 PST
Boris -

Thanks for looking at this. Sorry that the docs are so thin (uhh... nonexistent... ;-) ) here. The only thing I can tell from the code link above is that it looks like, on Webkit, only access to the author rules are provided to the JS API (which I was unaware of when I asked for this feature). Still, the API has a lot of usefulness to me.

Therefore I'd be willing to post a set of questions to webkit-dev mailing list and gather the data for you from the fine folks over there if you would care to post those questions here.

Thanks again!
Comment 31 Boris Zbarsky [:bz] (still a bit busy) 2010-02-16 19:19:12 PST
Hmm.  So looking through their current code, what's there is pretty different from that first landing....

They expose the method on Window, looks like, not Document (though they seem to have idl for both).  Their code will happily return null if there are no matching rules instead of returning an empty list; I don't think we should duplicate that.

I checked what they do if you try to get the non-author rules and then modify them.  Safari crashes very nicely if you do that.  Filed https://bugs.webkit.org/show_bug.cgi?id=35014

The list they return is non-live.

The rules in their list are sorted in least to most important order, ignoring !important issues (since those are on the property level, not the rule level).

Looks like if a rule matches a node more than once it'll be in the list more than once, with the locations determined by the selectors that matched.  That's the easy thing for us to do as well.

So it sounds to me like we should disallow access to the non-author rules from untrusted script, change things so that we're not actually resolving a style context but are just getting a list of rules (should be _much_ faster in display:none subtrees), and test carefully....
Comment 32 Boris Zbarsky [:bz] (still a bit busy) 2010-02-16 19:20:39 PST
Oh, and probably need security checks on rules that are not same-origin with the caller.  It doesn't look like Webkit has those, and they're a must.
Comment 33 Boris Zbarsky [:bz] (still a bit busy) 2010-02-16 19:29:26 PST
I filed https://bugs.webkit.org/show_bug.cgi?id=35015 on the same-origin thing.
Comment 34 William J. Edney 2010-02-16 19:53:25 PST
Excellent!

Let me know if there is anything I can do (besides cheering from the sidelines :-) ).

Thank you!
Comment 35 Boris Zbarsky [:bz] (still a bit busy) 2010-02-16 20:13:19 PST
Write a test?  See https://developer.mozilla.org/en/Mochitest#Writing_tests
Comment 36 William J. Edney 2010-02-16 21:54:02 PST
You got it!

Coming up.
Comment 37 Anne (:annevk) 2010-02-17 03:03:44 PST
Would be cool if this is brought up on www-style as well for non-Gecko/WebKit-based browsers, especially since the plan is to expose it to Web content.
Comment 38 Boris Zbarsky [:bz] (still a bit busy) 2010-03-22 18:35:00 PDT
I'm not planning to work on this (at least for web script) pending the outcome of the discussion in https://bugs.webkit.org/show_bug.cgi?id=35015 (where the latest comments have been suggestions to remove this feature from Webkit).
Comment 39 William J. Edney 2010-03-22 18:52:40 PDT
Boris -

I've been totally remiss in getting the tests done for this - so much other stuff got in the way. Sorry.

Thanks for the heads up re: the status of this feature in Webkit. It sure would be a shame if this feature went away in Webkit. Unfortunately, my login there doesn't give me access to the bug you mentioned - I assume there's a security problem. This effectively mutes me from stating my case as to the usefulness of this call. I guess I just don't see a security issue here, especially if either no access or read-only access were given to user-agent rules.

If you could please keep this bug up-to-date with the latest goings-on over there, I sure would appreciate it. Should that issue work itself out, ping this bug and I get to working on these tests - I promise :-).

Cheers,

- Bill
Comment 40 Boris Zbarsky [:bz] (still a bit busy) 2010-03-22 19:25:11 PDT
> I assume there's a security problem.

Yes.

> If you could please keep this bug up-to-date with the latest goings-on over
> there

Will do.
Comment 41 :Ms2ger (⌚ UTC+1/+2) 2011-10-14 09:29:00 PDT
(In reply to Boris Zbarsky (:bz) from comment #40)
> > I assume there's a security problem.
> 
> Yes.
> 
> > If you could please keep this bug up-to-date with the latest goings-on over
> > there
> 
> Will do.

I'm interested as well :)
Comment 42 Boris Zbarsky [:bz] (still a bit busy) 2011-10-14 09:48:26 PDT
> I'm interested as well :)

I just cced you on the webkit bug.
Comment 43 maggotfish 2012-07-02 05:43:36 PDT
I've written a short Gist that polyfills this for Gecko:

https://gist.github.com/3033012

HTH (:
Comment 44 Boris Zbarsky [:bz] (still a bit busy) 2012-07-06 10:24:55 PDT
For some values of "polyfills", yes.  ;)  (Media handling is buggy, ordering looks buggy, no support for @import, @media, etc.)
Comment 45 maggotfish 2012-07-07 04:42:35 PDT
It's just a POC implementation.
Anyhow:

* I don't see how media handling is buggy. Could you be more specific?
* Ordering? I'm not familiar with that aspect, what does it mean in this context?
* @import, @media: Yes, no support for now (just a POC), but if there's an interest it can be easily added.
Comment 46 Boris Zbarsky [:bz] (still a bit busy) 2012-07-07 08:20:06 PDT
> * I don't see how media handling is buggy. Could you be more specific?

It's just fundamentally broken in a world where browsers implement http://www.w3.org/TR/css3-mediaqueries/ (which they do).  Consider these two stylesheets:

   <style media="not print">
   <style media="all and (monochrome: 1)">

The former applies on screen but is not picked up by the script.  The latter only applies on devices which are monochrome and use one bit per pixel (so only two colors available for display; no grayscale).  Which means it basically never applies.  But it will be picked up by the script.

> * Ordering? I'm not familiar with that aspect, what does it mean in this context?

The use cases I know of for this want the rules in cascade order.
Comment 47 maggotfish 2012-07-07 13:19:50 PDT
Cool, thanks!
I've implemented proper media matching and support for @import/@media rules.
Ordering according to cascade order is TBD.
Comment 48 maggotfish 2012-09-23 03:39:27 PDT
This is basically there:
https://gist.github.com/3033012

Cheers,
~Y
Comment 49 Philip Jägenstedt 2015-01-15 02:47:13 PST
This bug was mentioned in a blink-dev thread to deprecate getMatchedCSSRules():
https://groups.google.com/a/chromium.org/d/msg/blink-dev/fd-QLCiLESQ/uqfzCsLja-MJ

Gecko developers, are you interested in standardizing and implementing this, or would you rather we try to remove it from Blink?
Comment 50 Boris Zbarsky [:bz] (still a bit busy) 2015-01-15 06:42:23 PST
I think I'm somewhat interested, subject to the constraints discussed earlier in this bug (not exposing cross-origin rules, not exposing UA/user rules, etc).

Note, though, that the extension use cases that have actually asked for this do NOT want these restrictions.  What are the non-extension (web page) use cases?
Comment 51 Philip Jägenstedt 2015-01-15 06:58:41 PST
I honestly don't know what the use cases for getMatchedCSSRules() on the general Web and can't tell from http://trac.webkit.org/changeset/11233 what the original use cases were.

I'm also not looking for reasons to keep it, as removing it seems like the faster way to reach interop...
Comment 52 brandon 2015-01-21 22:11:11 PST
Unless I'm missing another way of doing it, getMatchedCSSRules can allow Javascript to access style information for an element that is not currently displayed in the DOM. This can allow the developer to avoid repeating constants in CSS (SASS) and Javascript.

For example, here's a vertical progress bar:

    +--+
    |  |
    |  |
    +--+
    |##|
    |##|
    +--+

It's made up of two divs: the outer bar, and the inner fill. We construct it with the following function:

    function createVerticalProgressBar(fraction) {
        var bar = document.createElement("div");
        bar.className = "progress-vertbar";
        var fill = document.createElement("div");
        bar.appendChild(fill);
        fill.className = "progress-fill";
        var heightOfBar = // MAGIC!
        fill.style.height = Math.round(heightOfBar * fraction) + "px";
        return bar;
    }

The SASS file might look like this:

    $vertbar-height: 80px;
    $vertbar-width:  20px;
    
    .progress-vertbar {
    
        height: $vertbar-height;
        width: $vertbar-width;
        position: relative;
        // colors, etc. here
    
        .progress-fill {
            // height set by createVerticalProgressBar
            width: $vertbar-width;
            position: absolute;
            bottom: 0;
        }
    }

    .progress-fill {
        // colors, etc. here
    }

It seems like getMatchedCSSRules allows the implementation of the "MAGIC". Does the current API support a (better?) way?
Comment 53 Philip Jägenstedt 2015-01-22 00:29:06 PST
I don't understand, if you have a progress-bar wouldn't you simply set the height to something between 0 and 100% depending on the current progress? Can you fill in the "MAGIC" bit using getMatchedCSSRules to clarify?
Comment 54 maggotfish 2015-01-22 01:12:49 PST
I can give the use-case that led me to use it and implement the Gecko polyfill. I was working on an app for creating emails via a WYSIWYG editor. Since styles needed to be inlined for the markup generation process I needed to get the matched rules from all existing style sheets and combine with anything set via JS directly on elements.
It was important I get the original values from the matched rules and not computed ones since they were generic and allowed reuse of the markup in other user agents.
Comment 55 Philip Jägenstedt 2015-01-22 01:58:21 PST
Does the polyfill work just as well as WebKit and Blink's getMatchedCSSRules()? Would it make any difference to you if getMatchedCSSRules() were removed from Blink?
Comment 56 maggotfish 2015-01-22 02:02:39 PST
The project died in the middle, so the implementation might not be complete or buggy in edge cases, but I think it's basically functionally similar. Should Blink remove getMatchedCSSRules() this polyfill could also work there. I also say someone forked my gist and implemented support for Webkit and IE.
Comment 57 brandon 2015-01-22 02:14:56 PST
(In reply to Philip Jägenstedt from comment #53)
> I don't understand, if you have a progress-bar wouldn't you simply set the
> height to something between 0 and 100% depending on the current progress?
> Can you fill in the "MAGIC" bit using getMatchedCSSRules to clarify?

Good point; thanks for the suggestion. For some reason, I thought percent heights didn't play well with absolute positioning, but it looks fine to me.

This is not really a good example, then, of where getMatchedCSSRules overcomes a limitation. I could certainly come up with a hypothetical example that couldn't be overcome with percent styling (e.g., calculating a width based on a height). I admit that would be reaching, though, so I have no problems with removal.

For the record, this is what I had in mind for MAGIC:

    function styleOf(node, prop) {
        var styles = getMatchedCSSRules(node);
        var style = "";
        [].forEach.call(styles, function(s) {
            if (s.style[prop]) {
                // TODO: Handle !important
                style = s.style[prop];
            }
        });
        return style;
    }
    /* Then replace `var heightOfBar = // MAGIC!` with: */
    var heightOfBar = parseFloat(styleOf(bar, "height"));
Comment 58 Philip Jägenstedt 2015-01-22 04:45:00 PST
Thanks Brandon. Let me know if you come across some existing code using getMatchedCSSRules() which can't easily be replaced by a polyfill or something even simpler as in the progress bar case.
Comment 59 info 2015-02-23 08:08:36 PST
Hi guys, I’m developing a polyfill for a CSS property called `object-fit` (https://github.com/anselmh/object-fit) which needs to parse through the CSS and makes use of `getMatchedCSSRules`. 

Unfortunately the polyfill for getMatchedCSSRules mentioned here is super-slow and is likely to crash any browser when parsing a bit larger CSS file.

Therefore I’d say it would make a difference if WebKit / Blink deprecate this and it would certainly help if Firefox would implement this.
Comment 60 Sebastian Zartner [:sebo] 2015-02-23 11:01:12 PST
(In reply to info from comment #59)
> Hi guys, I’m developing a polyfill for a CSS property called `object-fit`
> (https://github.com/anselmh/object-fit) which needs to parse through the CSS
> and makes use of `getMatchedCSSRules`.
> ...
> Therefore I’d say it would make a difference if WebKit / Blink deprecate
> this and it would certainly help if Firefox would implement this.

Implement what? 'getMatchedCSSRules' or 'object-fit'? Note that 'object-fit' is available in Firefox 36.[1][2]

[1] https://developer.mozilla.org/en-US/docs/Web/CSS/object-fit
[2] Bug 1099450
Comment 61 info 2015-02-23 11:12:32 PST
(In reply to Sebastian Zartner [:sebo] from comment #60)
> (In reply to info from comment #59)

> Implement what? 'getMatchedCSSRules' or 'object-fit'? Note that 'object-fit'
> is available in Firefox 36.[1][2]
> 
> [1] https://developer.mozilla.org/en-US/docs/Web/CSS/object-fit
> [2] Bug 1099450

Nah, I meant implementing 'getMatchedCSSRules' would be helpful for any CSS polyfills that need to parse correlated rules. I’m aware of the implementation of object-fit in v36.
Comment 62 Anne (:annevk) 2015-02-23 11:17:31 PST
https://wiki.css-houdini.org/ has a completely different direction for enabling polyfills so I don't think we should let that influence us too much here.
Comment 63 info 2015-02-23 11:26:34 PST
(In reply to Anne (:annevk) from comment #62)
> https://wiki.css-houdini.org/ has a completely different direction for
> enabling polyfills so I don't think we should let that influence us too much
> here.

Yeah, I’m totally aware that Tab is doing something to make polyfilling CSS better. Still, today we don’t have another option than using the getMatchedRules for some specific use cases and as far as I can see. I also played around with the existing codebase from Remy and Tab but they’re relatively heavy and not yet production-ready.

But anyway, I just added a use-case as people asked for some in this thread.
Comment 64 Boris Zbarsky [:bz] (still a bit busy) 2015-02-23 11:32:58 PST
Looking at that use case, the getMatchedCSSRules is used for getMatchedStyle, which is actually trying to just find the specified values of the styles on an element, right?

That seems like a use case for having a way to get the specified styles (which is in fact something people have asked for a lot), with getMatchedCSSRules being used as a hacky workaround, afaict.
Comment 65 info 2015-02-23 11:41:46 PST
(In reply to Boris Zbarsky [:bz] from comment #64)
> Looking at that use case, the getMatchedCSSRules is used for
> getMatchedStyle, which is actually trying to just find the specified values
> of the styles on an element, right?
> 
> That seems like a use case for having a way to get the specified styles
> (which is in fact something people have asked for a lot), with
> getMatchedCSSRules being used as a hacky workaround, afaict.

Yep, exactly. From that point of view any other tool that provides me these styles is possible, too. It’s just that there isn’t any at the moment.
Comment 67 David Baron :dbaron: ⌚️UTC-10 2015-02-24 00:06:48 PST
Neither getMatchedCSSRules nor getCascadedStyle would provide values or properties that we don't implement, so I don't see how they'd help with polyfills (which I think should have a better API that is more designed for extending support).
Comment 68 info 2015-02-24 00:14:23 PST
(In reply to David Baron [:dbaron] (UTC+13) (vacation, returning March 2) from comment #67)
> Neither getMatchedCSSRules nor getCascadedStyle would provide values or
> properties that we don't implement, so I don't see how they'd help with
> polyfills (which I think should have a better API that is more designed for
> extending support).

Of course. But this is not what I’m talking about. I’ve shared a use case which *is* a polyfill and *makes use of* getMatchedCSSRules to read them out and re-apply them to another element. This follows the principle of a polyfill: To emulate the native behavior of a not yet implemented though standardized functionality.

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