687311 - outlines are drawn outside (expanded by) outlines on descendant elements

Status: NEW

(Core :: Layout, defect)

Description

[Stephanie Sullivan Rewis]

I've recently encountered some odd rendering issues in FFOX while using outline. In the first example, there are pseudo-elements that are absolutely positioned in their parent div and given negative top, right, bottom and left sides (positioning their sides outside their parent). The outline on the parent div, instead of remaining the proper size with the parent background-color, is going around the entire before and after pseudo-elements. Webkit doesn't separate the background-color and outline and if the outline is changed to border, it remains with the div. The jsFiddle to demonstrate this portion of the bug is here: http://srewis.me/qcD9GE

The second, but similar bug is also related to outline. Both the parent div and the paragraph within have an outline and an RGBa background color. The outline on the div stays outside the outline on the child P and renders a space between the div's outline and background-color on both the left and bottom. Webkit browsers render properly with the outline of the div sitting on top of the outline of the P within (since outline should not be included in the box model). Changing either the div or p from outline to border fixes the rendering in FFOX. Please view this bug demonstrated on this jsFiddle: http://srewis.me/o9IVqa

Comment 1

[philippe (part-time)]

Sounds like bug 480888

Comment 2

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

Attachment: first testcase

Comment 3

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

Attachment: second testcase

from http://srewis.me/o9IVqa

Comment 4

[Leon Sorokin]

i think i just ran across something similar. horizontal 2px mystery spacing between outline and element background. only happens in FF.

http://jsfiddle.net/CZKrY/

is this the same bug?

Comment 5

[Leon Sorokin]

filed as Bug 697899 w/ref to this one. feel free to mark as dupe if appropriate.

Comment 6

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

I guess I'm inclined to say this is a feature rather than a bug -- outlines should be drawn around descendant elements.

Comment 7

[Stephanie Sullivan Rewis]

David, I must disagree. I don't see this as a feature at all — on two points: 

On the first demo (with the pseudo-elements), the children are absolutely positioned. I would not expect the outline to go ALL the way around them (the border does not). Notice when I put a double border on the parent (so you can see the color below)—the background moves further out below the whole border: http://jsfiddle.net/stefsull/nSNaR/

Notice also on that demo, that if I remove the position:relative from the parent (there simply to give it position so the children position themselves based on the parent), the outline then moves back to the parent. http://jsfiddle.net/stefsull/YZWJ3/ (And the second problem outlined below occurs.) I would not expect an outline to enclose absolutely positioned children—they are out of the flow and should not affect that.

On the second demo (p element inside div), the issue is that the background color, if no border exists, is not not being painted under the area that would contain the border. However, as shown in this fiddle, if a border is added (again, I used a 4px double border), the background color is painted behind the border (not to the inner edge of the outline). I don't think the outline on the child should be expanding the parent. http://jsfiddle.net/stefsull/eUyJn/ 

