Created attachment 466364 [details] testcase 1 This issue affects both Chromium and WebKit. The Chromium version of this bug report is https://bugs.chromium.org/p/chromium/issues/detail?id=1446014 STR: 1. View attached testcase. EXPECTED RESULTS: The first table should have no border (just like the second one). ACTUAL RESULTS: The first table does have a blue border. The first and second tables both set the color of the border, but don't explicitly activate the border using the `border` attribute or the `border-style` property, which is why the border should not render. The problematic first table here is just <table bordercolor="blue">. Per the html spec at https://html.spec.whatwg.org/multipage/rendering.html#tables-2 , the browser is supposed to "treat the [bordercolor] attribute as a presentational hint setting the element's 'border-top-color', 'border-right-color', 'border-bottom-color', and 'border-left-color' properties to the resulting color." If that were what WebKit were doing, then it would render that table the same as the second one, with no border. Firefox gives expected results here. So does EdgeHTML (pre-Chromium Edge). Chromium and WebKit give "actual results". I suspect this is a webkit-ism that predated the Blink fork.
Created attachment 466373 [details] rendering in safari, firefox, chrome Tested on macOS 13.4 --- Safari Technology Preview 169 18616.1.12.2 Firefox Nightly 115.0a1 11523.5.10 Google Chrome Canary 115.0.5762.0 5762.0
Thanks Daniel!
<rdar://problem/109436009>
In the case of bordercolor="blue" WebKit assigns: border-right-color: rgb(0, 0, 255); border-right-style: solid; border-right-width: 3px; In the case of style="border-color: blue" WebKit assigns: border-right-color: rgb(0, 0, 255); border-right-style: none; border-right-width: 0px;
Hi Karl - thanks for taking a look! I've got a patch posted on https://phabricator.services.mozilla.com/D178487 to add a WPT to test this, tentatively at this path in the WPT directory (once it gets merged around): `html/rendering/non-replaced-elements/tables/table-bordercolor-001.html`
Part of the WebKit code is at https://searchfox.org/wubkat/rev/622bd3bfe173b244d3cc68f2cb14ebbf987e14dd/Source/WebCore/html/HTMLTableElement.cpp#320-323 https://searchfox.org/wubkat/rev/622bd3bfe173b244d3cc68f2cb14ebbf987e14dd/Source/WebCore/html/HTMLTableElement.cpp#462-483
Pull request: https://github.com/WebKit/WebKit/pull/14060
Daniel, could you test with Firefox https://github.com/WebKit/WebKit/blob/main/LayoutTests/fast/table/border-changes.html https://github.com/WebKit/WebKit/blob/main/LayoutTests/tables/mozilla/bugs/bug1163-1.html https://github.com/WebKit/WebKit/blob/main/LayoutTests/tables/mozilla/bugs/bug131020.html https://github.com/WebKit/WebKit/blob/main/LayoutTests/tables/mozilla/bugs/bug131020_iframe.html I'm in the process of adjusting the test, but I want to make extra-sure, that we are adjusting the right thing on both sides.
PR for the new test on WPT https://github.com/web-platform-tests/wpt/pull/40088 (not landed yet)
Created attachment 466423 [details] Firefox's test results from WebKit test LayoutTests/fast/table/border-changes.html (In reply to Karl Dubost from comment #8) > Daniel, could you test with Firefox Sure -- for what it's worth, I'm testing with `python3 -m http.server 8888` run in a git checkout of WebKit, and then I'm loading e.g. http://localhost:8888/LayoutTests/fast/table/border-changes.html > https://github.com/WebKit/WebKit/blob/main/LayoutTests/fast/table/border-changes.html Results attached. > https://github.com/WebKit/WebKit/blob/main/LayoutTests/tables/mozilla/bugs/bug1163-1.html > https://github.com/WebKit/WebKit/blob/main/LayoutTests/tables/mozilla/bugs/bug131020.html > https://github.com/WebKit/WebKit/blob/main/LayoutTests/tables/mozilla/bugs/bug131020_iframe.html Firefox does render the specified bordercolor in all of these cases, because `border` is specified on the table (though we do so with a beveled look which changes the color's darkness a bit).
Committed 265670@main (9311f46770ba): <https://commits.webkit.org/265670@main> Reviewed commits have been landed. Closing PR #14060 and removing active labels.
*** Bug 19681 has been marked as a duplicate of this bug. ***