Intent to Deprecate: getMatchedCSSRules()

[Philip Jägenstedt]

Primary eng (and PM) emails

phi...@opera.com

Summary

Deprecate getMatchedCSSRules().

Motivation

It's WebKit-only.

There's an open WebKit bug to remove it with interesting comments:

https://bugs.webkit.org/show_bug.cgi?id=79653

There's also a Mozilla bug that didn't go anywhere:

https://bugzilla.mozilla.org/show_bug.cgi?id=438278

No spec.

Compatibility Risk

This API was introduced in WebKit in 2005:

http://trac.webkit.org/changeset/11233

"Add support for getMatchedCSSRules, an API that can be used to inspect the set of rules that match on an element. From Obj-C you see all rules (user agent, author, user).  From JS you just see author rules."

Removing the API will cause exceptions to be thrown where it's used unconditionally.

Alternative implementation suggestion for web developers

http://stackoverflow.com/questions/2952667/find-all-css-rules-that-apply-to-an-element

While I haven't tried it, this looks promising:

http://www.brothercake.com/site/resources/scripts/cssutilities/

More generally, do whatever you do to support non-WebKit browsers.

Usage information from UseCounter

https://www.chromestatus.com/metrics/feature/timeline/popularity/155

In July, usage came down from ~0.5% and is currently ~0.01%.

Entry on chromestatus.com, crbug.com, or MDN

https://code.google.com/p/chromium/issues/detail?id=437569

Requesting approval to remove too?

No. Usage isn't zero and maybe the deprecation message will shake out some developer feedback on why they need the API.

[PhistucK]

My guess is that most of the usage comes from developer tools. It would be a nice one to remove. :)

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[TAMURA, Kent]

Deprecation LGTM.

--

TAMURA Kent
Software Engineer, Google

[John Mellor]

It seems that getMatchedCSSRules could have be useful for polyfilling new CSS properties and values. However:

1. I suspect unrecognized properties and values aren't included when you access a rule's cssText, in which case this is less useful (I guess you'd have to find inert properties that take strings as values, and parse the strings, to see what property you're meant to be polyfilling).

2. Tab says the way forward is custom CSS properties (namespaced with leading dashes). So we should probably focus on implementing those rather than putting effort into standardizing getMatchedCSSRules.

[Philip Jägenstedt]

Right, here's a test showing that CSSStyleDeclaration doesn't retain unknown properties:

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3328

Philip

[Timothy Loh]

Non-OWNER lgtm to deprecate.

[Chris Harrelson]

LGTM

[jma...@google.com]

FWIW, we on the Google Web Designer team use this API heavily to get CSS rules in our HTML authoring environment. Though it is not perfect and has lots of limitations it does enable a ton of functionality for us. We are looking into ways to eliminate it's use, such as by using the dev tools protocol directly but that will take some time.

Our usage is through Chromium Embedded so I'm wondering if it would show up in the usage numbers you are seeing.

Regardless, I agree that deprecation is necessary but was wondering if there is a way to keep it for those who need it until they can transition to alternative approaches. The need for this would depend on when it is actually slated to be removed.

[PhistucK]

You can just keep using it while it is deprecated, but you need to transition to alternative approaches immediately.

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Philip Jägenstedt]

There is no set date for removal, at the earliest a few months from
now I think. Do you have a good idea of how to migrate the code, and
would removal in a few months be too soon for you to adapt?

[John Mayhew]

It is more of a scheduling issue for us as we need to drop feature work to do this. The estimate I heard thrown around within the group is 3 mos. but we need to asses that now that we know it is coming up next year. We did start some investigations on using the devtools protocol and it looked promising. Our dev on this is out this week. I'll get with him when he is back and provide and update on our timeframes.

--

John Mayhew |

Software Engineer |

jma...@google.com |

415-225-9265

[Philip Jägenstedt]

