Hi Eddy, did the stats that you collected for getMatchedCSSRules usage include anything on extensions?

Unfortunately not - HTTPArchive only looks at archived web pages.

I believe the reason we wanted to remove getMatchedCSSRules in the first place was it a) adds complexity (We don't store enough information do get the result without a lot of work, but keeping it around means more memory usage for a rare feature), so b) it's really slow (n^2 by number of rules)

shend, I vaguely remember you had a previous conversation with devlin about extensions-only getMatchedCSSRules - what was the outcome of that?

Sorry, hit post too early - for point 1: ... and we don't get the benefit of deprecate + remove we were originally going for if we keep it around for extensions.

Yes, I did talk with Devlin about an extension-only API and he basically said what you said in #c3 (complexity and efficiency). Also, my understanding is that it doesn't belong naturally to any of the existing extension APIs.

Yeah, when we chatted, there were the same concerns around whether removing it for web pages but keeping it around for extension usage would yield much value (beyond removing a non-standardized exposed method).  Additionally, both Elliot Sprehn and Rob Wu raised concerns about the performance of the current API, and suggested that having authors implement their own in JS could be more efficient (especially if it can be tailored to the uses of the extension).  Given these, I'm not sure it's worth keeping it around, exposed specifically to extensions.  But I'm open to discussing further.

rbyers@, given the discussion above, is this still something we want to discuss?

It's your call.  It sounds like both Extensions and Style leads agree that this is not a capability they want to expose to extensions.  So this is 'WontFix' for now.

Developers/users impacted by this decision should 'star' this bug and we can revisit the star count at some point to see if the demand is high enough to warrant reconsidering.