No one would expect to put a background-color on an element, and not have it move under the space that the child is creating with THEIR outline (where the parent's border would be if it existed). Outlines tend to be used because they don't add to the box model (yes, I realize we have box-sizing now, but that's a new property and not supported everywhere yet).

If outline is to be treated like box-shadow, in that it does not add to the box model, then I would not expect the outline to go AROUND the box-shadow (example on this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=480888 ). In fact, if I use the spread radius of box-shadow instead of outline, this problem doesn't exist. Firefox draws the box-shadow exactly where I would expect to see the outline—directly outside the border. http://jsfiddle.net/stefsull/5hwWm/2/

If I change both the parent and child to create the look of the border with the spread radius value of box-shadow, creating the same effect as the outline, with the same specifications to start outside the border and not add to the box model, the element is drawn exactly as I would expect—with the child not pushing the parent out and leaving a gap in the background color: http://jsfiddle.net/stefsull/46aVv/1/

No other browser renders outline in this way—and there's no prefix to turn it off in Mozilla.

Comment 8

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

The 'outline' property is designed to render focus outlines; it should behave as an indication of focus ought to behave.  Any other use cases are purely secondary and should only be considered in so far as they do not interfere with drawing optimal focus outlines.

Comment 11

[Stephanie Sullivan Rewis]

Now that https://bugzilla.mozilla.org/show_bug.cgi?id=480888 is fixed, is there any hope we could reconsider rendering this bug and render a focus ring around the parent with pseudo-elements, but let the outline-only stay on the parent (where it was placed)?

Comment 13

[Jean-Yves Perrier [:teoli]]

ddn keyword added to update the comment in the outline page if something change in the future. I'm not sure to understand if this is a bug, the correct behavior or a possible behavior (spec underspecified).

Comment 14

[noel.abrahams]

This is a bug. Neither Webkit nor IE draw outlines around absolutely positioned child elements. 

This bug is still present as of FF version 39.0.3.

Because there is a simple workaround (outlined here: http://stackoverflow.com/questions/10662902), namely that of using box-shadow instead of outline, there has been no noise around this bug.

It is a significant nuisance to have to work around this. It makes the CSS unintuitive, necessitating comments all over the place.

Please have this fixed.

Comment 15

[Duan Yao]

If an element need both outline and box-shadow, the box-shadow workaround on SO can not be used. Currently I set box-shadow on the element and outline on its ::before to workaround this problem, however what if ::before must be used for other purpose? So please fix this issue.

Comment 16

[Karl Dubost💡 :karlcow]

Relevant specification 
https://drafts.csswg.org/css-ui/#outline-props

> The stacking of the rendering of these outlines is 
> explicitly left up to implementations to provide 
> a better user experience per platform. This supersedes 
> the stacking of outlines as defined in CSS 2.1.

And

> The rendering of applying transforms to outlines is 
> left explicitly undefined in CSS3-UI.

Example of Web compatibility issue because of outline
https://bugzilla.mozilla.org/show_bug.cgi?id=1214865

Comment 17

[Milan]

This bit us pretty hard. We have a large widget set where designers used outline and outline-offset to style controls and we develop a WYSIWYG editor that uses the controls. Everything looked visually correct deployed from the editor (using an embedded chromium instance) to latest Edge and Chrome.

Started testing Firefox more recently and found the outline behavior makes the panels visually unusable (elements with pop-up style components are added as children and the outline stretched around them unexpectedly). Switching to borders doesn't achieve the same effect we can create with outline + outline-offset and also as borders contribute to box model it complicates the WYSIWYG layout (many of the widgets are calculating sizes in JS inconsistently and changing to borders results in subtle misalignment in many places).

Comment 18

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

After bug 480888, I don't think we expand outlines for the *outlines* of descendant elements anymore.  We still do so for their border boxes, which is the right thing to do for focus outlines.

Comment 19

[markus]

This is a bug in my opinion. It should behave exactly like in chrome. Please fix it. I recently removed my outline of textfields and textarea elements because of this bug. I expected a behavior like in chrome.

Comment 20

[Yves Goergen [:ygoe]]

Oh, this bug is even officially listed in the compatibility matrix of the MDN docs page about the outline property (https://developer.mozilla.org/en-US/docs/Web/CSS/outline). Now I've got a problem. I can decide for Firefox or all other browsers. I can compensate for each, but not for both.

Because of this, and since this bug doesn't seem to be fixed anymore, I request an official CSS selector to distinguish Firefox from other browsers. Would that be possible? It's not what spec authors like, but I don't like buggy and incompatible implementations either. Be it a spec or implementation bug, I don't care, there is just no way to render things corectly in all browsers at once.

Comment 21

[Yves Goergen [:ygoe]]

Has this been fixed in Firefox 65? I see correct results in Firefox and Chrome with identical CSS code now. This definitely wasn't the case before.

Comment 22

[ken.sugiura]

Not sure if this should be considered a separate bug or not, but I noticed that if you apply an outline to a <button> element containing an element with display: inline-block, there will be a considerable gap between the outline and the border box. This also happens with other elements as well but the gap is much larger on buttons for some reason.

https://codepen.io/ksugi/pen/dybvpWG

I am using Firefox 68 and macOS 10.14.5

Comment 23

[Emilio Cobos Álvarez [:emilio]]

(In reply to Yves Goergen from comment #21)

Has this been fixed in Firefox 65? I see correct results in Firefox and Chrome with identical CSS code now. This definitely wasn't the case before.

We've done some changes so that we don't include out-of-flow descendants (i.e., position: absolute / fixed).

(In reply to ken.sugiura from comment #22)

Not sure if this should be considered a separate bug or not, but I noticed that if you apply an outline to a <button> element containing an element with display: inline-block, there will be a considerable gap between the outline and the border box. This also happens with other elements as well but the gap is much larger on buttons for some reason.

This is because buttons have baseline alignment by default. You can see that the button and div position is the same in Firefox and Blink, only difference is where the outline gets painted. So I'd say this is this issue.

I'd note that there was a fair bit of discussion in the CSS Working Group about this not that long ago, see https://github.com/w3c/csswg-drafts/issues/2846.

Comment 24

[ken.sugiura]

I did look through the default browser styles but couldn't find any that makes the button behave consistently with the divs. I tried setting -moz-appearance: none !important and vertical-align: top but they have no effect.

Comment 25

[Ole Strøm]

Big vote from me in making Firefox exclude absolutely positioned (and transformed!) elements from the outline.

Just spent my evening bashing my head against this, without finding any solution.

I'd say this should be fixed even before the CSS Working Group issue is resolved - an easy win for webcompat, as seemingly all the other browsers are excluding it.

Comment 26

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 3 duplicates and 10 votes.
:dholbert, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 27

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.