Let's revisit when the time comes to remove this. There's no big rush, and we could keep it behind a runtime-enabled flag for a while longer to buy you some extra time. It would be nice to hear what you learn from investigating this issue, in particular if you find that something is possible only with this API, in which case maybe the Web platform is missing something...

Philip

[seba...@adblockplus.org]

Hi,

we'd like to use getMatchedCSSRules() in Adblock Plus, to implement element hiding filters based on applied CSS properties. I suppose when we (and possibly other adblockers) start using it, it would affect significantly more than 0.5% of the users. The alternative approach, going through all stylesheets on the page and going then through all elements, matching them against the found rules, wouldn't be realistic for us mostly because performance issues. So any chance to revert the decision to remove that function?

Sebastian

[Philip Jägenstedt]

Hi Sebastian,

Can you describe in some more detail what conditions you're trying to
use for filtering? You say "applied CSS properties", but that's
accessible getComputedStyle()... Are you thinking of hiding stuff
that's styled by a particular stylesheet, using the knowledge that
certain stylesheets are included only to style ads?

How would you do the same thing in Firefox and IE

If there is some use case that makes sense generally, then maybe
something should be standardized. Maybe getMatchedCSSRules() is
exactly the API you need, but I'd like to learn more.

Philip

[seba...@adblockplus.org]

Hi Philip,

On Friday, January 9, 2015 at 4:11:50 PM UTC+1, Philip Jägenstedt wrote:

Can you describe in some more detail what conditions you're trying to
use for filtering? You say "applied CSS properties", but that's
accessible getComputedStyle()

With "applied properties" I mean properties that are applied to a given element, as defined in the stylesheet. We can't rely on getComputedStyle(), because its result varies based on a lot of factors like the browser, browser version, viewport size and font settings. Here is a proof-of-concept, how this could be implemented with getMatchedCSSRules():

http://codereview.adblockplus.org/5450938709966848/patch/5741031244955648/5086100271923200

 

... Are you thinking of hiding stuff
that's styled by a particular stylesheet, using the knowledge that
certain stylesheets are included only to style ads?

We aim to address cases where websites randomize the URLs and markup of their ads. So we can't rely on request blocking and regular element hiding (based on CSS selectors). In order to hide those ads, we need a way to hide elements that were styled with a given combination of CSS properties. Those can't be randomized easily (without a visible effect). 

 

How would you do the same thing in Firefox and IE

On Firefox there is an inspector API (extensions only) that does pretty much the same as getMatchedCSSRules():

https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/inIDOMUtils#getCSSStyleRules()

Also there is an open bug for implementing getMatchedCSSRules() in Firefox:

https://bugzilla.mozilla.org/show_bug.cgi?id=438278

IE is a different story. We haven't looked into how/if this could be implemented there. There isn't probably a way using JavaScript. However, IE extensions use C++ and can manipulate the browser via COM. So there might be a different way. And even if it's not possible at all, it wouldn't be the first limitation we have on IE. ;)

 

If there is some use case that makes sense generally, then maybe
something should be standardized. Maybe getMatchedCSSRules() is
exactly the API you need, but I'd like to learn more.

While getMatchedCSSRules() in combination with TreeWalker and MutationObserver, seems to work good enough for our purpose, an API that lets us select elements by applied properties and listen to new matching elements added would be nicer:

    var nodeList = document.getElementsByCSSProperties({margin: 0; color: "red"})

    nodeList.onadded = function() {}

Or even better, a CSS selector syntax that lets us match elements by applied styles, so all we need to do is injecting a stylesheet:

   

    *:prop(margin: 0):prop(color: "red") {

        display: none;

    }

However, as long as there isn't any better option we have to rely on getMatchedCSSRules() and don't think that it should be deprecated.

Sebastian

[Elliott Sprehn]

On Fri, Jan 9, 2015 at 8:33 AM, <seba...@adblockplus.org> wrote:

Hi Philip,

