The new one is the same as the old one, just in the new Parser's
source files. This isn't the most elegant solution but it seemed
like the best option. And it's all temporary, after all.
We already do this in most places, so the style should be consistent.
Also, Clang does not like it, as this could cause an unexpected compile
error if some statements are added to the default label or a new label
is added above it.
This patch removes some FIXMEs from the StyleResolver, specifically
adding the proper float-parsing to the flex: shorthand. The
functionality was already there it just didn't get plumbed in before.
This takes care of the 1, 2, 3 and 4 parameter shorthand of the border-
radius identifier.
There are more as well as the ominous '/' character but that is for
another time. The 2 and 3 parameter versions are weird enough already.
I don't think anybody uses anything other than the 1 or 4 parameter
version or even the elliptical stuff.
SPDX License Identifiers are a more compact / standardized
way of representing file license information.
See: https://spdx.dev/resources/use/#identifiers
This was done with the `ambr` search and replace tool.
ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
The background-repeat value may be specified as either one- or two-value
identifiers (to be interpreted as horizontal and vertical repeat). This
adds two pseudo-properties, background-repeat-x and background-repeat-y,
to handle this. One-value identifiers are mapped to two-value in
accordance with the spec.
These are properties that may used internally by LibWeb when resolving
style values, but may not be set by external stylesheets. For example,
'background-repeat' may be a two-value CSS property that internally
translates to 'background-repeat-x' and 'background-repeat-y'.
(...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED)
Since all of these checks are done in release builds as well,
let's rename them to VERIFY to prevent confusion, as everyone is
used to assertions being compiled out in release.
We can introduce a new ASSERT macro that is specifically for debug
checks, but I'm doing this wholesale conversion first since we've
accumulated thousands of these already, and it's not immediately
obvious which ones are suitable for ASSERT.
