This implements the previously stubbed out `report_validity` method.
The specification is not very clear on how to exactly report the
validity. For now, we bring the first visible invalid control into
view and focus it. In the future, however, it would make sense to
support more complex scenarios and be more aligned with the other
implementations.
Importing these tests now because they are for input-element types that
have requirements related to the constraint-validation API — which we’ve
been implementing recently.
This commit only imports tests, without any changes to our code.
Type changes are now signaled to radio buttons. This causes other radio
buttons in the group to be unchecked if the input element is a checked
radio button after the type change.
This change adds “default step” and “step scale factor” handling for all
remaining HTMLInputElement input types for which the spec defines such
and that we didn’t yet have handling for.
Previously, we would only invalidate style when setting the `media` IDL
attribute; changing the attribute via `setAttribute()` and
`removeAttribute()` had no immediate effect.
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.
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.
Corresponds to part of https://github.com/whatwg/html/pull/9841 and then
https://github.com/whatwg/html/pull/11047
Adding `Auto` as a type state feels a little odd, as it's not an actual
type allowed in HTML. However, it's the default state when the value is
missing or invalid, which works out the same, as long as we never
serialize "auto", which we don't.
This commit begins to implement the track processing model. When the
`src` attribute is updated, we now fetch the given source file.
Currently, we always fire an `error` event once fetching is completed,
as we don't support processing the fetched data.
This matches the behavior of other browsers, which always set the dirty
checkedness flag when setting checkedness, except when setting the
`checked` content attribute.