On Friday, January 9, 2015 at 4:11:50 PM UTC+1, Philip Jägenstedt wrote:

Can you describe in some more detail what conditions you're trying to
use for filtering? You say "applied CSS properties", but that's
accessible getComputedStyle()

...

If there is some use case that makes sense generally, then maybe
something should be standardized. Maybe getMatchedCSSRules() is
exactly the API you need, but I'd like to learn more.

While getMatchedCSSRules() in combination with TreeWalker and MutationObserver, seems to work good enough for our purpose, an API that lets us select elements by applied properties and listen to new matching elements added would be nicer:

    var nodeList = document.getElementsByCSSProperties({margin: 0; color: "red"})

    nodeList.onadded = function() {}

This also is going to be very expensive, we'd have to walk the entire page running all the CSS rules a second time since which rules matched are lost after style recalc.

I'd suggest instead using your own CSS parser and just calling querySelector on the rules you parsed from it. (You could also use CSSOM).

 

Or even better, a CSS selector syntax that lets us match elements by applied styles, so all we need to do is injecting a stylesheet:

   

    *:prop(margin: 0):prop(color: "red") {

        display: none;

    }

This is cyclical, you can't implement it because you don't know what properties match until you run the body. Implementing this would also be very expensive, and in general I think we should stop adding expensive selectors and focus on making the ones we have already fast.

 

- E

[seba...@adblockplus.org]

On Friday, January 9, 2015 at 10:35:07 PM UTC+1, Elliott Sprehn wrote:

On Fri, Jan 9, 2015 at 8:33 AM, <seba...@adblockplus.org> wrote:

While getMatchedCSSRules() in combination with TreeWalker and MutationObserver, seems to work good enough for our purpose, an API that lets us select elements by applied properties and listen to new matching elements added would be nicer:

    var nodeList = document.getElementsByCSSProperties({margin: 0; color: "red"})

    nodeList.onadded = function() {}

This also is going to be very expensive, we'd have to walk the entire page running all the CSS rules a second time since which rules matched are lost after style recalc.

I'd suggest instead using your own CSS parser and just calling querySelector on the rules you parsed from it. (You could also use CSSOM).

I don't see how doing that ourselves with JavaScript on (every DOM change!) is any more efficient than having the browser do it for us.

 

Or even better, a CSS selector syntax that lets us match elements by applied styles, so all we need to do is injecting a stylesheet:

   

    *:prop(margin: 0):prop(color: "red") {

        display: none;

    }

This is cyclical, you can't implement it because you don't know what properties match until you run the body. Implementing this would also be very expensive, and in general I think we should stop adding expensive selectors and focus on making the ones we have already fast.

I don't see how this would be different from the :dir() selector.

Sebastian

[Rob Wu]

[side note] Computed CSS-based adblocking is not practical in my opinion. Not only because of the performance implications (see my inline comments below), but also because it can easily be circumvented. E.g. by randomizing properties of values ("red", "RED", "rgb(255,0,0)", "rgb(254,0,0)", "rgba(255,0,0,1)").

