[css-borders] 'border: 1px inset' is not interoperable

[zcorpan]

https://drafts.csswg.org/css-backgrounds/#line-style

See whatwg/html#2727 (comment)

I'd like to make the rendering of the hr element interoperable, but it appears there is lack of interoperability for CSS inset borders.

Which behavior should browsers converge on?

[mstensho]

https://www.w3.org/TR/CSS22/box.html#border-style-properties has a section about certain style values, among those "inset":

"All borders are drawn on top of the box's background. The color of borders drawn for values of 'groove', 'ridge', 'inset', and 'outset' depends on the element's border color properties, but UAs may choose their own algorithm to calculate the actual colors used. For instance, if the 'border-color' has the value 'silver', then a UA could use a gradient of colors from white to dark gray to indicate a sloping border."

Of course, border-color is just color initially, but maybe this paragraph is what caused confusion. I've done some digging in Blink now, and we have this interesting passage in ComputedStyle.cpp:

  // FIXME: Treating styled borders with initial color differently causes
  // problems, see crbug.com/316559, crbug.com/276231
  if (!visited_link && (border_style == EBorderStyle::kInset ||
                        border_style == EBorderStyle::kOutset ||
                        border_style == EBorderStyle::kRidge ||
                        border_style == EBorderStyle::kGroove))
    return Color(238, 238, 238);

[mstensho]

This is very old code, and it's in WebKit's initial commit from August 2001:

void RenderObject::drawBorder(QPainter *p, int x1, int y1, int x2, int y2,
                              BorderSide s, QColor c, const QColor& textcolor, EBorderStyle style,
                              int adjbw1, int adjbw2, bool invalidisInvert)
{
    int width = (s==BSTop||s==BSBottom?y2-y1:x2-x1);

    if(style == DOUBLE && width < 3)
        style = SOLID;

    if(!c.isValid()) {
        if(invalidisInvert)
        {
            p->setRasterOp(Qt::XorROP);
            c = Qt::white;
        }
        else {
            if(style == INSET || style == OUTSET || style == RIDGE || style ==
	    GROOVE)
                c.setRgb(238, 238, 238);
            else
                c = textcolor;
        }
    }

[mstensho]

Oh, even a patch (abandoned?): https://codereview.chromium.org/2394383002/

[fantasai]

Agenda+ to ask for feedback from other implementers, and also to determine whether this goes in L3 or L4. (Probably L4 unless there is fast traction on resolving and implementing it.)

[css-meeting-bot]

The Working Group just discussed 'border: 1px inset' is not interoperable.

The full IRC log of that discussion

<dael> Topic: 'border: 1px inset' is not interoperable
<dael> github: https://github.com//issues/1489
<dael> Rossen_: Is zcorpan on?
<dael> [silence]
<dael> fantasai: I can prob take this
<dael> fantasai: basically the inset and outset borders we don't define what color they should be. This is resulting in non-interop, esp. on 1px. Do we want to work on aligning and, if yes, do we try and do this in L3 or L4?
<tantek> L4 please
<dael> fantasai: I don't think we can resolve on the result, but figuring out where to put this work would help me agenda set.
<dael> Rossen_: Fair.
<tantek> unless someone has citations of real world sites where people are complaining
<tantek> and in which case, seriously, 1px inset/outside/ridge etc. border?!? why?!?
<dael> Rossen_: For the impl would this besomething high on your list of things to fix if we were to agree? Or will this be low priority?
<tantek> silence = low
<dael> Rossen_: I'mgoing to take silence as it being low priority.
<tantek> hah
<dael> Rossen_: As an impl I would say this is low priority for us. We have no had any reports of issues b/c of this. I don't see us rushing this.
<dael> Rossen_: One more call.
<dael> Rossen_: If no one raises urgency I propose L4.
<dael> Rossen_: So this is the call. If you're an impl and want to rush an interop fix, now is the time.
<tantek> if Edge is still using the Trident border style rendering code which was ported from Tasman, then I'd say that's a good default if you want to specify something in L4 :)
<bradk> Wait for L4
<dael> Rossen_: Okay, let's take this to L4. fantasai Is this specific to 1px or inset in general?
<dael> fantasai: I'm not sure.
<dael> florian: From bug it looks like there's a general problem and it's worse at 1px. We need to dig into details.
<tantek> I want to know what is the use-case for these odd 1px border-styles
<dael> Rossen_: Okay. Again, I don't htink we can push inset to L4.
<tantek> seriously why are people doing them? what effect do they expect?
<dael> fantasai: The spec has a not-specific statement as to what the color should be, but no formula. All impl are spec complient.
<tantek> yes that's deliberately vague to capture what implementations did in the late 1990s / early 2000s
<dael> Rossen_: Okay. Let's close saying if there are any more restrictive spec changes that have to be made in terms of inset and color computation, they would go in L4. Obj?
<dael> tantek: I'd want a use case. Why are you doing this? for what effect.
<dael> fantasai: THe default rendering of hr to be consistant?
<bradk> Inset borders are not in vogue anyway
<dael> tantek: Why?
<dael> fantasai: Don't know.
<dael> tantek: That's why I want it documented. I'd prefer an explicit statement saying we don't know why to do this. Most things we do with a use case for what's trying to be achieved. You're just making work without a use case
<astearns> the effect we're looking to achieve is interoperability in an existing feature
<dael> Rossen_: Fair point.
<dael> Rossen_: Your point will me in github. If we ever come back to this we'll have to call for use cases and then revisit. Fair to you?
<dael> tantek: Yeah.
<dael> Rossen_: Anything else?
<dael> fantasai: That's it.

[fantasai]

Hi, the CSSWG just discussed this and agreed to defer resolving this issue until L4, since L3 is quite far stabilized.

In addition, there was a request for use cases / evidence of existing problems, to justify doing this synchronization work and to help prioritize accordingly, since slight differences in color on a rarely-used border style are unlikely to make or break a website.