(Same issue for Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=605534 ) https://github.com/WebKit/webkit/blob/66e68cd8d7bf4ea1cf52f31ed9cb242f83ea5b57/Source/WebCore/html/HTMLBodyElement.cpp#L159 This code does not match the requirements in the HTML spec: [[ When a body element has a bgcolor attribute set, the new value is expected to be parsed using the rules for parsing a legacy colour value, and if that does not return an error, the user agent is expected to treat the attribute as a presentational hint setting the element's 'background-color' property to the resulting colour. When a body element has a text attribute, its value is expected to be parsed using the rules for parsing a legacy colour value, and if that does not return an error, the user agent is expected to treat the attribute as a presentational hint setting the element's 'color' property to the resulting colour. When a body element has a link attribute, its value is expected to be parsed using the rules for parsing a legacy colour value, and if that does not return an error, the user agent is expected to treat the attribute as a presentational hint setting the 'color' property of any element in the Document matching the :link pseudo-class to the resulting colour. When a body element has a vlink attribute, its value is expected to be parsed using the rules for parsing a legacy colour value, and if that does not return an error, the user agent is expected to treat the attribute as a presentational hint setting the 'color' property of any element in the Document matching the :visited pseudo-class to the resulting colour. When a body element has an alink attribute, its value is expected to be parsed using the rules for parsing a legacy colour value, and if that does not return an error, the user agent is expected to treat the attribute as a presentational hint setting the 'color' property of any element in the Document matching the :active pseudo-class and either the :link pseudo-class or the :visited pseudo-class to the resulting colour. ]] https://html.spec.whatwg.org/multipage/rendering.html#the-page It seems we use the correct rules for bgcolor (on various elements, and <font color>, <table bordercolor>, <hr color>) and text but not the link/vlink/alink attributes on body. This should also not be conditional on quirks mode. Gecko matches the spec AFAICT. Simple tests: <!doctype html> <body bgcolor="00ff0x">This should have a green background. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4091 bgcolor --- <!doctype html> <body link="00800x"><a href=javascript:>This text should be green. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4092 link (standards mode) --- <!doctype html> <body link="00800x"><a href=javascript:>This text should be green. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4093 link (quirks mode) --- <body link="008000"><a href=javascript:>This text should be green. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4094 link (quirks mode, using a value we successfully parse today)
I am fixing it for chromium (https://codereview.chromium.org/1921823006/) - will port the fix here as well.
I am still able to reproduce this bug in Safari 15.6 on macOS 12.5 from following test cases: http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4092 http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4093 Further, this has been fixed in Chrome in following commit: https://chromium.googlesource.com/chromium/src.git/+/ac6c480c0c078999a785de7ef1e10c6c0c928c75 I think this might be linked to bug 61697?
Pull request: https://github.com/WebKit/WebKit/pull/2883
Committed 252992@main (c521422a249b): <https://commits.webkit.org/252992@main> Reviewed commits have been landed. Closing PR #2883 and removing active labels.
<rdar://problem/97886718>