-- Rob (https://robwu.nl)

2015-01-09 22:47 GMT+01:00 <seba...@adblockplus.org>:

On Friday, January 9, 2015 at 10:35:07 PM UTC+1, Elliott Sprehn wrote:

On Fri, Jan 9, 2015 at 8:33 AM, <seba...@adblockplus.org> wrote:

While getMatchedCSSRules() in combination with TreeWalker and MutationObserver, seems to work good enough for our purpose,

A few months ago, I profiled the use of MutationObservers in an extension for matching specific elements-attribute combinations. On huge pages, the load time increased by 25 - 35% (3-8% with perceivable throttling). In a DOM benchmark with the throttled implementation, the (peek) memory usage tripled.

As a popular browser extension vendor, you have to be considerate and not add features that significantly degrade the performance.

 

an API that lets us select elements by applied properties and listen to new matching elements added would be nicer:

    var nodeList = document.getElementsByCSSProperties({margin: 0; color: "red"})

    nodeList.onadded = function() {}

This also is going to be very expensive, we'd have to walk the entire page running all the CSS rules a second time since which rules matched are lost after style recalc.

I'd suggest instead using your own CSS parser and just calling querySelector on the rules you parsed from it. (You could also use CSSOM).

I don't see how doing that ourselves with JavaScript on (every DOM change!) is any more efficient than having the browser do it for us.

Implementing this feature is also expensive for browser engines. Your JS code could outperform the browser if there are assumptions that your code can make. E.g. assumptions like "there is no need to process child nodes if an element is matched".

 

 

Or even better, a CSS selector syntax that lets us match elements by applied styles, so all we need to do is injecting a stylesheet:

   

    *:prop(margin: 0):prop(color: "red") {

        display: none;

    }

This is cyclical, you can't implement it because you don't know what properties match until you run the body. Implementing this would also be very expensive, and in general I think we should stop adding expensive selectors and focus on making the ones we have already fast.

I don't see how this would be different from the :dir() selector.

:dir matches the semantic value (derived from the dir attribute, etc.), not the calculated CSS style.

[seba...@adblockplus.org]

On Saturday, January 10, 2015 at 12:31:42 PM UTC+1, Rob Wu wrote:

[side note] Computed CSS-based adblocking is not practical in my opinion.

I'm not talking about computed styles, but applied CSS properties as further outlined above.

 

but also because it can easily be circumvented. E.g. by randomizing properties of values ("red", "RED", "rgb(255,0,0)", "rgb(254,0,0)", "rgba(255,0,0,1)").

Normalizing colors before matching them would be an option.

 

2015-01-09 22:47 GMT+01:00 <seba...@adblockplus.org>:

On Friday, January 9, 2015 at 10:35:07 PM UTC+1, Elliott Sprehn wrote:

On Fri, Jan 9, 2015 at 8:33 AM, <seba...@adblockplus.org> wrote:

While getMatchedCSSRules() in combination with TreeWalker and MutationObserver, seems to work good enough for our purpose,

A few months ago, I profiled the use of MutationObservers in an extension for matching specific elements-attribute combinations. On huge pages, the load time increased by 25 - 35% (3-8% with perceivable throttling). In a DOM benchmark with the throttled implementation, the (peek) memory usage tripled.

As a popular browser extension vendor, you have to be considerate and not add features that significantly degrade the performance.

We wouldn't do that on all web pages, but only those where this is the only option to hide ads. Those aren't usually huge pages. But even if the overhead becomes noticeable users will rather live with that, than seeing ads there. However, if there is (or will be) a more efficient way, we are happy to pursue it.

 

an API that lets us select elements by applied properties and listen to new matching elements added would be nicer:

    var nodeList = document.getElementsByCSSProperties({margin: 0; color: "red"})

    nodeList.onadded = function() {}

This also is going to be very expensive, we'd have to walk the entire page running all the CSS rules a second time since which rules matched are lost after style recalc.

I'd suggest instead using your own CSS parser and just calling querySelector on the rules you parsed from it. (You could also use CSSOM).

I don't see how doing that ourselves with JavaScript on (every DOM change!) is any more efficient than having the browser do it for us.

Implementing this feature is also expensive for browser engines. Your JS code could outperform the browser if there are assumptions that your code can make. E.g. assumptions like "there is no need to process child nodes if an element is matched".

This particular scenario wouldn't be very common in our case, and isn't probably worth optimizing for. There are some other optimizations that makes sense of course, but they could be implemented in the browser as well.

Sebastian

[Philip Jägenstedt]

On Fri, Jan 9, 2015 at 10:47 PM, <seba...@adblockplus.org> wrote:
> On Friday, January 9, 2015 at 10:35:07 PM UTC+1, Elliott Sprehn wrote:
>>
>> On Fri, Jan 9, 2015 at 8:33 AM, <seba...@adblockplus.org> wrote:
>>>
>>> While getMatchedCSSRules() in combination with TreeWalker and
>>> MutationObserver, seems to work good enough for our purpose, an API that
>>> lets us select elements by applied properties and listen to new matching
>>> elements added would be nicer:
>>>
>>> var nodeList = document.getElementsByCSSProperties({margin: 0; color:
>>> "red"})
>>> nodeList.onadded = function() {}
>>
>>
>> This also is going to be very expensive, we'd have to walk the entire page
>> running all the CSS rules a second time since which rules matched are lost
>> after style recalc.
>>
>> I'd suggest instead using your own CSS parser and just calling
>> querySelector on the rules you parsed from it. (You could also use CSSOM).
>
>
> I don't see how doing that ourselves with JavaScript on (every DOM change!)
> is any more efficient than having the browser do it for us.

If you're looking for something good enough, couldn't you use CSSOM to
rewrite the rules that are supposed to style the ads to instead hide
them?

getMatchedCSSRules() is on the track for deprecation in M41, so I
really hope that you do not start to depend on it without making sure
that it is on the path for standardization with some support from
other browser vendors.

Philip

[jma...@google.com]

John from the Web Designer team here. We are still trying to figure out a plan to switch away from getMatchedCSSRules() and are trying to schedule it in to our work this quarter. Keeping it behind a flag would be great as it could buy us some more time. My concern then would be that it would basically be unsupported and if other blink dev work were to break this function, the priority on fixing it would be extremely low. So a break is just as bad as having it removed. Is that concern valid?

John

[Elliott Sprehn]

getMatchedCSSRules() is very slow internally, I'd suggest not using it. I don't think we should put it behind a flag, that just delays the work for people to migrate away from it.

[John Mayhew]

Okay, we (the Web Designer team) have a change we are currently working on to remove our dependence on getMatchedCSSRules(). This work should be completed in the next 4-6 weeks which I assume is well ahead of the methods full removal.

[Philip Jägenstedt]

Thanks for the update John, that sounds promising. If removed right now, that would reach the stable channel in ~12 weeks, so you should be OK. But I think waiting until after the next branch point would be good to give it two release cycles of deprecation, which would add ~6 weeks to that.

Philip

[mirikl...@gmail.com]

Please, please fix the returning null issue instead of deprecating it... As a user of webkit, this is what I'm truly thinking. I'm writing something that analyzes web pages, and it really needs to know what styles are currently active on an element.

[ento...@gmail.com]

Does anyone know if this is still intended to be fully deprecated?

It's useful (the only not-insane way to figure out what styles come from CSS files rather than computed (e.g. height)) and I plan on using it going forward.

[PhistucK]

I would not use it if I were you.

If I remember correctly, Edge implemented it as a no-op (returning null or an empty object or similar). I would guess that if it is not outright removed from Blink, it would return the same as Edge.

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

[Elliott Sprehn]

Philip can we remove this now? :) It seems to be about 0.02% and adds a bunch of complexity.

