Modified the test-page because FontDatabase looks for exact font-weight
matches, so requesting weight 800 in a font that only has 700, causes
it to return the default font instead. So, we ask for 700 here.
The actual fix is to improve our font-matching but I am trying not to
get distracted today. :^)
None of these require any outside metrics, which is nice! I believe the
Values-4 spec would have us simplify them down into a single value at
parse time, but that's a yak for another day.
Most of the time, we cannot resolve a `calc()` expression until we go to
use it. Since any `<length-percentage>` can legally be a `calc
()`, let's store it in `LengthPercentage` rather than make every single
user care about this distinction.
The previous static functions are now methods of their respective
CalcFoo structs, but the logic has not changed, only that they work
with CalculationResults instead of converting everything to floats.
calc() sub-expressions can return a variety of different types, which
then can be combined using the basic arithmetic operators. This class
should make that easier to deal with, instead of having to handle all
the possible combinations at each call site. :^)
We take the Layout::Node as a pointer not a reference, since later we'll
need to call these functions when resolving to `<number>` or `<integer>`
which don't use those, and we don't want to force users to pass them in
unnecessarily.
See https://www.w3.org/TR/css-values-3/#calc-type-checking
If the sub-expressions' types are incompatible, we discard the calc() as
invalid.
Had to do some minor rearranging/renaming of the Calc structs to make
the `resolve_foo_type()` templates work too.
This lets us produce valid CSS in its to_string() method, instead of
always adding commas as before. :^)
Also, finally added a Formatter for StyleValues.
Many of these will need to change in the future in order to include
features we don't yet support, and touching StyleValue.h is a great way
to have to wait for all of LibWeb to rebuild. I'm hoping this saves me
time in the long run. :^)
Raw whitespace is not allowed inside a name, but escaped whitespace is,
for example `\9`, which is the tab character.
This stops yakzz.com from crashing the Browser, since it was using `\9`
in various places as a hack to only apply those properties to IE8/9.
`convert_nodes_to_single_node` is inside its own file so ChildNode can
include and use it without having to include other headers such as
DOM/Node.h. This is to prevent circular includes.
In order to avoid having multiple instances, we were keeping a pointer
to these singleton objects and only allocating them when it was null.
We have `__cxa_guard_{acquire,release}` in the userland, so there's no
need to do this dance, as the compiler will ensure that the constructors
are only called once.
Apologies for the enormous commit, but I don't see a way to split this
up nicely. In the vast majority of cases it's a simple change. A few
extra places can use TRY instead of manual error checking though. :^)
Rather than having separate systems for the attributes and their CSS
equivalents, we can treat the attributes as presentational hints and
convert them to CSS properties. This means they can be inherited, as
they should. :^)
As noted, the `fill` and `stroke` attributes do not fully match the
`fill` and `stroke` properties. The CSS spec is still an early draft and
not entirely helpful, so we can just pretend they are the same for now.
CSS has rules about automatic blockification or inlinification of boxes
in certain circumstances.
This patch implements automatic blockification of absolutely positioned
and floating elements. This makes the smile appear on ACID2. :^)
This is a bit of a hack to get box content to stop bleeding 1px outside
the border sometimes. We will need to come up with a more general
solution for this problem eventually.
While IFC flows text into a block container, floating objects are
anchored at the BFC root, not necessarily the local block container.
Because of this, we have to use root-relative coordinates when checking
how much space is available in between left and right floated objects.
Block placement is now divided into a vertical and horizontal step. The
vertical step runs before formatting boxes internally. The horizontal
step still runs after (since we may need the final width value.)
This solves a long-standing architectural problem where IFC didn't know
its origin Y position within the BFC root box. This is required for
figuring out how to flow around floating objects. (Floating objects are
always relative to the BFC root.)
