New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 605534 link

Starred by 3 users

Issue metadata

Status: Verified
Owner:
Last visit > 30 days ago
Closed: Jul 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug



Sign in to add a comment

Parsing of <body link vlink alink> is not per spec

Reported by sim...@opera.com, Apr 21 2016

Issue description

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/html/HTMLBodyElement.cpp&sq=package:chromium&type=cs&l=96

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)
 

Comment 1 by sim...@opera.com, Apr 21 2016

Cc: davve@opera.com

Comment 2 by sim...@opera.com, Apr 21 2016

(Same issue for WebKit: https://bugs.webkit.org/show_bug.cgi?id=156849 )
Labels: Hotlist-GoodFirstBug
Owner: dominicc@chromium.org
Status: Available (was: Untriaged)
Please feel free to poach.

I believe this is where we parse bgcolor:

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/html/HTMLElement.cpp&sq=package:chromium&type=cs&l=932&rcl=1461539842
I'd like to try fixing it.
OK, I would be happy to review your patch.

Comment 7 Deleted

Hi Dominic,
please have a look, I updated my patch some time ago and run all layout tests - seems to be no regressions.

Comment 10 by sim...@opera.com, Jul 4 2016

Status: Verified (was: Available)
Test cases work as expected in 54.0.2787.0 canary.

Sign in to add a comment