[selectors] :link and <link> #3817

emilio · 2019-04-10T13:50:52Z

Sorry for the issue title, it was just a good opportunity.

So, the following testcase:

<style>
  body { margin: 0 }
  a, head, link { display: block }
  a, link { width: 100px; height: 100px; background-color: red }
  :link { background-color: blue }
  :visited { background-color: purple }
</style>
<link href="unvisited"></a>
<link href="">
<a href="unvisited"></a>
<a href=""></a>

Renders as follows in UAs:

Firefox and WebKit: blue, purple, blue, purple
Edge: blue, blue, blue, purple
Blink: red, red, blue, purple

I think per spec (https://drafts.csswg.org/selectors-4/#location) Firefox and WebKit are right. However, I don't see any use-case for letting <link>s match :visited, and I have an internal use-case in Firefox where Blink or Edge's behavior would save us some trouble (https://bugzilla.mozilla.org/show_bug.cgi?id=1495621#c20).

Arguably that Firefox case can't arise in the web, and we can work around it in different ways, but I wonder if there'd be interest here in either making <link>s never match :visited, or making them not match any of :link / :visited / :any-link.

The text was updated successfully, but these errors were encountered:

AmeliaBR · 2019-04-10T15:34:22Z

I don't think there is any sensible definition of what it means for a <link> to be visited. E.g., is a <link rel="stylesheet"> visited once you download a stylesheet? That's the only "visited" state that makes sense for that type of link, but I doubt that's what the browsers are checking.

From a user perspective, it's also not very helpful for <link> to match :link, despite the names. A :link style is supposed to indicate to the user that I can activate this element to trigger a hyperlink navigation. And while an author may choose to render a <link> element with CSS, it doesn't make it a navigable hyperlink.

fantasai · 2019-04-10T18:44:55Z

@AmeliaBR LINK elements are used for things other than style sheets. For example, rel=next/prev.

fantasai · 2019-04-10T18:46:56Z

Also, this works, and creates a navigable link.

<!DOCTYPE html>
<html>
  <link title="Test" href="test" rel="next">
  <style>
    html, head, link { display: block; }
    link::before { content: "test"; }
  </style>

http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Chtml%3E%0A%20%20%3Clink%20title%3D%22Test%22%20href%3D%22test%22%20rel%3D%22next%22%3E%0A%20%20%3Cstyle%3E%0A%20%20%20%20html%2C%20head%2C%20link%20%7B%20display%3A%20block%3B%20%7D%0A%20%20%20%20link%3A%3Abefore%20%7B%20content%3A%20%22test%22%3B%20%7D%0A%20%20%3C%2Fstyle%3E

fantasai · 2019-04-10T18:48:49Z

Personally, I don't think it's reasonable to say that :link/:visited don't apply to LINK elements. They are hyperlinks, even if they're not visible by default. If browser don't want to deal with rendering them, they can specify link { display: none !important; } in their UA style sheet.

AmeliaBR · 2019-04-10T18:57:38Z

@fantasai I know about next/previous rel values, but I don't think it's specified anywhere that they should create navigable links if displayed. Neither Chrome nor pre-Chromium Edge turn your test case into a navigable link.

If there are use cases for turning a displayed <link> with certain rel values into a navigable hyperlink, like Firefox does, then an issue should be raised with HTML.

On this issue, my conclusion therefore is qualified based on the behavior: if force-displaying a <link> creates a navigable hyperlink, it should match :link and :any-link and :visited if appropriate. If it's not navigable, then it shouldn't match the pseudoclasses.

…in chrome docs. r=smaug I don't think there's a point in making <link> elements match :visited, and it's an issue for Chrome docs because some chrome code can run before we have a profile. Make the already-existent workaround for localization links work more generally. There's no interop across browsers here anyhow: w3c/csswg-drafts#3817 tracks that. Differential Revision: https://phabricator.services.mozilla.com/D26910 --HG-- extra : moz-landing-system : lando

…in chrome docs. r=smaug I don't think there's a point in making <link> elements match :visited, and it's an issue for Chrome docs because some chrome code can run before we have a profile. Make the already-existent workaround for localization links work more generally. There's no interop across browsers here anyhow: w3c/csswg-drafts#3817 tracks that. Differential Revision: https://phabricator.services.mozilla.com/D26910

fantasai · 2019-04-11T23:18:47Z

@AmeliaBR I don't understand why you think not rendering an element should make pseudo-classes not apply. Selectors aren't just about CSS. FWIW, the HTML spec is very explicit that they should match: https://html.spec.whatwg.org/multipage/semantics-other.html#pseudo-classes

AmeliaBR · 2019-04-11T23:52:11Z

@fantasai, I never said that selector matching should depend on whether the element renders or not. It's about whether the element (if it is rendered) actually acts like a link from a user perspective: can you click it, or tab to it and press enter, and trigger navigation.

Whether or not a <link> has this behavior seems to be the underlying discrepancy between browsers, and the styling differences fall out from that. I wouldn't want to ask browsers to harmonize their styling unless they first harmonize the behavior. And that's something for the HTML spec to clarify.

fantasai · 2019-04-12T22:48:29Z

@AmeliaBR The HTML spec doesn't need clarification, it's very explicit about whether :link and :visited match LINK elements. There is zero ambiguity here.

tabatkins · 2019-04-24T18:07:42Z

Zero ambiguity, sure. The argument, tho, is that the definition is wrong/useless, and I agree. Having :link apply to <link> doesn't seem like a useful behavior, and the fact that it then raises these questions of what it means for a <link> to be visited just makes it worse.

We should pursue changing the HTML definition so that :link only applies to <a>.

(In other words, a <link> can reasonably be argued to be neither visited nor unvisited; it doesn't have a "visited-ness" at all. Thus neither of :link nor :visited should apply (and neither should :any-link, then).)

emilio · 2019-04-25T12:11:10Z

I think as of http://trac.webkit.org/projects/webkit/changeset/244642 WebKit will also stop matching :visited on link elements.

@rniwa, do you know what's the reasoning for changing that?

emilio · 2019-04-25T12:12:30Z

I guess the not recomputing :visited could prevent privacy leaks, though you can always create a new <a> element?

Edit: Right, but that doesn't work. Nice.

rniwa · 2019-04-25T15:17:24Z

@emilio : oh, that's surprising. That's probably an unintentional change if any. FWIW, my testing at r244643 says WebKit still does blue, purple, blue, purple.

1jj · 2019-08-09T00:02:04Z

Arguably that Firefox case can't arise in the web,

Arguably it could be a real problem:
document.querySelectorAll(":link")[0] returns a <link> in Firefox and Safari and <a> in Chromium

…in chrome docs. r=smaug I don't think there's a point in making <link> elements match :visited, and it's an issue for Chrome docs because some chrome code can run before we have a profile. Make the already-existent workaround for localization links work more generally. There's no interop across browsers here anyhow: w3c/csswg-drafts#3817 tracks that. Differential Revision: https://phabricator.services.mozilla.com/D26910 UltraBlame original commit: e2a285801fb26598983b83b32fa3a44f1840c441

josepharhar · 2020-12-21T22:47:52Z

I'm implementing the pseudo selectors in blink which should make it have the same behavior as webkit: https://groups.google.com/a/chromium.org/g/blink-dev/c/l3Qw9cWYPUA

josepharhar · 2021-01-06T18:20:20Z

There is a discussion about removing link:link and link:visited here: whatwg/html#4831

domenic · 2021-01-19T20:33:47Z

I think this can be closed now that whatwg/html#6269 is merged.

emilio added selectors-4 Current Work selectors-5 labels Apr 10, 2019

fantasai added selectors-3 and removed selectors-5 labels Apr 10, 2019

emilio closed this as completed Jan 19, 2021

github-actions bot mentioned this issue Aug 4, 2021

Fixes #1634 - remove old compat site for Japanese mdn/translated-content#1900

Merged

This was referenced Oct 20, 2021

Firefox folder markdown prep mdn/content#9957

Merged

[DO NOT SQUASH MERGE] Firefox folder to markdown mdn/content#9981

Closed

[DO NOT SQUASH MERGE] firefox folder to markdown mdn/content#10074

Merged

github-actions bot mentioned this issue Aug 20, 2022

mozilla/firefox 以下を md に一括変換 mdn/translated-content#7835

Merged

github-actions bot mentioned this issue Jul 14, 2024

/mozilla/ 以下の表記ゆれの修正 mdn/translated-content#22095

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[selectors] :link and <link> #3817

[selectors] :link and <link> #3817

emilio commented Apr 10, 2019

AmeliaBR commented Apr 10, 2019

fantasai commented Apr 10, 2019

fantasai commented Apr 10, 2019 •

edited

Loading

fantasai commented Apr 10, 2019

AmeliaBR commented Apr 10, 2019

fantasai commented Apr 11, 2019 •

edited

Loading

AmeliaBR commented Apr 11, 2019

fantasai commented Apr 12, 2019 •

edited

Loading

tabatkins commented Apr 24, 2019

emilio commented Apr 25, 2019

emilio commented Apr 25, 2019 •

edited

Loading

rniwa commented Apr 25, 2019 •

edited

Loading

1jj commented Aug 9, 2019

josepharhar commented Dec 21, 2020

josepharhar commented Jan 6, 2021

domenic commented Jan 19, 2021

[selectors] :link and <link> #3817

[selectors] :link and <link> #3817

Comments

emilio commented Apr 10, 2019

AmeliaBR commented Apr 10, 2019

fantasai commented Apr 10, 2019

fantasai commented Apr 10, 2019 • edited Loading

fantasai commented Apr 10, 2019

AmeliaBR commented Apr 10, 2019

fantasai commented Apr 11, 2019 • edited Loading

AmeliaBR commented Apr 11, 2019

fantasai commented Apr 12, 2019 • edited Loading

tabatkins commented Apr 24, 2019

emilio commented Apr 25, 2019

emilio commented Apr 25, 2019 • edited Loading

rniwa commented Apr 25, 2019 • edited Loading

1jj commented Aug 9, 2019

josepharhar commented Dec 21, 2020

josepharhar commented Jan 6, 2021

domenic commented Jan 19, 2021

fantasai commented Apr 10, 2019 •

edited

Loading

fantasai commented Apr 11, 2019 •

edited

Loading

fantasai commented Apr 12, 2019 •

edited

Loading

emilio commented Apr 25, 2019 •

edited

Loading

rniwa commented Apr 25, 2019 •

edited

Loading