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)
Summary: WebKit resolves its initial `border-color` to either currentColor or to rgb(2...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: CSS (show other bugs)
Version: Safari 12
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: BrowserCompat, InRadar
Depends on:
Blocks:
 
Reported: 2019-02-25 13:38 PST by Daniel Holbert
Modified: 2022-08-20 16:24 PDT (History)
8 users (show)

See Also:


Attachments
testcase 1 (538 bytes, text/html)
2019-02-25 13:38 PST, Daniel Holbert
no flags Details
Safari 15.6.1 and STP 151 matches Chrome but differs from Firefox (536.30 KB, image/png)
2022-08-20 16:24 PDT, Ahmad Saleem
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Holbert 2019-02-25 13:38:01 PST
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.
Comment 1 Radar WebKit Bug Importer 2019-02-25 16:26:52 PST
<rdar://problem/48382464>
Comment 2 Ahmad Saleem 2022-08-20 16:24:21 PDT
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!