Commit graph

7 commits

Author SHA1 Message Date
Callum Law
05c336ea4e LibWeb: Use document's viewport when resolving lengths in media queries
Previously we would always use the window's viewport which was incorrect
if we were within an iframe.

This is likely applicable to all uses of
`Length::ResolutionContext::for_window`.
2025-10-07 10:32:59 +01:00
Tim Ledbetter
5d57723ebf LibWeb: Implement CSSImportRule.supportsText
Returns the supports condition specified by the given import at-rule.
2025-03-19 16:42:51 +01:00
Sam Atkins
b6fb4baeb7 LibWeb/CSS: Implement @supports font-format() and font-tech()
These let authors query whether we support font formats and features.
2025-03-17 10:00:19 +00:00
Sam Atkins
0f5e054f97 LibWeb: Implement generic boolean logic for media/supports queries
CSS Values 5 now defines a `<boolean-expr[]>` type that is used in place
of the bespoke grammar that previously existed for `@media` and
`@supports` queries. This commit implements some BooleanExpression
types to represent the nodes in a `<boolean-expr[]>`, and reimplements
`@media` and `@supports` queries using this.

The one part of this implementation I'm not convinced on is that the
`evaluate()` methods take a `HTML::Window*`. This is a compromise
because `@media` requires a Window, and `@supports` does not require
anything at all. As more users of `<boolean-expr[]>` get implemented in
the future, it will become clear if this is sufficient, or if we need
to do something smarter.

As a bonus, this actually improves our serialization of media queries!
2025-03-17 10:00:19 +00:00
Sam Atkins
84a695c958 LibWeb/CSS: Evaluate Supports query components during parsing
Instead of parsing the parts of a `@supports` query, then only
evaluating them when constructing the Supports itself, we can instead
evaluate them as we parse them. This simplifies things as we no longer
need to pass a Realm around, and don't have to re-parse the conditions
again with a new Parser instance.
2025-03-17 10:00:19 +00:00
Sam Atkins
6a4d80b9b6 LibWeb/CSS: Integrate ParsingContext into the Parser
This is not really a context, but more of a set of parameters for
creating a Parser. So, treat it as such: Rename it to ParsingParams,
and store its values and methods directly in the Parser instead of
keeping the ParsingContext around.

This has a nice side-effect of not including DOM/Document.h everywhere
that needs a Parser.
2025-02-06 16:47:25 +00:00
Timothy Flynn
93712b24bf Everywhere: Hoist the Libraries folder to the top-level 2024-11-10 12:50:45 +01:00
Renamed from Userland/Libraries/LibWeb/CSS/Supports.cpp (Browse further)