Bug 195015 – WebKit resolves its initial `border-color` to either currentColor or to rgb(238,238,238), depending on `border-style` (for td and th elements)

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: CSS

[Daniel Holbert]

Created attachment 362924 [details]
testcase 1

(This is a bug that Blink & WebKit have mostly in common -- blink version of the bug is at https://bugs.chromium.org/p/chromium/issues/detail?id=935708 )

STR:
 1. Load https://jsfiddle.net/Lhcswgp8/

EXPECTED RESULTS:
The borders should all have the same color (aside from some minor shading for inset/outset).  They should all be teal, via `color:teal` and via `border-color` having an initial value of `currentColor`.

ACTUAL RESULTS:
The inset/outset-styled borders are a grayish color instead. Specifically, they are rgb(238, 238, 238) as you can see if you inspect the cell in devtools and examine its computed `border-top-color` value.

So it seems WebKit has `border-color: $MAGIC`, where $MAGIC resolves to `currentColor` for some border-styles and to rgb(238, 238, 238) for other border-styles.

Chrome has a version of the same bug --though for Chrome, "$MAGIC" is just the "currentColor" keyword itself. (i.e. Chrome exhibits the bug even if I manually specify `border-color:currentColor`, unlike WebKit where the bug goes away if I do that.)


Note: technically the WHATWG spec requires that these elements have `border-color:gray` (which is rgb(128,128,128), but no engine (not even WebKit) does that.  For these td/th elements...
 - Firefox 65, Edge 18, and IE11 all use `border-color: currentColor` and produce the expected results.
 - Chrome 72 uses `border-color: currentColor` but then has some magic behavior which depends on the border-style.
 - WebKit (Safari 12) seems to have a magic default value for `border-color` which has magic behavior that either resolves to `currentColor`, or an extremely light shade of gray (with 238 in each color channel, rather than 128, as noted above).

So I've filed https://github.com/whatwg/html/issues/4391 to update the WHATWG spec to remove this rule that nobody follows.

[Radar WebKit Bug Importer]

<rdar://problem/48382464>

[Ahmad Saleem]

Created attachment 461774 [details]
Safari 15.6.1 and STP 151 matches Chrome but differs from Firefox

I am not sure on web-spec aligned behavior but Safari 15.6.1 and STP 151 matches with Chrome Canary 106 but differ from Firefox Nightly 105, please refer to attached screenshot. Just updating testing results. Thanks!

[Ahmad Saleem]

Created attachment 472588 [details]
STP 203 - now closely matching Firefox

[Ahmad Saleem]

@Tim - if I am not mistaken, you fixed this in the past in different bug.

Do we need to track further for slight color difference or we can close this?

[Daniel Holbert]

Thanks for the update! FWIW this looks fixed from my perspective.  Bisecting among versions available to me on BrowserStack, it looks like it was fixed in this range:
* Safari 16.5 is "bad"
* Safari 17.3 is "good"

> Do we need to track further for slight color difference or we can close this?

I don't think this is an issue -- slight color differences between implementations are allowed here.  In the testcase here, the color differences are in the `border-style:inset` and `outset` sections, where the CSS Backgrounds and Borders spec just says to apply an effect that "Looks as if the content on the inside of the border is sunken into the canvas." (or raised out of the canvas).  This involves some color darkening/lightening which I don't think is specified anywhere and where engines are free to diverge.

Spec reference:
https://drafts.csswg.org/css-backgrounds/#valdef-line-style-inset

[Tim Nguyen (:ntim)]

*** This bug has been marked as a duplicate of bug 258725 ***