Outline applied on a multi-line element should encompass all the line boxes and stay connected

NEW
Unassigned

Status

()

Core
Layout
13 years ago
8 months ago

People

(Reporter: Aaron Leventhal, Unassigned)

Tracking

(Blocks: 3 bugs)

Trunk
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9.2 -
wanted1.9.2 -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [parity-IE] [parity-webkit] [parity-opera])

Attachments

(5 attachments)

(Reporter)

Description

13 years ago
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.
(Reporter)

Comment 1

13 years ago
Created attachment 163430 [details]
Testcase
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).
But in that example, the first line of the <span> element is in a different
stacking context from the second line.
*** Bug 280087 has been marked as a duplicate of this bug. ***

Comment 7

12 years ago
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.
Depends on: 317375

Comment 9

11 years ago
Out of interest, is this likely to fix bug 328193?
I don't know about bug 328193, but speaking of dependencies, I'm pretty sure it should fix bug 337274 :-)
Blocks: 337274

Comment 11

11 years ago
Guys is there any patch available for this.
Created attachment 334588 [details]
testcase2

Updated

9 years ago
Duplicate of this bug: 419408

Updated

9 years ago
Blocks: 274647

Comment 14

8 years ago
Created attachment 386881 [details]
testcase3

IE8, Safari and Opera do this.

Comment 15

8 years ago
(The second example in testcase3 is probably another bug)
Flags: wanted1.9.2?
Whiteboard: [parity-IE] [parity-safari] [parity-opera]
Flags: wanted1.9.2?
Flags: wanted1.9.2-
Flags: blocking1.9.2-
Assignee: nobody → ehsan.akhgari
Assignee: ehsan.akhgari → nobody

Updated

7 years ago
Whiteboard: [parity-IE] [parity-safari] [parity-opera] → [parity-IE] [parity-webkit] [parity-opera]
Blocks: 605520
Duplicate of this bug: 637473

Updated

5 years ago
Duplicate of this bug: 735009

Comment 18

5 years ago
Testcase from CSS2.1 test suite
-------------------------------

http://test.csswg.org/suites/css2.1/latest/html4/outline-layout-004.htm

http://test.csswg.org/suites/css2.1/nightly-unstable/html4/outline-layout-004.htm


Relevant chunk of spec
----------------------
"
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. In contrast to borders, the outline is not open at the line box's end or start, but is always fully connected if possible.
"
18.4 Dynamic outlines: the 'outline' property
http://www.w3.org/TR/CSS21/ui.html#dynamic-outlines

Comment 19

5 years ago
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

Comment 20

5 years ago
> (...) 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

Comment 21

5 years ago
> 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
Duplicate of this bug: 825058

Comment 23

a year ago
With 'writing-mode' set to 'vertical-rl'
http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/outline-inline-vrl-012.xht

With 'writing-mode' set to 'vertical-lr'
http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/outline-inline-vlr-013.xht

Chrome 50.0.2661.94, IE11 and Edge pass these 2 tests.
Created attachment 8788409 [details]
testcase3 rendered in IE11 and Google Chrome 52 and Firefox 48

For reference: attaching image capture displaying testcase3 rendered in current browsers.

Comment 25

8 months ago
Testcase from CSS2.1 test suite
-------------------------------

http://test.csswg.org/suites/css2.1/latest/html4/outline-layout-004.htm

http://test.csswg.org/suites/css2.1/nightly-unstable/html4/outline-layout-004.htm

That test is now in the NeedsWork category because the shape of the outline border (non-rectangular) is not specified by the CSS2.x spec (and not even in CSS2 UI). Only the "stay connected" and "enclose all content" items are required by the CSS2.x spec.


Therefore, I have removed the

http://test.csswg.org/suites/css2.1/nightly-unstable/html4/outline-layout-006.htm

test.

The tests

With 'writing-mode' set to 'vertical-rl'
http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/outline-inline-vrl-012.xht
 
With 'writing-mode' set to 'vertical-lr'
http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/outline-inline-vlr-013.xht

have been updated accordingly and will be submitted soon.

Comment 26

8 months ago
> 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).
You need to log in before you can comment on or make changes to this bug.