| Age | Commit message (Collapse) | Author |
|---|
|
The logic is handled by `CSSGroupingRule` and `CSSConditionRule`, so
`CSSMediaRule` only has to report if its condition matches.
Right now, that condition is always false because we do not evaluate the
media query.
|
|
CSSStyleSheet is no longer the only class that contains a list of rules,
so this will save duplicating the logic in multiple places.
|
|
Websites being able to query whether we support a given CSS feature
should prevent them from loading unnecessary polyfills for things we
already support! Or at least, that's the nice theory. :^)
|
|
... according to
https://www.w3.org/TR/css-conditional-3/#typedef-supports-condition
This works very similarly to `@media`, but is different enough to
require its own parsing. (Though, the draft of Conditional-4 currently
mentions combining the two into a `@when` rule.)
Made some small changes to parsing code to make this work. Notably,
making `consume_a_declaration()` fail gracefully instead of
`VERIFY()`ing.
|
|
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.
:^)
|
|
This version takes a property name and value as separate parameters.
|
|
This is the `CSS` namespace defined in IDL here:
https://www.w3.org/TR/cssom-1/#namespacedef-css , not to be confused
with our `Web::CSS` namespace. Words are hard.
`CSS.escape()` lets you escape identifiers that can then be used to
create a CSS string.
I've also stubbed out the `CSS.supports()` function.
|
|
This matches the class hierarchy of the CSS Geometry Interfaces Module.
|
|
The recursive style update function was written a bit strangely and
would only mark descendants of the style update root as not needing a
style update.
With this patch, all nodes in the subtree now have clean style after a
style update finishes.
|
|
Layout depends on style (and not the other way around), so if the
document has dirty style when we enter update_layout(), make sure we
call update_style() before proceeding with the layout work.
This has the pleasant effect of coalescing some redundant layouts.
|
|
|
|
'static' for a function means that the symbol shall not be made public
for the result of the current compilation unit. This does not make sense
in a header, especially not if it's a large function that is used in
more than one place and not that performance-sensitive.
|
|
Previously: Length (and all nearly all of its inline method
definitions) depended on the definition of class CalculatedStyleValue.
Meanwhile, CalculatedStyleValue (and nearly all of its namespaced
structs) depended on the definition of class Length.
Thus, a compilation unit that (for example) only contains
#include <Userland/Libraries/LibWeb/CSS/Length.h>
would fail to compile.
This patch resolves this issue by pushing the inline definition of
various Web::CSS::Length methods into a different file.
|
|
Previously: CSSImportRule::loaded_style_sheet() (and others) depend on
the definition of class CSSStyleSheet. Meanwhile,
CSSStyleSheet::template for_each_effective_style_rule (and others)
depend on the definition of class CSSImportRule.
This hasn't caused any problems so far because CSSStyleSheet.h happened
to be always included after CSSImportRule.h (in part due to alphabetical
ordering).
However, a compilation unit that (for example) only contains
#include <Userland/Libraries/LibWeb/CSSImportRule.h>
would fail to compile.
This patch resolves this issue by pushing the inline definition of
Web::CSS::CSSStyleSheet::for_each_effective_style_rule and
for_first_not_loaded_import_rule into a different file, and adding the
missing headers.
|
|
Per the spec, only a BlockContainer" can have line boxes, so let's not
clutter up every Layout::Box with line boxes.
This also allows us to establish an invariant that BFC and IFC always
operate on a Layout::BlockContainer.
Note that if BlockContainer has all block-level children, its line boxes
are not used for anything. They are only used in the all inline-level
children scenario.
|
|
List item markers will never have children, so let's mark them as such,
which now allows our layout system to skip over their "insides" and
going straight to positioning instead.
|
|
Some boxes cannot have children (most commonly replaced elements),
and so there is nothing meaningful inside them to layout.
We now use the can_have_children() flag to quickly skip over such boxes
instead of creating a formatting context and other pointless busywork.
|
|
|
|
|
|
There's a subtle difference here. A "block box" in the spec is a
block-level box, while a "block container" is a box whose children are
either all inline-level boxes in an IFC, or all block-level boxes
participating in a BFC.
Notably, an "inline-block" box is a "block container" but not a "block
box" since it is itself inline-level.
|
|
The CSS spec uses the name "block formatting context root" when talking
about a box that establishes a BFC. So let's call it BFC::root() in our
code as well, instead of the less specific BFC::context_box().
|
|
|
|
Until now, we've internally thought of the CSS "display" property as a
single-value property. In practice, "display" is a much more complex
property that comes in a number of configurations.
The most interesting one is the two-part format that describes the
outside and inside behavior of a box. Switching our own internal
representation towards this model will allow for much cleaner
abstractions around layout and the various formatting contexts.
Note that we don't *parse* two-part "display" yet, this is only about
changing the internal representation of the property.
Spec: https://drafts.csswg.org/css-display
|
|
|
|
Instead of doing layout synchronously whenever something changes,
we now use a basic event loop timer to defer and coalesce relayouts.
If you did something that requires a relayout of the page, make sure
to call Document::set_needs_layout() and it will get coalesced with all
the other layout updates.
There's lots of room for improvement here, but this already makes many
web pages significantly snappier. :^)
Also, note that this exposes a number of layout bugs where we have been
relying on multiple relayouts to calculate the correct dimensions for
things. Now that we only do a single layout in many cases, these kind of
problems are much more noticeable. That should also make them easier to
figure out and fix. :^)
|
|
The HTML event loop does a check for MQL match-state changes and
dispatches the events. This requires us to keep a list of MQLs on the
Document.
|
|
Currently, `evaluate()` recalculates whether the MediaQuery matches or
not, and stores it in `m_matches`, which users can query using
`matches()`. This allows us to know when the match-state changes, which
is required to fire MediaQueryList's change event.
|
|
In cases where we know the Length is absolute, we know we don't need to
pass in a Layout::Node or FontMetrics etc, and yet we were required to
before. Splitting it means jumping through less hoops that we don't have
to. :^)
|
|
This method provides the needed information to evaluate media queries.
Every feature in Media Queries Level 4 is present, either as code or as
a FIXME: https://www.w3.org/TR/mediaqueries-4/#media-descriptor-table
There's a draft Level 5 which I have ignored for now.
Some are unimplemented for now since we do not have access to the
requested information. Some require StyleValue types that we do not yet
support. Many are hard-coded for now since we do not (and may never)
support monochrome or text-only displays for Browser.
|
|
To avoid duplicating a lot of functionality, we're using StyleValues for
the values of media-features. So, we need their identifiers added here.
|
|
|
|
The only one I didn't implement is `border` itself, because there isn't
an obvious sensible value for it if the borders are different.
|
|
|
|
Of course, we don't actually *use* the box-sizing property yet, but the
value is applied and shows up in the computed style.
|
|
If the specified value for these properties is "none", we end up storing
it as an "undefined" CSS::Length in the computed values.
We need to convert it back into "none" for getComputedStyle().
|
|
The location IDL interface includes a stringifier on the href
attribute i.e. the object's toString should return the value of the
href attribute.
|
|
|
|
We don't want to wrap the inline-blocks the same way we want to wrap
pure inline children.
|
|
A flex-child that was display:inline-block but also had no text inside
of it was previously skipped.
|
|
Auto margins are still not supported at all, but this is a good start
into supporting margins on flex items.
The way cross-before (top for row, left for column) is handled is very
naive.
|
|
Previously, if the parent of the container had a definite main size, it
would've been disregarded when calculating the main size of the
container if it had no definite size and neither min- nor max-main-size
constraints.
This patch fixes that behavior by additionally checking whether the main
size is not only not constrained but also infinite.
|
|
This was incorrectly calling DOM::Window::clear_timeout(). In practice,
these functions are interchangeable, but let's have things looking
correct regardless.
|
|
Instead of passing a function it is also possible to pass a string,
which is then evaluated as a classic script.
|
|
Instead of passing a function it is also possible to pass a string,
which is then evaluated as a classic script.
This means we now support the following example from the "timer
initialization steps", step 16 - except that it runs the timers in
reverse order, so the `log` result is `"TWO ONE "`.
https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#timer-initialisation-steps
var log = '';
function logger(s) { log += s + ' '; }
setTimeout({ toString: function () {
setTimeout("logger('ONE')", 100);
return "logger('TWO')";
} }, 100);
|
|
|
|
|
|
Until we have CORS preflight checks working, this is only getting in the
way of testing and I have to disable it manually all the time.
|
|
This is not entirely to spec, but gets the basic job done.
|
|
|
|
This matches the spec ("3. Otherwise, ...")
|
