Each of these strings would previously rely on StringView's char const*
constructor overload, which would call __builtin_strlen on the string.
Since we now have operator ""sv, we can replace these with much simpler
versions. This opens the door to being able to remove
StringView(char const*).
No functional changes.
The goal here is to move the parser-internal classes into this namespace
so they can have more convenient names without causing collisions. The
Parser itself won't collide, and would be more convenient to just
remain `CSS::Parser`, but having a namespace and a class with the same
name makes C++ unhappy.
This is in line with this recent change to Conditional-3:
> Removed the “unknown” value in CSS feature queries’ boolean logic,
> defining unrecognized syntaxes as “false” instead.
> https://github.com/w3c/csswg-drafts/issues/6175
Now that we can serialize CSS tokens, we can just hold a string and then
re-parse it when the Supports is evaluated. This feels a little weird,
but it only happens once so it's not going to slow it down much, and it
keep the API cleaner.
The name is a little awkward, but this corresponds to the condition of a
`@supports` rule or the `CSS.supports("")` function.
A supports query only gets evaluated once, since its condition cannot
change during runtime. (We either support something or we don't, and the
spec specifically mentions that user preferences that disable features
do not affect the result here.) We keep a representation of it around
though, so that it can be serialized if needed. This is a little awkward
since we hold onto a `StyleDeclarationRule` which should be an internal
Parser class. This means making some Parser functions more public.
Potentially we could evaluate the Supports inside the Parser, and have
it only store a String representation of itself. But this works for now.
:^)
