This parses conic-gradient()s while also attempting to share the bulk
of the parsing code with linear-gradient()s. This is done by extracting
the <color-stop-list> parsing to a "fill in the blacks" generic
function. This is a little awkward but cuts down on a lot of copy
pasting of code.
This parses <position> according to the following grammer:
<position> = [
[ left | center | right ] || [ top | center | bottom ]
|
[ left | center | right | <length-percentage> ]
[ top | center | bottom | <length-percentage> ]?
|
[ [ left | right ] <length-percentage> ] &&
[ [ top | bottom ] <length-percentage> ]
]
The code is a little hairy and simply tries each alternative in turn,
manually checking the possible orders. There may be a better way to
represent this.
This class represents a <position> and handles resolving it to a
Gfx::FloatPoint relative to some rectangle.
It can handle all forms of <position>:
- Two presets:
left center
- A preset + a length percentage:
10% bottom
- Or relative to some edges:
right 20% bottom 30px
This commit adds a simple style value (which is an abstract image)
to represent conic-gradient()s.
This commit also starts to factor out some reusable parts of the
linear-gradient() style value for other gradient types.
This was an oversight from when I converted PendingResponse and various
other classes from being ref-counted to GC-allocated last minute - no
one takes care to keep all of them alive. Some are on the stack, and
some might be captured in another PendingResponse's JS::SafeFunction,
but ultimately, we need a better solution.
Since a PendingResponse is *always* the result of someone having created
a Request, let's just let that keep a list of each PendingResponse that
has been created for it, and visit them until they are resolved. After
that, they can be GC'd with no complaints.
Otherwise, we end up propagating those dependencies into targets that
link against that library, which creates unnecessary link-time
dependencies.
Also included are changes to readd now missing dependencies to tools
that actually need them.
Refactor various classes in the GridTrackSize file for the incoming
named_tracks feature.
Previously the ExplicitTrackSizing had mixed responsiblities with the
newly-named GridRepeat class. This made it so it was not possible to
have multiple repeats within a single 'GridTrackSizeList' definition.
The MetaGridTrackSize class had both the responsibilities of being a
container for minmax values as well as for simple GridSizes. By uniting
the different possible values (repeat, minmax, default) into the
ExplicitGridTrack class are able to be more expressive as to the
different grid size modalities.
The GridTrackSizeList will be useful as compared to a
Vector<ExplicitGridTrack> since this way can keep track of the declared
line names. These same line names are able to be declared within the
values of a repeat function, hence the presence of a GridTrackSizeList
inside the GridRepeat class.
In order to avoid naming conflicts with the many trial-and-error name
changes going on in the GridTrackSize file, rename this to a unique name
that is unlikely to be troublesome.
Before were resetting the auto_placement_cursor_x to 0 at the end of
the row but this was incorrect, especially since the
auto_placement_cursor_y wasn't being incremented.
This made it so that auto-placed items were occasionally placed before
absolutely-placed ones even after the latter had already been placed.
With so much infrastructure implemented, we can finally add the last
piece of this puzzle - the fetch() method itself!
This contains a few hundred lines of generated code as handling the
RequestInfo and RequestInfo parameter types manually is not feasible,
but we can't use the IDL definition as the Window object is handwritten
code at the moment.
It's neatly tucked away in Bindings/ and will be removed eventually.
This implements the following operations from section 4 of the Fetch
spec (https://fetch.spec.whatwg.org/#fetching):
- Fetch
- Main fetch
- Fetch response handover
- Scheme fetch
- HTTP fetch
- HTTP-redirect fetch
- HTTP-network-or-cache fetch (without caching)
It does *not* implement:
- HTTP-network fetch
- CORS-preflight fetch
Instead, we let ResourceLoader handle the actual networking for now,
which isn't ideal, but certainly enough to get enough functionality up
and running for most websites to not complain.
There will be a lot of different cases where we'll return an error
response, and having a customized Promise rejection message seems quite
useful.
Note that this has to be distinct from the existing 'status message',
which is required to be empty in those cases.
The header-specific ABNF rules are completely ignored for now, but we
can at least extract a single header value, which at least works for
simple cases like `Location`-based redirects.
