This spec is very early on, and likely to change. However, it still
feels preferable to use these rather than the prefixed -webkit ones.
Plus, as we have a `::fill` on range inputs, we can use that for styling
the bar instead of inserting CSS from C++.
This removes a couple of places where we were constructing strings or
vectors just to transfer data over IPC. And passes some values by const&
to remove clangd noise.
This was completely unnecessary, and we can just let the internal
DOM tree changes trigger partial layout updates instead.
Noticed we were repeatedly dropping layout trees on ChatGPT and this
was one of the culprits.
This change implements the requirements for the “suffering from an
overflow” and “suffering from an underflow” algorithms for
HTMLInputElement constraint validation.
This change fixes a bug in our implementation of the “step base”
algorithm at https://html.spec.whatwg.org/#concept-input-min-zero. We
were using the “value” IDL/DOM attribute in a particular step, where the
spec instead actually requires using the “value” content attribute.
This change implements HTMLInputElement type=email constraint validation
in conformance with the current spec requirements (which happens to also
produce behavior that’s interoperable with other existing engines).
This change implements HTMLInputElement type=url constraint validation
in such a way as to match the behavior in other existing engines (which
is, however, very different from what the spec currently requires).
This change — part of the HTML constraint-validation API (aka
“client-side form validation”) — implements the willValidate IDL/DOM
attribute/property for all form controls that support it.
This reduces the number of `.cpp` files that need to be recompiled when
one of the below header files changes as follows:
CSS/ComputedProperties.h: 1113 -> 49
CSS/ComputedValues.h: 1120 -> 209
One point to note is that I am not entirely sure what the result
of the pre-existing valueAsNumber test should be for this strange
case which does not lie exactly on a week/day boundary. Chrome
gives a negative timestamp, which seems more wrong than the result
we give, and neither gecko or WebKit appear to support the 'week'
type. So I'm considering this result acceptable for now, and this
may be something that will need more WPT tests added in the future.
While keyword_to_foo() does return Optional<Foo>, in practice the
invalid keywords get rejected at parse-time, so we don't have to worry
about them here. This simplifies the user code quite a bit.
This matches the behavior of other browsers, which always set the dirty
checkedness flag when setting checkedness, except when setting the
`checked` content attribute.
Many times, attribute mutation doesn't necessitate a full style
invalidation on the element. However, the conditions are pretty
elaborate, so this first version has a lot of false positives.
We only need to invalidate style when any of these things apply:
1. The change may affect the match state of a selector somewhere.
2. The change may affect presentational hints applied to the element.
For (1) in this first version, we have a fixed list of attribute names
that may affect selectors. We also collect all names referenced by
attribute selectors anywhere in the document.
For (2), we add a new Element::is_presentational_hint() virtual that
tells us whether a given attribute name is a presentational hint.
This drastically reduces style work on many websites. As an example,
https://cnn.com/ is once again browseable.
