See bug 1035091 comment 110 through bug 1035091 comment 114. Having an API for this would make a lot of sense.

In terms of how to expose it, there are a few options: 1) We could add an extensions-only static thing on the CSS interface that takes a string and returns a sequence<CSSRule> or a CSSStyleSheet. 2) We could make CSSStyleSheet constructible with a string arg from extensions. This would be a little more complicated but might end up being something that happens on the web eventually anyway. Or it might not....

There are some open questions about what things should or should not be parseable in this context, of course....

We have the ReparseStyleSheet stuff already for devtools, I think we can reuse most of it for this... I could take a look at this when I'm not buried in other stuff, I guess... If someone wants to steal it from me that'd be nice too.

I think extensions-only things should be under the `browser` namespace instead of adding a member or a constructor to global interfaces such as CSS or CSSStyleSheet.

OK, so there are two separate questions: 1) What is the API exposed to extensions? 2) How is that implemented? In that we could have a browser.something that gets implemented via ChromeOnly things on CSS.

We've got a pretty lightweight process for asking the WebExtensions team about new APIs, so I've added this to that process. If this is a lot of code and you feel a WebExtension peer might not be keen on landing this, it might good to wait for that process to complete before writing too much code. https://wiki.mozilla.org/Add-ons/Contribute/Triage https://wiki.mozilla.org/WebExtensions/NewAPIs

I'll clear the ni? for now. I don't think implementing it is particularly complex, so whenever someone decides on this API, I can implement it.

Hi Boris, this has been added to the agenda for the December 19, 2017 WebExtensions APIs triage. Would you be able to join us? Here’s a quick overview of what to expect at the triage: * We normally spend 5 minutes per bug * The more information in the bug, the better * The goal of the triage is to give a general thumbs up or thumbs down on a proposal; we won't be going deep into implementation details Relevant Links: * Wiki for the meeting: https://wiki.mozilla.org/WebExtensions/Triage#Next_Meeting * Meeting agenda: https://docs.google.com/document/d/1KwfTum8Ow5w4afPAOvShpu_d_MNtahhOIqL3-Em9lLc/edit# * Vision doc for WebExtensions: https://wiki.mozilla.org/WebExtensions/Vision

I think browser.something (implemented as suggested in comment 5) makes the most sense if we want this API to be exposed to content scripts since content scripts share the window object with the page in which they are injected. I'm assuming that makes exposing something as a property on CSS impractical, but would be happy to be corrected. Boris, can you spell out the questions from comment 2?

> Would you be able to join us? I don't know yet. I will be traveling for part of Dec 19, so whether I can join at that time depends on the traffic. I can try to join if I'm not in a car at the time. :) > since content scripts share the window object with the page in which they are injected. They do, but they see it via Xrays, so we can do different exposure for them and for the page. > I'm assuming that makes exposing something as a property on CSS impractical Not at all. For example, we expose a bunch of properties on HTMLMediaElement to addon content scripts (and in fact only content scripts for addons that have debugger or tab privileges) but not webpages. I have no personal opinion on whether the api should be browser.something or reached via some other access point. We should probably put it wherever addon authors are most likely to look for it. > Boris, can you spell out the questions from comment 2? Well, for question 1... Is input a Unicode string or a byte sequence (probably the former?)?. Is output a CSSStyleSheet, or an array of rules, or are both possibilities? Do you have to parse full rules (or lists of rules), or can you pass pairs of (property name, property value) somehow? If the latter, what is returned? Is there a way to parse just selectors? If so, what does it return? Plus of course the question of what the actual integration point or points are (CSS.something, browser.something, something else). For question 2, it partly depends on the integration points and the API we decide to expose. The obvious options are to call into Gecko and use its CSS parser, to use the JS fork of the Gecko CSS tokenizer that devtools have, or to reimplement some amount of CSS parsing in JS. Using the Gecko parser is obviously easier if we have the API return objects that the Gecko parser already knows how to create.

Hi Boris, we weren't quite able to get to this bug on the 9th and it has been added to the agenda for the upcoming triage meeting on January 9, 2018. You are invited to join us! Here's a link to the agenda: https://docs.google.com/document/d/15JYw3L1490dKbr6yTLz1uirH8rfhcSiLJCubSWDlnfs/edit#

(In reply to Boris Zbarsky [:bz] (no decent commit message means r-) from comment #10) > > since content scripts share the window object with the page in which they are injected. > > They do, but they see it via Xrays, so we can do different exposure for them > and for the page. This seems to be the primary issue. Otherwise, I'm not clear what the benefit of a new API here is. What's the use case? Can teh xray issue be resolved without a new api? Otherwise, sidebar/page/browser actions (and I'm guessing the background page) should be able to just use existing webapis.

> Otherwise, I'm not clear what the benefit of a new API here is. I don't follow. The benefit of a new API is to allow extensions to parse CSS that web pages cannot parse, no? > What's the use case? Did you read the links in comment 0? > Can teh xray issue be resolved without a new api? What do you mean by "the xray issue"? > should be able to just use existing webapis. The whole point is, existing webapis don't allow parsing the bits that people want to parse.