[Philip Jägenstedt]

We need to take some kind of action for sure, just leaving it deprecated (my fault) isn't any good.

I've taken a look at what Edge does, and from what I can tell their getMatchedCSSRules always returns null, but as a non-optional argument which can be anything.

I queried 2016_06_15 desktop and android httparchive data sets for 'getMatchedCSSRules':

https://docs.google.com/spreadsheets/d/13mGPt_6cFzdf8VXMDV5X8nJeURIuUKtL4zq_hNtq7Cc/edit?usp=sharing

https://docs.google.com/spreadsheets/d/103zriuBmp_DE4ljdwaXUBc5MjedA9WFmei-VVzHgsbY/edit?usp=sharing

The results are dominated by scripts from blogger.com and evernote.com. Both look like they could end up calling getMatchedCSSRules. I looked at a few random other sites, and at least some do feature detection with a fallback, which might work better if getMatchedCSSRules is dropped than if it's made to always return null.

In order to remove, I think the following is needed:

• Talk to the Edge team to learn about what compat caused them to add a null-returning getMatchedCSSRules.
• Investigate a random subset of the matched from httparchive to get an idea about the kind of breakage to expect.
• Reach out to the developers of the sites/libraries that show up most often.

This is a bit of work. Elliott, are interested in driving this?

