While we're here, assert that we're not doing this conversion when the
NavigationHistoryBehavior is still "auto", as the
HistoryHandlingBehavior enum is supposed to represent a "resolved"
behavior.
Instead of having a nested enum within a struct, use the macro
AK_ENUM_BITWISE_OPERATORS to add all the convienent has_flag free
functions and such for ease of use.
If the table used width has to be adjusted because of a cell with
percentage width, add back the undistributable space due to border
spacing. This is consistent with the width distribution algorithm, which
sets aside the undistributable space and the behavior of other browsers.
Otherwise, someone may try to paint the paint tree after the layout tree
has been torn down. This could in theory be possible in the future, but
until we've completely severed the paint tree's dependency on the layout
tree, this is not safe as the layout tree is no longer in a valid state.
The FIXME here describes an old constraint on JS Interpreters which no
longer holds. It hails from a time when we had the global object and
JS realm attached to the document.
The proper abstract operations on Navigable and TraversableNavigable are
not quite ready to call from Navigation. With this commit all of the
user-facing APIs of Navigation are in place, and the stage should be set
to implement the parts of the navigation and traversal AOs that need to
interact with the Navigation object.
When the grid layout gets to
`resolve_items_box_metrics(GridDimension::Column)`, we've already
determined the width of each column. However, the widths of the
individual grid items themselves haven't been set. Rather than using
`get_available_space_for_item()`, which returns an indefinite size if
an item's width/height hasn't been set, we should use the already
known track width as the available size to calculate the fit-content
width.
This is intended to annotate conversions from unknown floating-point
values to CSSPixels, and make it more obvious the fp value will be
rounded to the nearest fixed-point value.
In general it is not safe to convert any arbitrary floating-point value
to CSSPixels. CSSPixels has a resolution of 0.015625, which for small
values (e.g. scale factors between 0 and 1), can produce bad results
if converted to CSSPixels then scaled back up. In the worst case values
can underflow to zero and produce incorrect results.
This means StyleComputer::resolve_unresolved_style_value() always
returns a value, so we can change its return type.
However, it does still return an UnresolvedStyleValue sometimes, so we
can't remove those checks from the user code.
This function returns the first element which matches both the filter
for the LiveNodeList collection itself, and a further filter that is
supplied as an argument to this function.
