Bug 222231 – Be more deliberate with what is required for CSS parsing

• Status: NEW
• Component: CSS

[Sam Weinig]

Currently, a lot of CSS related parsing is pretty adhoc with regard to what context is required to parse CSS (and CSS-ish), with some parsing functions requiring CSSParserContexts, some not, and some passing in CSSParserContexts that don't contain the correct information (e.g. any that doesn't construct their CSSParserContext with a document are not getting correct Settings values).

With more CSS parsing being needed in workers for OffscreenCanvas and various worklets, I think we should take a moment to clean this up and be as deliberate and clear as we can with the interfaces we expose for this.

Specifically, I think we should require a fully initialized CSSParserContext for all parsing, and remove the default values that currently allow some parsing to get away with what is essentially a dummy one. 

Since a fully initialized CSSParserContext currently requires a Document, the first step might be to enumerate the cases where CSS parsing is needed and a Document and Page (needed for useSystemAppearance(), though perhaps we should move this somewhere else) is not available and figure out the appropriate ways to get the information in those cases.

Enumerating these right now is kinda tricky, due to default initialization of CSSParserContext to a dummy one in many cases, so I think a first pass here would be remove the existing constructor not taking a document, and add new ones that require passing in a new enum that we can create that that will have values for all the reasons. e.g. 

enum class CSSParsingReason {
    Inspector,
    UserAgentStyleSheet,
    StyleRuleWithoutAPointerToADocument,
    etc...
};

And also switch CSSParser away from using static functions to require bottlenecking through the

[Antti Koivisto]

Good idea

[Radar WebKit Bug Importer]

<rdar://problem/74828679>