This commit fixes algorithm for computing auto height (CSS 2.2 10.6.7)
by including floating boxes into computation and implements one of the cases
for computing the height of absolutely positioned, non-replaced elements (10.6.4 rule 3)
The bullet point should not be centered in the height of the list item,
but rather stay in front of the first line.
So, instead of giving the marker the full height of the ListItemBox,
it gets the height of a single line.
This closes#6384
This is because it includes the initial node that the function was
called on, which makes it "inclusive" as according to the spec.
This is important as there are non-inclusive variants, particularly
used in the node mutation algorithms.
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.
For now, painting of background color is kept separate. The ICB needs to
perform a "translate" call between painting the color and background,
whereas other divs must not make that call.
This also adds an API to Label to determine if the Label itself or its
child TextNode is hovered. This allows ButtonBox to render in a hovered
state when the label is hovered.
A label's format is: <label>Label text</label>
So, a TextNode is created as a child of the Label node, and EventHandler
will send events to the TextNode. This changes TextNode to accept mouse
events if its parent is a Label, and to forward those events upward.
The HTML <label> element is special in that it may be associated with
some other <input> element. When the label element is clicked, the input
element should be activated.
To achieve this, a LableableNode base class is introduced to provide an
interface for "labelable" elements to handle mouse events on their
associated labels. This not only allows clicking the label to activate
the input, but dragging the mouse from the label to the input (and vice-
versa) while the mouse is clicked will also active the label.
As of this commit, this infrastructure is not hooked up to any elements.
For example:
<div>
<input type=radio name=group value=item1 />
</div>
<div>
<input type=radio name=group value=item2 />
</div>
Is a valid DOM and clicking on of these radio buttons should uncheck
the other.
Update the painting of background images for both <body> nodes and other
non-initial nodes. Currently, only the following values are supported:
repeat, repeat-x, repeat-y, no-repeat
This also doesn't support the two-value syntax which allows for setting
horizontal and vertical repetition separately.
This is required for the block formatting context to know the height of
the <br> element while computing the height of its parent. Specifically,
this comes into play when the <br> element is the first or last child of
its parent. In that case, it previously would not have any fragments, so
BlockFormattingContext::compute_auto_height_for_block_level_element
would infer its top and bottom positions to be 0.
Turns out compute_position should be invoked before placing the element
in normal flow. Otherwise, the position isn't set on the first layout.
The effect was that the block would "jump" into place on a secondary
layout.
This is a follow-up to commit:
deda7c8995
Section 10.3 "Calculating widths and margins" indicates that the 'left'
and 'right' properties of relatively positioned elements should be set
in accordance with the rules of section 9.4.3.
Section 10.6.4 rule 5 of the CSS height property spec outlines a method
to compute the height of an absolutely positioned block when the 'top'
and 'bottom' CSS properties are specified.
The case for computing auto-height of block elements which have block-
level children was erroneously skipping some children:
1. If the block element itself is absolute or floating, all children
were skipped due to a likely typo ("box" vs. "child_box" inside the
for-each loop).
2. Floating children should only be skipped if the block element's
'overflow' property computes to 'visible', per section 10.6.3 of the
CSS height property spec. If the property computes to another value,
section 10.6.7 only indicates that absolutely positioned children
should be skipped.
Auto block heights are now computed according to something that kinda
resembles the specification.
Blocks with inline children and height:auto have their height computed
based on the top of the first line box and the bottom of the last line
box. Very straightforward.
Blocks with block children and height:auto have their height computed
based on the top of the first in-flow block child's margin box, and the
bottom of the last in-flow block child's margin box.
Previously the page background was always draw relative to the viewport
instead of following with the content. This should eventually become
an opt-in mode (via CSS "background-attachment") but for now let's have
the default behavior be that backgrounds scroll with content.
Also take this opportunity to move the background painting code from
the two web views to a shared location in InitialContainingBlockBox.
It was previously using draw_tiled_bitmap, which always aligns the
tiles with the global origin and does not respect the alpha of the
source. Switch to a new Painter::blit_tiled helper which uses
Painter::blit under the hood, which has more correct behavior.
We try scrolling a Node with the handle_mousewheel event, but if it
isn't scrollable, the event should be passed back up to the page
host. This is the first step in that process.
(...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.
We implement this by adding a BlockBox::is_scrollable() helper,
and then ignoring wheel events for non-scrollable boxes.
Thanks to FireFox317 for pointing this out! :^)
This is rather crude, but you can now use the mouse wheel to scroll up
and down in block-level boxes with clipped overflowing content.
There's no limit to how far you can scroll in either direction, since
we don't yet track how much overflow there is. But it's a start. :^)
We now apply a paint-time clip to the padding rect of a BlockBox before
painting its inline-level children. This covers some of the behavior
we want from "overflow: hidden" etc but is far from a complete solution.
Elements with shadow roots will now recurse into those shadow trees
while building the layout tree.
This is the first step towards basic Shadow DOM support. :^)
The approach of attaching sub-widgets to the web view widget was only
ever going to work in single-process mode, and that's not what we're
about anymore, so let's just get rid of WidgetBox so we don't have the
dead-end architecture hanging over us.
The next step here is to re-implement <input type=text> using LibWeb
primitives.
We'll want to remove the LibGUI dependency from the WebContent process.
This is the first basic step of removing unnecessary LibGUI includes
and swapping out GUI::Painter for Gfx::Painter.
Image boxes want to know whether they are inside the visible viewport.
This is used to pause/resume animations, and to update the purgeable
memory volatility state.
Previously we would traverse the entire layout tree on every resize,
calling a helper on each ImageBox. Make those boxes register with the
frame they are interested in instead, saving us all that traversal.
This also makes it easier for other parts of the code to learn about
viewport changes in the future. :^)
The ImageDecoder service now returns a list of image frames, each with
a duration value.
The code for in-process image decoding is removed from LibWeb, an all
image decode requests are sent out-of-process to ImageDecoder. :^)
This won't scale super well to very long and/or large animations, but
we can work on improving that separately. The main goal here is simply
to stop doing any image decoding inside LibWeb.
Fixes#5165.
A C++ source file containing just
#include <LibFoo/Bar.h>
should always compile cleanly.
This patch adds missing header inclusions that could have caused weird error
messages if they were used in a different context. Also, this confused QtCreator.
The FFC now supports both vertical and horizontal flex layout, based on
the flex-direction property. It's still extremely naive, but at least
now you can be naive in two directions! :^)
This implementation of flexbox is going to take a lot of work, but at
least now we've gotten started.
