Issues in Layout that do not fit into any other Layout component or which span multiple Layout components.

Bugs related to the top level presentation objects (pres shell, pres context, and document viewer), the frame constructor, and the base frame classes, as well as general issues with alignment and sizing, all belong here.

One an element is broken up into several layout frames, the CSS outline should
be drawn around the entire collection of frames. It should not be drawn as
several overlapping outlines.
This needs to take into account -moz-outline-radius and -moz-outline-offset as well.

There are some spec issues here, I think. How should the outline be drawn in a
situation like this?
<style>.vot::first-line { opacity:0.5; }</style>
<div class="vot">
<span style="outline:2px solid red;">Hello<br>Kitty</span>
</div>
So we still need to break up the unified outline into pieces that belong to
individual frames and paint each piece when its frame paints. But we need to
make sure that no part of the unified outline is painted twice or we'll get
incorrect results for rgba() colors. We may also need to think about how dotted
or dashed borders are going to work.
I thought this interacted with z-ordering too, but as far as I can tell it
really doesn't.
So in PaintOutline, we look at the other frames for the content and figure out
what the union outline is and which part this frame should paint. Here's how
this could work. There are two regions associated with each outline: the
interior (the area enclosed by the outline's inner edge) and the exterior (the
area enclosed by the outline's outer edge). Say that a frame paints its regular
outline clipped to exclude all the exteriors of its prev-in-flow frames'
outlines and to exclude all the interiors of its next-in-flow frames' outlines.
This will guarantee that no point in any interior is painted, and every point in
the union of the outlines is painted exactly once.
I think we could actually implement it this way by building clip regions, even
for outline-radius by gluing together 1-pixel-high rectangles. It might be a bit
slow for frames with a large outline-radius but we could optimize by only doing
the clipping thing when we know the frame's overflow area intersects with other
frames in its in-flow list.

That doesn't address getting dots and dashes right. That seems really tricky. To
fix that, we'd have to do the clipping thing but instead of painting the frame's
outline normally, compute the geometric path for the union outline and paint
that. That would require taking the post-segmentation polygon for each frame
outline, figuring out intersections and which segments are the boundary
(difficult since it has width), and then painting that.

The outline for an element should be rendered all at once, not piecemeal. So
there isn't a problem here. You'd render the outline for that inline way after
you've rendered the rest of the block (in fact you should do it at the end of
the stacking context).

Created attachment 187150[details]
changes from 1.0.4 to 1.0+
On the 19/6/05 nightly, rendering has improved for the testcase in this bug,
but still fails for the testcase in bug 280087 (attachment 172646[details]), as shown in
this collection of screenshots.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050619
Firefox/1.0+

Now that bug 317375 has landed, outlines for all frames for a single element are painted consecutively in z-order whenever possible. We could copy the merging logic from nsDisplayOpacity to nsDisplayOutline, or use some other approach, to ensure that the outlines for a single element are painted in a single operation. Cairo drawing APIs are available through Thebes in cairo builds, so we should be able to go ahead and fix this now in cairo builds.
The only remaining problem is to figure out exactly how this should be implemented in its full generality. The idea in comment #2 would be fairly easy to do with cairo but it doesn't handle dotted and dashed outlines well.

The inaccuracy of the bug summary makes it difficult to find this bug report; "glob" is not a real english verb, otherwise, it is a word difficult to understand or to translate.
Bug summary changed to:
Outline applied on a multi-line element should encompass all the line boxes and stay connected.
I considered "wrap around", "enclose" and "surround".
-------------
(In reply to j.j. (inactive in 2012) from comment #15)
> (The second example in testcase3 is probably another bug)
Such exaple is interesting because there is no test for such kind of line box scenario at CSS 2.1 test suite: a line box with a few inline boxes of various line-heights.
I'm working on a test to be submitted based on your 2nd example in testcase3.
When the spec says "Outlines may be non-rectangular. For example, if the element is broken across several lines, the outline is the minimum outline that encloses all the element's boxes.", then I think it suggests that a line box with several inline boxes of various line-heights should be enclosed using a non-rectangular outline.
Gérard

Summary: Multiple outlines from the same element should glob together instead of overlapping → Outline applied on a multi-line element should encompass all the line boxes and stay connected

> (...) there is no test for such kind of line
> box scenario at CSS 2.1 test suite: a line box with a few inline boxes of
> various line-heights.
> I'm working on a test to be submitted based on your 2nd example in
> testcase3.
Recently submitted test at CSS 2.1 test suite:
http://test.csswg.org/suites/css2.1/nightly-unstable/html4/outline-layout-006.htm
IE9, IE10, Opera 12.12 and Opera 12.50 pass this test.
I'll create another bug report for this one.
Gérard

> I'll create another bug report for this one.Bug 825058: Outline applied on element with a few inline boxes of various line-heights should be minimal and should encompass all the inline boxes and stay connected

> the shape of the outline
> border (non-rectangular) is not specified by the CSS2.x spec (and not even
> in CSS2 UI).
I meant to say
(...) is not specified by the CSS2.x spec (and not even in CSS3 UI).