Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[selectors] :link and <link> #3817

Open
emilio opened this issue Apr 10, 2019 · 13 comments
Open

[selectors] :link and <link> #3817

emilio opened this issue Apr 10, 2019 · 13 comments

Comments

@emilio
Copy link
Collaborator

@emilio emilio commented Apr 10, 2019

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.

@AmeliaBR

This comment has been minimized.

Copy link
Contributor

@AmeliaBR AmeliaBR commented Apr 10, 2019

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

This comment has been minimized.

Copy link
Collaborator

@fantasai fantasai commented Apr 10, 2019

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

@fantasai

This comment has been minimized.

Copy link
Collaborator

@fantasai fantasai commented Apr 10, 2019

@fantasai

This comment has been minimized.

Copy link
Collaborator

@fantasai fantasai commented Apr 10, 2019

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.

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

This comment has been minimized.

Copy link
Contributor

@AmeliaBR AmeliaBR commented Apr 10, 2019

@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.

moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Apr 11, 2019
…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
mykmelez pushed a commit to mykmelez/gecko that referenced this issue Apr 11, 2019
…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

This comment has been minimized.

Copy link
Collaborator

@fantasai fantasai commented Apr 11, 2019

@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

This comment has been minimized.

Copy link
Contributor

@AmeliaBR AmeliaBR commented Apr 11, 2019

@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

This comment has been minimized.

Copy link
Collaborator

@fantasai fantasai commented Apr 12, 2019

@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

This comment has been minimized.

Copy link
Member

@tabatkins tabatkins commented Apr 24, 2019

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

This comment has been minimized.

Copy link
Collaborator Author

@emilio emilio commented Apr 25, 2019

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

This comment has been minimized.

Copy link
Collaborator Author

@emilio emilio commented Apr 25, 2019

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

This comment has been minimized.

Copy link

@rniwa rniwa commented Apr 25, 2019

@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

This comment has been minimized.

Copy link

@1jj 1jj commented Aug 9, 2019

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

gecko-dev-updater pushed a commit to marco-c/gecko-dev-comments-removed that referenced this issue Oct 4, 2019
…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
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified that referenced this issue Oct 4, 2019
…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
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified-and-comments-removed that referenced this issue Oct 4, 2019
…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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.