Also add the internal slot names as comments, and separate them into
groups of spec and non-spec members.
This will make it easier to compare the implementation code with the
spec, as well as identify internal slots currently missing or only
present on FunctionObject.
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.
This replaces a bunch of casts with `.as_foo()` calls, and adjusts calls
to the old `is_foo()` methods that now are better as `has_foo()`.
Also tidied up some whitespace to be more consistent.
This does a few things, that are hard to separate. For a while now, it's
been confuzing what `StyleValue::is_foo()` actually means. It sometimes
was used to check the type, and sometimes to see if it could return a
certain value type. The new naming scheme is:
- `is_length()` - is it a LengthStyleValue?
- `as_length()` - casts it to LengthStyleValue
- `has_length()` - can it return a Length?
- `to_length()` - gets the internal value out (eg, Length)
This also means, no more `static_cast<LengthStyleValue const&>(*this)`
stuff when dealing with StyleValues. :^)
Hopefully this will be a bit clearer going forward. There are lots of
places using the original methods, so I'll be going through them to
hopefully catch any issues.
FontPickerWeightModel is no longer necessary as variants contain
weight as part of a complete typeface description. This fixes fonts
not inventorying correctly in picker when they contained more than
bold and regular typefaces. Weight mapping has been moved into
LibGfx/FontStyleMapping.h
Previously the algorithm was being performed from the start of the
string to the end, which was a little more convenient when writing
the code, but made it more annoying to be able to properly talk
about the "start" of where the changes were happening, since we
can only re-construct the changes in reverse order of the initial
traversal.
Basically, doing the initial pass in reverse lets us reconstruct
the hunks in the correct order to begin with, and not have to worry
about reversing the hunks / lines within the hunks
This behaves very much like the regular diff command, showing the
start lines and ranges of additions/changes/deletions in both the
source and target files.
These now crash as VM::call() uses ThrowExceptionOr<T>, which refuses to
hold an empty JS::Value as its non-exception result.
We only need to return an empty value when should_return_empty() says
so for the return value of throw_dom_exception_if_needed().
Co-authored-by: Luke Wilde <lukew@serenityos.org>