Philip

[Michael Cook]

Not to be rude at all, but what is the fallback you mentioned?

I can't find anything even close, and no amount of parsing getComputedStyle achieves the same results (believe me I've tried), e.g. CSS file source, given rules instead of computed, etc.

Myke

--
You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/fd-QLCiLESQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blink-dev+...@chromium.org.

[Philip Jägenstedt]

I don't mean that the fallback is actually any good, only that it's sometimes there and might be better than nothing.

For example, http://static.evernote.com/noteit.js has this structure:

... } else if (typeof view.getMatchedCSSRules == 'function') {
      style = new Evernote.ClipStyle(view.getMatchedCSSRules(node), filter);
    } else {
      try {
        if (typeof CSSStyleDeclaration != 'undefined'
            && node.style instanceof CSSStyleDeclaration
            && node.style.length > 0) {
          style = new Evernote.ClipStyle(node.style, filter);
        }
      } catch (e) {}
    }

If getMatchedCSSRules is removed entirely, then at least sometimes style would become non-null in the fallback path, whereas letting getMatchedCSSRules always return null would make style always null here. This matters in determining whether full removal or leaving a null-returning dummy is the safer option. More detailed analysis of the common cases would be needed.

I believe what you are asking, and which we need to have a good answer for, is how existing uses of getMatchedCSSRules should be replaced if it's finally removed. Can you share the code that depends on getMatchedCSSRules?

[PhistucK]

