Like the name suggests this pointer type compares its pointees by value
rather than just by the pointer. This is needed for the defaulted
struct Properties equality operator.
This commit also contains a few changes to StyleValue such as replacing
the operator==()s with a .equals() again. This is done to avoid the new
reversed operator==()s ambiguity in C++20.
This removes a load of manually implemented equality operators. This
is done with a little pattern where all properties of a StyleValue are
placed inside a Properties member struct, with a defaulted equality
operator. This is then used to do the actual StyleValue compare.
There is also a CTRP class to avoid manually implementing the virtual
operator==()s for all StyleValues.
Gfx::Color is always 4 bytes (it's just a wrapper over u32) it's less
work just to pass the color directly.
This also updates IPCCompiler to prevent from generating
Gfx::Color const &, which makes replacement easier.
This will make it easier to support both string types at the same time
while we convert code, and tracking down remaining uses.
One big exception is Value::to_string() in LibJS, where the name is
dictated by the ToString AO.
We have a new, improved string type coming up in AK (OOM aware, no null
state), and while it's going to use UTF-8, the name UTF8String is a
mouthful - so let's free up the String name by renaming the existing
class.
Making the old one have an annoying name will hopefully also help with
quick adoption :^)
C++20 can automatically synthesize `operator!=` from `operator==`, so
there is no point in writing such functions by hand if all they do is
call through to `operator==`.
This fixes a compile error with compilers that implement P2468 (Clang
16 currently). This paper restores the C++17 behavior that if both
`T::operator==(U)` and `T::operator!=(U)` exist, `U == T` won't be
rewritten in reverse to call `T::operator==(U)`. Removing `!=` operators
makes the rewriting possible again.
See https://reviews.llvm.org/D134529#3853062
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.
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.
Add classes ExplicitTrackSizing and MetaGridTrackSize which will allow
for managing properties like auto-fill and minmax.
In the following CSS example there are 3 classes that will be used:
grid-template-column: repeat(auto-fill, minmax(50px, 1fr) 75px);
ExplicitTrackSizing - will contain the entire value. e.g.
repeat(auto-fill, minmax(50px, 1fr) 75px)
With a flag if it's a repeat, as well as references to the
MetaGridTrackSizes which is the next step down.
MetaGridTrackSize:
Contain the individual grid track sizes. Here there are two:
minmax(50px, 1fr) as well as 75px.
This way can keep track if it's a minmax function or not, and the
references to both GridTrackSizes in the case it is, or in just the one
if it is not.
GridTrackSize:
Is the most basic element, in this case there are three in total; two of
which are held by the first MetaGridTrackSize, and the third is held by
the second MetaGridTrackSize.
Examples: 50px, 1fr and 75px.
This style value holds a list of CSS filter function calls e.g.
blur(10px) invert() grayscale()
It will be used to implement backdrop-filter, but the same style value
can be used for the image filter property.
(The name is a little awkward but it's referenced to as
filter-value-list in the spec too).
Values that contain percentages require special treatment in various
parts of layout. Previously we had no way of peeking into calc() values
to see if their expression contains one or more percentages. That's the
bulk of what we're adding here.
The only accepted syntax for these seems to be
<color> <length percentage> <length percentage>, no other order.
But that's just gathered from looking at other browsers as though
these are supported by all major browsers, they don't appear in
the W3C spec.
This commit moves both the ImageStyleValue and LinearGradientStyleValue
to a common base class of AbstractImageStyleValue. This abstracts
getting the natural_width/height, loading/resolving, and painting
the image.
Now for 'free' you get:
- Linear gradients working with the various background sizing/repeat
properties.
- Linear gradients working as list-markers :^) -- best feature ever!
P.s. This commit is a little large as it's tricky to make this change
incrementally without breaking things.
The -webkit version of linear-gradient does not include the `to`
before a <side or corner>. The angles of the <side or corner>
for the webkit version are also opposite that of the standard one.
So for the standard: linear-gradient(to left, red, blue)
The webkit version is: -webkit-linear-gradient(right, red, blue)
Adding the `to` in the -webkit version is invalid, omitting it in
the standard one is also invalid.
When a `calc()` is resolved, it can only return a Percentage value if
the requested type is Percentage. In all other cases, it returns a
concrete value.
eg, a `calc()` with Lengths and Percentages in will always resolve to a
Length, never a Percentage. This means we can just return Length
directly instead of LengthPercentage, which simplifies things in a few
places.
