If the first element of an SVG path spec uses relative coordinates,
we'll now treat them as absolute. This is achieved by defaulting to
(0,0) as the initial "last point" in the path.
In some cases these can be several KiB or more in size, making checking
very slow, and it doesn't make sense to filter them out anyway. This
change speeds up loading pages with large data: urls, which previously
took up to 1ms per byte to process.
If a page is nice enough to give us some preload hints, we can tell
RequestServer to get started on downloading the resources right away,
instead of waiting until discovering them later on during parsing.
This patch adds the setProperty(name, value) API to CSSStyleDeclaration.
Setting an invalid or empty value will cause the property to be removed
from the declaration.
Note that this only works on mutable declarations (i.e element.style)
and not on resolved declarations (i.e window.getComputedStyle(element)).
A legacy platform object is a non-global platform object that
implements a special operation. A special operation is a getter, setter
and/or deleter. This is particularly used for old collection types,
such as HTMLCollection, NodeList, etc.
This will be used to make these spec-compliant and remove their custom
wrappers. Additionally, it will be used to implement collections that
we don't have yet, such as DOMStringMap.
We now fire "pageshow" events at the appropriate time during document
loading (done by the parser.)
Note that there are no corresponding "pagehide" events yet.
This will be used to determine whether "pageshow" and "pagehide" events
are appropriate. We won't actually make use of it until we implement
more of history traversal and document unloading.
The only difference from what we were already doing is that setting the
same ready state twice no longer fires a "readystatechange" event.
I don't think that could happen in practice though.
We have to mark the EventListener objects so that we can tell them apart
from listeners added via the addEventListener() API.
This makes element.onfoo getters actually return the handler function.
We will now spin in "the end" until there are no more "things delaying
the load event". Of course, nothing actually uses this yet, and there
are a lot of things that need to.
The ideal solution here is to implement a more spec-compliant event
loop, but while we get all the pieces in place for that, this at least
makes the HTML event loop a bit more responsive since it never has to
wait for a 16ms timer to fire.
The old name is the result of the perhaps somewhat confusingly named
abstract operation OrdinaryFunctionCreate(), which creates an "ordinary
object" (https://tc39.es/ecma262/#ordinary-object) in contrast to an
"exotic object" (https://tc39.es/ecma262/#exotic-object).
However, the term "Ordinary Function" is not used anywhere in the spec,
instead the created object is referred to as an "ECMAScript Function
Object" (https://tc39.es/ecma262/#sec-ecmascript-function-objects), so
let's call it that.
The "ordinary" vs. "exotic" distinction is important because there are
also "Built-in Function Objects", which can be either implemented as
ordinary ECMAScript function objects, or as exotic objects (our
NativeFunction).
More work needs to be done to move a lot of infrastructure to
ECMAScriptFunctionObject in order to make FunctionObject nothing more
than an interface for objects that implement [[Call]] and optionally
[[Construct]].
Some sites don't have favicon.ico, so we may get 404 response.
In such cases, ResourceLoader still calls success_callback.
For favicon loading, we are not checking response headers or payload
size.
This will ultimately fail in Gfx::ImageDecoder::try_create().
So avoid unnecessary work by returning early, if data is empty.
This doesn't work correctly in the new world where fonts are resolved
during the CSS cascade. Let's patch it out with a FIXME and get back to
it once everything has fallen into place.
Resolved style is a spec concept that refers to the weird mix of
computed style and used style reflected by getComputedStyle().
The purpose of this class is to produce the *computed* style for a given
element, so let's call it StyleComputer.
Once we've performed the cascade on a set of values for an element,
we should have enough information to resolve/absolutize some lengths.
Basically, any CSS length that isn't "auto" or a percentage can be
turned into an absolute length (in pixels) as long as we have the
following information:
- The viewport rect
- The parent element's font
- The document element's font
- The element's own font
To ensure that we can absolutize lengths relative to the element's own
font, we now do a separate first pass where font-related properties are
defaulted (in the cascade spec sense of the word) and become usable.
There's a lot more work to do here, but this should open up a lot of
simplification in layout code, since it will no longer need to care
about relative lengths. Layout still needs to resolve percentages, since
we can't do that for some properties until the containing block
dimensions are known.
The original name was based on the window.getComputedStyle() API.
However, "Computed" in "getComputedStyle" is actually a misnomer that
the platform is stuck with due to backwards compatibility.
What getComputedStyle() returns is actually a mix of computed and used
values. The spec calls it the "resolved" values. So let's call this
declaration subclass "ResolvedCSSStyleDeclaration" to match.