Perhaps having the "best" of both of the worlds makes sense here - apply the same trick that document.all uses (typeof document.all !== "undefined" // false, even though it exists).

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

[22mmorfo...@lakeplacidcsd.net]

[iho...@gmail.com]

I guess getMatchedCSSRules is useful for PageSpeed Insights optimization. You can grab all css rules for page top part using this function. Am I wrong ? 

[Philip Jägenstedt]

Do you mean that https://developers.google.com/speed/pagespeed/insights/ uses getMatchesCSSRules, or that you're using getMatchesCSSRules to improve on things that PageSpeed Insights suggests?

[plummer...@gmail.com]

I understand that getMatchedCSSRules is Webkit only and for general consumption deprecation makes sense, however it provides functionality that is extremely useful for developer tools (extensions) and at the moment there is no good alternative. Removing this feature effectively locks away declared user styles leaving only computed styles accessible. Can this not be moved somewhere appropriate to extensions so that these values are not hidden away forever?

[Rick Byers]

It's an interesting idea.  I filed this feature request do discuss it further with the extension API owners. 

On Sat, Oct 28, 2017 at 5:51 AM, <plummer...@gmail.com> wrote:

I understand that getMatchedCSSRules is Webkit only and for general consumption deprecation makes sense, however it provides functionality that is extremely useful for developer tools (extensions) and at the moment there is no good alternative. Removing this feature effectively locks away declared user styles leaving only computed styles accessible. Can this not be moved somewhere appropriate to extensions so that these values are not hidden away forever?

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e751fe36-0edc-4e38-ae73-cfe477c9a082%40chromium.org.

[co...@moock.org]

I'm aware that getMatchedCSSRules() has been removed already, and is not likely coming back, but for the historical record: as many others have observed, it's a shame getMatchedCSSRules() was never standardized, and was removed from Chromium. As others have pointed out, the stackoverflow alternative is comparatively slow and will be inaccurate in some edge cases due to its reliance on regex. For me, these cases where JavaScript application code cannot perfectly duplicate the native implementation are precisely the situations where native APIs make sense. In our use case, we need to retrieve the CSS-specified value of line-height, which cannot be extrapolated by other means. For example, a CSS declaration's line-height might be 1.6. The getComputedStyle() lineHeight, however, gives a derived value in pixels. Our application needs access to the original line-height for the purposes of text measurement for automatic font sizing. Any case where getComputedStyle() does not match the CSS-declared value is a case where the developer is forced to settle for an imperfect workaround.

[Emilio Cobos Álvarez]

Disclaimer: I don't have anything against getMatchedCSSRules() on my
own, and I think it may be a useful primitive. It allows you to observe
and poke inside shadow trees and such which may be problematic or not,
etc etc...

But to be clear it doesn't work for what you want. What you want is the
_computed_ value of line-height, which is not what getComputedStyle()
returns, for legacy reasons, see [1].

getMatchedCSSRules() allows you to get the first rule that specified
line-height, but if that has something like `var(--my-line-height)`,
then you need to do the cascade yourself to figure out what the right
computed value is.

In any case, I recommend you to file an issue against the csswg-drafts
repo[2] to be able to expose what you want sanely.

However it's unclear how the computed value helps you either, for the
case where it's `normal` and not a number.

-- Emilio

[1]: https://drafts.csswg.org/cssom/#resolved-values
[2]: https://github.com/w3c/csswg-drafts/issues/new

On 11/9/19 6:23 PM, co...@moock.org wrote:
> I'm aware that getMatchedCSSRules() has been removed already, and is not
> likely coming back, but for the historical record: as many others have
> observed, it's a shame getMatchedCSSRules() was never standardized, and
> was removed from Chromium. As others have pointed out, the stackoverflow
> alternative is comparatively slow and will be inaccurate in some edge
> cases due to its reliance on regex. For me, these cases where JavaScript
> application code cannot perfectly duplicate the native implementation
> are precisely the situations where native APIs make sense. In our use
> case, we need to retrieve the CSS-specified value of line-height, which
> cannot be extrapolated by other means. For example, a CSS declaration's
> line-height might be 1.6. The getComputedStyle() lineHeight, however,
> gives a derived value in pixels. Our application needs access to the
> original line-height for the purposes of text measurement for automatic
> font sizing. Any case where getComputedStyle() does not match the
> CSS-declared value is a case where the developer is forced to settle for
> an imperfect workaround.
>
>
>
> On Friday, November 28, 2014 at 6:00:10 PM UTC-5, Philip Jägenstedt wrote:
>
> Primary eng (and PM) emails
>

> phi...@opera.com <javascript:>

> <https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/page/UseCounter.h&sq=package:chromium&type=cs&q=file:UseCounter.h%20Feature&l=39>
>
> https://www.chromestatus.com/metrics/feature/timeline/popularity/155

> <https://www.chromestatus.com/metrics/feature/timeline/popularity/155>
>
>
> In July, usage came down from ~0.5% and is currently ~0.01%.
>
>

> Entry on chromestatus.com <http://chromestatus.com>, crbug.com
> <http://crbug.com>, or MDN
>
> https://code.google.com/p/chromium/issues/detail?id=437569

> <https://code.google.com/p/chromium/issues/detail?id=437569>
>
>
> Requesting approval to remove too?
>
> No. Usage isn't zero and maybe the deprecation message will shake
> out some developer feedback on why they need the API.
>

> --
> You received this message because you are subscribed to the Google
> Groups "blink-dev" group.

> To unsubscribe from this group and stop receiving emails from it, send
> an email to blink-dev+...@chromium.org

> <mailto:blink-dev+...@chromium.org>.

> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/99f8117e-8acd-4945-acee-b77a7ac3f8d9%40chromium.org
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/99f8117e-8acd-4945-acee-b77a7ac3f8d9%40chromium.org?utm_medium=email&utm_source=footer>.