[css-ui] Outline rects of an inline

[emilio]

Context:

• Gecko used to include overflow areas in outlines, but we had to change to not do that in https://bugzilla.mozilla.org/show_bug.cgi?id=1739894, because some pages use text-indent: -9999px or so to hide text on some controls.
• Blink apparently special-cases inline boxes to include some amount of overflowing content. We got a report about this in https://bugzilla.mozilla.org/show_bug.cgi?id=1751574
• WebKit behaves like Gecko, and Blink's behavior is somewhat strange (see some of the test-cases in that bug).

So given that browsers are agreeing now to draw the outline around the border area, not including descendants, except for this Blink special-case, can we spec outline rects finally?

I think I'd prefer agreeing on the Gecko + WebKit behavior, since it's consistent with borders and outlines on all other boxes.

[css-meeting-bot]

The CSS Working Group just discussed [css-ui] Outline rects of an inline.

The full IRC log of that discussion

<emeyer> Topic: [css-ui] Outline rects of an inline
<emeyer> Github: https://github.com/w3c/csswg-drafts/issues/6981
<emeyer> emilio: When you have an outline around inlines, the spec was ambiguous about what an outline should draw around. We’ve changed Gecko to match WebKit, but missed a case where Blink does something different.
<emeyer> …There is a special code path for outlines of inlines. Can we resolve on what outline actually does and fully spec it?
<smfr> i’d love to see some pictuers in the issue
<emeyer> iank_: Does this cover auto outlines?
<emeyer> …I think engines have different code paths.
<emeyer> emilio: How do they differ?
<emeyer> smfr: What I remember is we only respect border radius for auto outlines.
<Rossen_> q
<Rossen_> ack emilio
<emeyer> iank_: I believe things differ for auto versus non-auto. If you have an inline block, we do something different to capture more of the visual overflow.
<emeyer> …The special case we had for non-auto outlines, I agree our behavior looks broken for one of the cases on the issue.
<emeyer> smfr: I’d love to see these and web platform tests.
<emeyer> iank_: I’ll try to create test cases where everyone does different things. I’ll be reluctant to change the auto outline case because of accessibility, but the non-auto outline case is difficult because people often force the outlines to be different.
<emeyer> emilio: I find the auto versus non-auto distinction quite weird. It should be about whether the element is focused. If we want to have focus outlines versus non-focus outlines, that’s another topic. But documenting the differences would be great, so we can agree on behavior.
<emeyer> Rossen: let’s take this back to the issue and create as many test cases as we can. I’ll +1 smfr’s suggestion to make the test cases WPT test cases.

[stylpe]

Came across this while experimenting with nice styling for multi-selectable cells in a sudoku grid. I made a demo here: https://observablehq.com/@supermikal/css-outline-rects-demo

The styles are a bit messy due to several iterations of trial and error, so it might not be a minimal repro but it's_something.jpg

Screenshot from Chrome for Android 98.0.4758.101:

Firefox for Android 97.2.0 (Build #2015863827), fc8bbf84c+ :

[MicahZoltu]

As a web developer, the behavior of Blink is surprising to me here. When I draw outside of the border box for some reason, I expect outline to draw around the border box and not around the stuff I drew outside of that box. My (potentially incorrect) understanding of outline is that it is similar to a border, but it doesn't consume space (thus making it a good tool for hover/focus as it won't trigger reflow like adding a border will).

The situation that caused me to spend a couple hours debugging was something like this:

<style>
my-element {
    outline: auto;
    outline-color: red;
    border: 1px solid blue;
    display: inline-flex;
    flex-direction: column;
}
my-element::after {
    height: 0;
    content: 'words';
    visibility: hidden;
}
</style>
<my-element>More Text</my-element>

In this example note that the ::after is invisible to both the user and the layout engine, yet the outline encapsulates it on Chromium browsers.

A potential middle ground that would address this specific issue would be to treat visibility: hidden the same as overflow: hidden, which causes the outline to ignore the overflow. Even with this change, I still feel like this behavior would be surprising to developers, but not quite as surprising as having outlines of empty boxes.

[pols12]

You may find some screenshots for this issue in MediaWiki.