| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
| |
Just use Clear instead, they have the same values.
|
|
|
|
|
|
|
|
| |
Since #29950, unit tests were only running with the legacy layout, and
there was no way to run them for layout 2020.
This patch makes './mach test-unit' run unit tests for both.
Also doing some changes so that the layout 2020 floats.rs tests compile.
|
|
|
| |
It was useful when it had 3 callers, but #29977 removed 2 of them.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Add initial support for css-text-3 whitespace handling
This adds initial support for whitespace handling from the CSS
specification for Layout 2020. In general, the basics are covered. Since
test output is very sensitive to whitespace handling, this change
incorporates several fixes:
1. Whitespace is collapsed according to the Phase 1 rules of the
specification, though language-specific unbreaking rules are not
handled properly yet.
2. Whitespace is mostly trimmed and positioned according to the Phase 2
rules, but full support for removing whitespace at the end of lines
is pending on a temporary data structure to hold lines under
construction.
3. Completely empty box fragments left over immediately after line
breaks are now trimmed from the fragment tree.
4. This change tries to detect when an inline formatting context
collapses through.
Fixes #29994.
Co-authored-by: Mukilan Thiyagarajan <me@mukilan.in>
Co-authored-by: Martin Robinson <mrobinson@igalia.com>
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
* Update test results
---------
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
Co-authored-by: Mukilan Thiyagarajan <me@mukilan.in>
Co-authored-by: Martin Robinson <mrobinson@igalia.com>
|
|
|
|
|
|
|
| |
(#30012)
A block that establishes an independent formatting context is placed
next to previous floats, so we should add their sizes when computing
the intrinsic contribution of the parent block container.
|
|
|
|
|
|
|
|
|
|
|
| |
Remove rayon_croissant and refactor the way that information about
floats in flows bubbles up. This simplifies the code a good deal and
lets us take advantage of some more optimized functions provided by
rayon. This removes 2 crates from the dependency tree.
In addition, this allows avoiding passing `contains_floats` up from
every box tree construction function. This makes things simpler, but
also opens up the possibility of passing more of these flags up in the
future (such as `contains_counters`).
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
calculate_inline_content_size_for_block_level_boxes was relying on
inline_content_sizes to get the size of each block-level box child.
For absolutely positioned boxes, this was 0x0.
That was no-op before #29887, but then it prevented adding the sizes
of a sequence of floats. Abspos should just be ignored instead of
treated as 0x0.
This patch removes inline_content_sizes, moves the logic into
calculate_inline_content_size_for_block_level_boxes (the only caller),
and handles abspos correctly.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Place replaced and non-auto inline size independent FCs next to floats
The CSS2 specification says that replaced content and independent
formatting contexts should be placed next to floats. This change adds
support for that, but punts on support for independent formatting
contexts that have an auto inline size. With an auto inline size, we
which requires a much more complex layout algorithm.
Co-authored-by: Oriol Brufau <obrufau@igalia.com>
* Fix issue with where last band was taken into account for inline size
* adjustment_from_floats should prevent margin collapse
* Properly handle elements with 0 height
---------
Co-authored-by: Oriol Brufau <obrufau@igalia.com>
|
| |
|
|
|
|
| |
Co-authored-by: Samson <16504129+sagudev@users.noreply.github.com>
|
|
|
|
|
|
|
|
|
|
|
| |
This function is already quite big and the changes necessary for
properly laying out independent formatting contexts next to floats will
make it even more unwieldy. Split the function in two and add a helper
for calculating the containing block for children and the margin. As
time goes on the independent formatting case is probably going to be
more like the replaced case anyway.
Co-authored-by: Oriol Brufau <obrufau@igalia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Every time that we would lay out a block box that could collapse its
top margin with its contents, we would do a lookahead to compute the
resulting margin in order to place floats correctly.
The problem was that this lookahead could iterate several descendants,
but then when laying these we would run the lookahead again.
This patch restricts the lookahead to boxes that either aren't collapsing
their top margin with their parent, or that have 'clear' different than
'none' (since clearance prevents collapsing margins with the parent).
Since the lookahead stops iterating when it finds a box that doesn't
collapse its top margin with its parent, or whose 'clear' isn't 'none',
this should ensure that lookahead never handles the same box twice.
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Check computed (min-)block-size when determining margin collapse
To collapse margins through, CSS2 requires "zero or auto computed height" and "zero computed min-height" (the latter should also also include auto, which was introduced in CSS3 as the new initial value).
Similarly, "auto computed height" is required to collapse the bottom margin with the bottom margin of the contents.
Therefore this patch stops collapsing when the used height is clamped to zero by max-height, but the computed value is not zero. Same for non-zero percentages that are indefinite or that resolve to 0px.
Note that 0% and calc(0% + 0px) are still considered to be zero (so they allow margin collapse), this may a bit inconsistent but matches Firefox (for the collapsing through case).
This also matches the heuristics in find_block_margin_collapsing_with_parent(). We could change the heuristics instead, but then they would have to track block sizes in order to be able to resolve percentages.
The change makes margin-collapse-through-percentage-height-block.html fail, that test is only passing on Blink, which did a different interpretation of the spec. To be fair, various places of CSS2 loosely consider that indefinite percentages compute to auto, and even Firefox does so when determining whether to collapse the top margin with the contents.
Since the spec isn't particularly clear and interoperability is lacking, I filed https://github.com/w3c/csswg-drafts/issues/8919.
<!-- Please describe your changes on the following line: -->
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix #29907
- [X] There are tests for these changes (1 test fails, see above)
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
To collapse margins through, CSS2 requires "zero or auto computed height"
and "zero computed min-height" (the latter should also also include auto,
which was introduced in CSS3 as the new initial value).
Similarly, "auto computed height" is required to collapse the bottom margin
with the bottom margin of the contents.
Therefore this patch stops collapsing when the used height is clamped
to zero by max-height, but the computed value is not zero. Same for
non-zero percentages that are indefinite or that resolve to 0px.
Note that 0% and calc(0% + 0px) are still considered to be zero (so they
allow margin collapse), this may a bit inconsistent but matches Firefox
(for the collapsing through case).
This also matches the heuristics in find_block_margin_collapsing_with_parent().
We could change the heuristics instead, but then they would have to track
block sizes in order to be able to resolve percentages.
The change makes margin-collapse-through-percentage-height-block.html fail,
that test is only passing on Blink, which did a different interpretation
of the spec. To be fair, various places of CSS2 loosely consider that
indefinite percentages compute to auto, and even Firefox does so when
determining whether to collapse the top margin with the contents.
Since the spec isn't particularly clear and interoperability is lacking,
I filed https://github.com/w3c/csswg-drafts/issues/8919.
|
|/
|
|
|
|
|
|
|
| |
Padding percentages weren't being resolved, this function would think
that margins wouldn't collapse even if the percentage resolved to 0px.
And margin percentages were always resolved to 0px.
So now the function takes a ContainingBlock parameter that is used to
resolve these percentages properly.
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Layout 2020: Properly calculate clearance
<!-- Please describe your changes on the following line: -->
calculate_clearance() was not taking into account that adding clearance prevents top margin from collapsing with earlier margins.
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix #29885 and #29919
- [X] There are tests for these changes
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
|
| |
| |
| |
| |
| | |
calculate_clearance() was not taking into account that adding clearance
prevents top margin from collapsing with earlier margins.
|
|\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
layout_2020: Do linebreak for atomic inline-level elements
<!-- Please describe your changes on the following line: -->
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: -->
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix #29591 (GitHub issue number if applicable)
<!-- Either: -->
- [x] There are tests for these changes OR
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
|
| | |
|
| |
| |
| |
| | |
This method finish layout of the current line and start a new one.
|
| |
| |
| |
| | |
Indicate current white-space property of current nesting context.
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
r=mrobinson
Properly position floats when subsequent boxes collapse margins with containing block (2)
PR #29939 tried to address this but missed various cases.
<!-- Please describe your changes on the following line: -->
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix #29944
- [X] There are tests for these changes
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
|
| |/
| |
| |
| |
| |
| | |
containing block (2)
PR #29939 tried to address this but missed various cases.
|
|/
|
|
|
|
|
|
|
|
| |
Clearance was implemented as a Length, where zero meant no clearance.
However, having a clearance of 0px should be different than having
no clearance, since the former can still prevent margin collapse.
This patch keeps the existing behavior, so it won't be possible to get
a clearance of Some(Length::zero()), but it prepares the terrain for
a follow-up to fix calculate_clearance to return the proper thing.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
containing block
Margins should be able to collapse through floats when collapsing with
parent blocks (the containing block). To properly place floats in this
situation, we need to look at these subsequent floats to find out how
much of the margin will collapse with the parent.
This initial implementation is very basic and the second step would be
to cache this in order to avoid having to constantly recalculate it.
Fixes #29915.
Co-authored-by: Oriol Brufau <obrufau@igalia.com>
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, final float positions were calculated when their parents
were positioned. This prevented proper positioning of absolute children
of floats with static insets, because they accumulate offsets as they
are hoisted up the tree.
This change moves the final float positioning to
`PlacementState::place_fragment` for the float itself so that it happens
before any insets are updated for hoisted descendants. In addition to
simplifying the code, this makes it a bit more efficient. Finally,
floats are taken into account when updating static insets of hoisted
boxes.
Fixes #29826.
|
|
|
|
|
|
|
|
|
|
|
| |
In #29897 I did the simple naive thing, but it wasn't entirely correct.
This patch tries to address the problems. In particular:
- Clearance should prevent margins from collapsing through if it
happens between them, as opposed to on the element that owns them.
- The margins of an element with clearance can still collapse through,
and collapse with other siblings as normal, but the resulting
margin can't collapse with the bottom margin of the parent.
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Simplify layout of absolutes with static insets
Absolutes with static insets need to be laid out at their ancestor containing blocks, but their position is dependent on their parent's layout. The static layout position is passed up the tree during hoisting and ancestors each add their own offset to the position until it is relative to the containing block that contains the absolute.
This is currently done with a closure and a fairly tricky "tree rank" numbering system that needs to be threaded through the entire layout. This change replaces that system.
Every time a child is laid out we create a positioning context to hold any absolute children (this can be optimized away at a later time). At each of these moments, we call a method to aggregate offsets to the static insets of hoisted absolutes. This makes the logic easier to follow and will also allow implementing this behavior for inline-blocks, which was impossible with the old system.
<!-- Please describe your changes on the following line: -->
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: -->
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes do not require tests because it should not change behavior.
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Absolutes with static insets need to be laid out at their ancestor
containing blocks, but their position is dependent on their parent's
layout. The static layout position is passed up the tree during hoisting
and ancestors each add their own offset to the position until it is
relative to the containing block that contains the absolute.
This is currently done with a closure and a fairly tricky "tree rank"
numbering system that needs to be threaded through the entire layout.
This change replaces that system.
Every time a child is laid out we create a positioning context to hold
any absolute children (this can be optimized away at a later time). At
each of these moments, we call a method to aggregate offsets to the
static insets of hoisted absolutes. This makes the logic easier to
follow and will also allow implementing this behavior for inline-blocks,
which was impossible with the old system.
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
r=mrobinson
Prevent margins from collapsing through when separated by clearance
This fixes #29884 and improves #29896.
<!-- Please describe your changes on the following line: -->
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix #29884 and improve #29896
- [X] There are tests for these changes
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
|
| | |
| | |
| | |
| | | |
This fixes #29884 and improves #29896.
|
|\ \ \
| |_|/
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Layout 2020: Correct rendering of floated root
Fix two issues around floating a root element:
1. In the StackingContext code handle the case where a root element is a Float fragment and not a Box fragment. This fixes a debug assertion failure in the css/CSS2/float/float-root.html test.
2. When initializing the SequentialLayoutState, use the containing block width as the maximum inline float placement position instead of infinity. This fixes the rendering of css/CSS2/float/float-root.html.
Note that css/CSS2/float/float-root.html was passing before, because both the test and reference were subject to the same bug. This fixes a couple other tests as well.
<!-- Please describe your changes on the following line: -->
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: -->
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] There are tests for these changes
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fix two issues around floating a root element:
1. In the StackingContext code handle the case where a root element is a
Float fragment and not a Box fragment. This fixes a debug assertion
failure in the css/CSS2/float/float-root.html test.
2. When initializing the SequentialLayoutState, use the containing block
width as the maximum inline float placement position instead of
infinity. This fixes the rendering of css/CSS2/float/float-root.html.
Note that css/CSS2/float/float-root.html was passing before, because
both the test and reference were subject to the same bug. This fixes a
couple other tests as well.
|
|/
|
|
|
|
| |
Typically, block-level contents are stacked vertically, so this was just
taking the maximum size among all contents. However, floats can be
stacked horizontally, so we need to sum their sizes.
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Implement BlockLevelBox::inline_content_sizes for floats
This improves #29874, but `BlockContainer::inline_content_sizes` will still need more changes in order to correctly handle sequences of floats.
<!-- Please describe your changes on the following line: -->
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [ ] These changes fix #___ (GitHub issue number if applicable)
<!-- Either: -->
- [X] There are tests for these changes OR
- [ ] These changes do not require tests because ___
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
|
| |
| |
| |
| |
| | |
This improves #29874, but BlockContainer::inline_content_sizes will still
need more changes in order to correctly handle sequences of floats.
|
|/
|
|
|
|
| |
Fix some rustdoc comments which won't process properly unless they start
with three '/' characters. In addition, improve the name of a function
and add some missing documentation.
|
|
|
|
|
|
|
|
|
|
| |
If a float has negative block margins, it should be pushed upward, but
shouldn't affect the positioning of any floats that came before it. It
should lower the ceiling though when it still has some non-negative
block contribution. In order to implement this behavior, we should only
place the float considering its non-negative block length contribution. If
the float is pushed up completely past it's "natural" position, it
should be placed like a float with zero block size.
|
|
|
|
|
|
|
|
|
|
|
| |
According to https://drafts.csswg.org/css2/#collapsing-margins, bottom
margins should only collapse with the last child if `height` is `auto`.
Also, the note mentions `min-height: 0`, but the normative text doesn't
have such requirement, so I'm dropping it, matching WebKit.
The previous logic is moved into the case of collapsing the top and
bottom margins of the same element, since this can happen either with
`height: auto` or `height: 0`, and requires `min-height: 0`.
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Layout 2020: Move all Fragment code to the `fragment_tree` directory
This is a simple code organization change with no behavior change with the idea of making Layout 2020 easier to understand by new folks to the project. The idea is that we will have a cleaner separation between the different parts of layout ie one directory for the fragment tree and one (currently multiple) directory for the box tree.
<!-- Please describe your changes on the following line: -->
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: -->
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes do not require tests because they do not change behavior.
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
|
| |
| |
| |
| |
| |
| |
| |
| | |
This is a simple code organization change with no behavior change with
the idea of making Layout 2020 easier to understand by new folks to the
project. The idea is that we will have a cleaner separation between the
different parts of layout ie one directory for the fragment tree and one
(currently multiple) directory for the box tree.
|
|/
|
|
|
|
|
| |
set to zero
Previously, end margin was allowed to collapse only when block size is
not set.
|
|
|
|
| |
These were broken for various issues.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of hoisting floated fragments to be siblings of the fragment
created by their containing block formatting context, keep them in
"normal" fragment tree position and adjust their positioning to be
relative to the containing block. This means that float fragments follow
the existing invariants of the fragment tree and properly handle hit
testing, painting order, and relative positioning.
The tradeoff here is more complexity tracking the containing block
offsets from the block formatting context (including handling collapsed
margins), but less complexity dealing with hoisting / shared ownership
in addition to the correctness benefits.
Some tests are failing now because this change revealed some additional
shortcomings with clearing block formatting context content size past
the end of their contained floats. This will be fixed in a followup
change.
Co-authored-by: Oriol Brufau <obrufau@igalia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit puts floats behind the `layout.floats.enabled` pref, because of the
following issues and unimplemented features:
* Inline formatting contexts don't take floats into account, so text doesn't
flow around the floats yet.
* Non-floated block formatting contexts don't take floats into account, so BFCs
can overlap floats.
* Block formatting contexts that contain floats don't expand vertically to
contain all the floats. That is, floats can stick out the bottom of BFCs,
contra spec.
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
layout_2020: Only count for content size for height of non-replaced inline elements
<!-- Please describe your changes on the following line: -->
Accorinding to https://drafts.csswg.org/css2/#inline-non-replaced, The vertical padding, border and margin of an inline, non-replaced box start at the top and bottom of the content area, and has nothing to do with the line-height. But only the line-height is used when calculating the height of the line box.
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: -->
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
<!-- Either: -->
- [x] There are tests for these changes OR
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
inline elements
Accorinding to https://drafts.csswg.org/css2/#inline-non-replaced, The
vertical padding, border and margin of an inline, non-replaced box
start at the top and bottom of the content area, and has nothing to do
with the line-height. But only the line-height is used when
calculating the height of the line box.
|