These are only used for debugging, so I've decided that logging the
ErrorOr<String> itself is fine instead of trying to handle that error
more gracefully in those cases. If you're getting OOM trying to debug
log things, you have bigger problems.
DeprecatedFlyString relies heavily on DeprecatedString's StringImpl, so
let's rename it to A) match the name of DeprecatedString, B) write a new
FlyString class that is tied to String.
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 :^)
Prevent media query parser from falling back into
MediaQuery::create_not_all() for queries with unknown media type.
With this change following test works correctly:
http://wpt.live/css/css-conditional/at-media-001.html
These will be used when resolving calc() values in StyleComputer.
It's indeed strange that calc() resolves to tokens, but it's how the
engine currently handles those things. There is room for improvement.
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.
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.
This could potentially be sped up by tracking the up to three different
ranges of characters known to be digits. This would save the double
parser from checking whether these are digits and because it has the
size it can use the fast parsing method.
