418912 - outline includes the overflowed area of the element

Status: RESOLVED DUPLICATE of bug 687311

(Core :: Layout, defect)

Description

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

See the testcase of URL.

The outline (red rectangular) is painted at edge of overflowed area.
CSS2.1 spec said:
http://www.w3.org/TR/CSS21/ui.html#dynamic-outlines
> The outline may be drawn starting just outside the border edge. 

The spec doesn't say clearly. But it sounds like that the outline inside edge and the border outside edge are adjacent. Opera renders as so.

Comment 1

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

The code is here:

> 2784 nsCSSRendering::PaintOutline

> 2838   nsRect overflowArea = aForFrame->GetOverflowRect();
> 2839 
> 2840   // get the offset for our outline
> 2841   aOutlineStyle.GetOutlineOffset(offset);
> 2842   nsRect outerRect(overflowArea + aBorderArea.TopLeft());
> 2843   nsRect innerRect(outerRect);
> 2844   if (width + offset >= 0) {
> 2845     // the overflow area is exactly the outside edge of the outline
> 2846     innerRect.Deflate(width, width);
> 2847   } else {
> 2848     // the overflow area is exactly the rectangle containing the frame and its
> 2849     // children; we can compute the outline directly
> 2850     innerRect.Deflate(-offset, -offset);
> 2851     if (innerRect.width < 0 || innerRect.height < 0) {
> 2852       return; // Protect against negative outline sizes
> 2853     }
> 2854     outerRect = innerRect;
> 2855     outerRect.Inflate(width, width);
> 2856   }

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

What we really want to do is probably merge adjacent boxes (e.g., on different lines).  There's a bug on that somewhere.

This may have been done intentionally; it may well be a better behavior; the spec allows it.  We shouldn't change just because Opera does otherwise; we should at least figure out why we chose to do it this way.

Comment 3

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Yeah, I'm not sure the reason. But if we consider that this is not a bug (so, we say that this is standard behavior), the spec should have note for this issue.

And note that if we change to opera like behavior, we can move away the outline of negative text-indent hack issue.

e.g., <a style="text-indent: -99999px; display: block; background-image: foo;">alt text</a>

It's used on http://www.mozilla.org/ :-(

Comment 4

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: test patch

This patch simply changes to like Opera behavior.

This patch is good for the testcase and for the negative text-indent issue.

However, even if the inline element which has images in its content, the outline is rendered as the inline box. So, the images are overflowed from outline. This behavior is not good for me.

Comment 5

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I think there are some better outline rendering spec for us. And the CSS2.1 document should be changed by the problem.

The current strict behavior of CSS2.1 is not good for <a><img/></a>. And also <a> has <sup> or <sub>.

Comment 6

[Jeff Walden [:Waldo]]

Is this the same bug that's causing this URL not to display a 150x75 green box at the top left of the viewport?

data:text/html,%3Cstyle%3E*%20{%20margin:%200;%20}%20div%20{%20font:%2010px;%20background:%20red;%20border-top:%2025px%20solid%20lime;%20width:%20100px;%20height:%200px;%20outline:%2050px%20solid%20lime;%20}%3C/style%3E%3Cdiv%3Efoobar%3C/div%3E

As far as I can tell, the line box is from the implicit overflow:visible on the div, and since the outline is drawn outside the border edge, which shouldn't include the line box because it's overflow, the outline should paint over the line generated for the text.

WebKit trunk shows a 150x75 green box at top left; the latest Opera I could find also includes a line box for "foobar" with a red background.  We do what Opera does except we don't color the line box red (correctly, I think, but we still shouldn't have the visible line box).

Comment 7

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

dbaron:

The latest CSS basic UI said:

> The position of the outline may be affected by descendant boxes.
> User agents should use an algorithm for determining the outline that encloses
> a region appropriate for conveying the concept of focus to the user. 

http://www.w3.org/TR/css3-ui/#outline1

So, is the result of the test case valid for CSS3 now?

Comment 8

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to Jeff Walden (remove +bmo to email) from comment #6)
> Is this the same bug that's causing this URL not to display a 150x75 green
> box at the top left of the viewport?
> 
> data:text/html,%3Cstyle%3E*%20{%20margin:%200;%20}%20div%20{%20font:%2010px;
> %20background:%20red;%20border-top:%2025px%20solid%20lime;%20width:%20100px;
> %20height:%200px;%20outline:%2050px%20solid%20lime;%20}%3C/
> style%3E%3Cdiv%3Efoobar%3C/div%3E

Yes.

> As far as I can tell, the line box is from the implicit overflow:visible on
> the div, and since the outline is drawn outside the border edge, which
> shouldn't include the line box because it's overflow, the outline should
> paint over the line generated for the text.

According to CSS2.1, it should be so.

> WebKit trunk shows a 150x75 green box at top left; the latest Opera I could
> find also includes a line box for "foobar" with a red background.  We do
> what Opera does except we don't color the line box red (correctly, I think,
> but we still shouldn't have the visible line box).

Google Chrome hasn't change the behavior. Current Opera renders same as Google Chrome.

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This is probably half duplicate of bug 480888 (which I just fixed) and half duplicate of bug 687311 (which I think should be WONTFIX).