Intent to Implement and Ship: Link element pseudo selectors

Joey Arhar

unread,

Dec 17, 2020, 7:57:08 PM12/17/20

to blink-dev

Contact emails

jar...@chromium.org

Explainer

None

Specification

https://drafts.csswg.org/selectors-4/#the-any-link-pseudo

API spec

Yes

Summary

This feature adds support for the :link, :visited, and :any-link pseudo selectors for <link> elements. Without this feature, <link> elements will never match for these pseudo selectors. With this feature, <link> elements will always match for :any-link and may match :link and :visited when they apply.

This feature has already been implemented in Firefox and Safari, it has already been specced, and there are already WPTs for it.

Blink component

Blink>HTML

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

This feature could break websites which expect these pseudo selectors to never match link elements. However, since Safari and Firefox have already implemented this feature, I don't think it will be a problem.

Gecko: Shipped/Shipping

WebKit: Shipped/Shipping

Web developers: No signals

Is this feature fully tested by web-platform-tests?

Yes

https://wpt.fyi/results/dom/nodes/ParentNode-querySelector-All.html
https://wpt.fyi/results/dom/nodes/ParentNode-querySelector-All-xht.xht
https://wpt.fyi/results/dom/nodes/Element-webkitMatchesSelector.html
https://wpt.fyi/results/dom/nodes/Element-matches.html
https://wpt.fyi/results/html/semantics/selectors/pseudo-classes/link.html

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=611093

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4784885279490048

This intent message was generated by Chrome Platform Status.

Joey Arhar

unread,

Dec 21, 2020, 11:47:53 AM12/21/20

to Šime Vidas, blink-dev

> Could you give an example of how this feature would be used? <link> elements are not rendered, so why would you style them?

You have a good point, I'm not aware of any reason why you would want to style <link> elements. As far as I can tell, this would only make a difference when using querySelector/querySelectorAll.

However, I still think this is worth implementing because:

1. It is specced to include <link> elements

2. Firefox and Safari already include <link> elements

3. MDN and other documentation say that <link> elements are included

On Sat, Dec 19, 2020 at 8:07 AM Šime Vidas <sime....@gmail.com> wrote:

Could you give an example of how this feature would be used? <link> elements are not rendered, so why would you style them?

Emilio Cobos Álvarez

unread,

Dec 21, 2020, 4:04:54 PM12/21/20

to Joey Arhar, blink-dev

Do you plan to honor `:visited`? See [1]

[1]: https://github.com/w3c/csswg-drafts/issues/3817

-- Emilio

On 12/18/20 1:56 AM, Joey Arhar wrote:
>
> Contact emails
>

> jar...@chromium.org <mailto:jar...@chromium.org>

>
>
> Explainer
>
> None
>
>
> Specification
>
> https://drafts.csswg.org/selectors-4/#the-any-link-pseudo
> <https://drafts.csswg.org/selectors-4/#the-any-link-pseudo>
>
>
> API spec
>
> Yes
>
>
> Summary
>
> This feature adds support for the :link, :visited, and :any-link pseudo
> selectors for <link> elements. Without this feature, <link> elements
> will never match for these pseudo selectors. With this feature, <link>
> elements will always match for :any-link and may match :link and
> :visited when they apply.
>
>
> This feature has already been implemented in Firefox and Safari, it has
> already been specced, and there are already WPTs for it.
>
>
> Blink component
>
> Blink>HTML

> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EHTML>

>
>
> TAG review
>
> None
>
>
> TAG review status
>
> Not applicable
>
>
> Risks
>
>
>
> Interoperability and Compatibility
>
> This feature could break websites which expect these pseudo selectors to
> never match link elements. However, since Safari and Firefox have
> already implemented this feature, I don't think it will be a problem.
>
>
>
> Gecko: Shipped/Shipping
>
> WebKit: Shipped/Shipping
>
> Web developers: No signals
>
>
> Is this feature fully tested by web-platform-tests

> <https://wpt.fyi/results/html/semantics/selectors/pseudo-classes/link.html>
>
>
> Tracking bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=611093
> <https://bugs.chromium.org/p/chromium/issues/detail?id=611093>
>
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/4784885279490048
> <https://chromestatus.com/feature/4784885279490048>
>
> This intent message was generated by Chrome Platform Status

> <https://www.chromestatus.com/>.
>
> --
> You received this message because you are subscribed to the Google
> Groups "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to blink-dev+...@chromium.org
> <mailto:blink-dev+...@chromium.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwKVPb601NpjyT5FbQSQxFsHUMMptme-Wj2-Wn%3DJyDJygw%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwKVPb601NpjyT5FbQSQxFsHUMMptme-Wj2-Wn%3DJyDJygw%40mail.gmail.com?utm_medium=email&utm_source=footer>.

Joey Arhar

unread,

Dec 21, 2020, 5:48:10 PM12/21/20

to Emilio Cobos Álvarez, blink-dev

> Do you plan to honor `:visited`? See [1]
>
> [1]: https://github.com/w3c/csswg-drafts/issues/3817

Thanks for sharing this!

I didn't know you could render <link>s like that.

After tinkering with the html you provided in that github issue, which I have attached to this email, I found that my implementation will support link:visited like Safari.

Based on the html file, it looks like firefox doesn't support link:visited... are you getting the same results?

I'm open to removing link:visited or any other behavior if a conclusion is reached in https://github.com/w3c/csswg-drafts/issues/3817

link.html

Šime Vidas

unread,

Dec 21, 2020, 7:16:48 PM12/21/20

to blink-dev, Joey Arhar

Could you give an example of how this feature would be used? <link> elements are not rendered, so why would you style them?

On Friday, December 18, 2020 at 1:57:08 AM UTC+1 Joey Arhar wrote:

Emilio Cobos Álvarez

unread,

Dec 22, 2020, 12:11:57 AM12/22/20

to Joey Arhar, blink-dev

On 12/21/20 11:47 PM, Joey Arhar wrote:
> > Do you plan to honor `:visited`? See [1]
> >
> > [1]: https://github.com/w3c/csswg-drafts/issues/3817

> <https://github.com/w3c/csswg-drafts/issues/3817>
>
> Thanks for sharing this!
> I didn't know you could render <link>s like that.
> After tinkering with the html you provided in that github issue, which I
> have attached to this email, I found that my implementation will support
> link:visited like Safari.
> Based on the html file, it looks like firefox doesn't support
> link:visited... are you getting the same results?

It's more subtle than that. Yeah, I changed Firefox's behavior in [1],
which is what triggered that issue.

I think Safari generally doesn't support link:visited. I think they just
have an special-case for the empty href which is silly, see [2].

So I think either old or new Firefox behavior (i.e., either actually
support link:visited, or don't support it, respectively) are preferable,
because I don't see why the empty href special-case would be desirable.

-- Emilio

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1572246
[2]: https://crisal.io/tmp/link-visited.html

> I'm open to removing link:visited or any other behavior if a conclusion
> is reached in https://github.com/w3c/csswg-drafts/issues/3817
> <https://github.com/w3c/csswg-drafts/issues/3817>
>
> On Mon, Dec 21, 2020 at 1:04 PM Emilio Cobos Álvarez <emi...@mozilla.com
> <mailto:emi...@mozilla.com>> wrote:
>
> Do you plan to honor `:visited`? See [1]
>
> [1]: https://github.com/w3c/csswg-drafts/issues/3817
> <https://github.com/w3c/csswg-drafts/issues/3817>
>
> -- Emilio
>
> On 12/18/20 1:56 AM, Joey Arhar wrote:
> >
> > Contact emails
> >
> > jar...@chromium.org <mailto:jar...@chromium.org>

> <mailto:jar...@chromium.org <mailto:jar...@chromium.org>>

> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>>?

> > <https://www.chromestatus.com/ <https://www.chromestatus.com/>>.

> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "blink-dev" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send
> > an email to blink-dev+...@chromium.org

> <mailto:blink-dev%2Bunsu...@chromium.org>
> > <mailto:blink-dev+...@chromium.org
> <mailto:blink-dev%2Bunsu...@chromium.org>>.

> > To view this discussion on the web visit
> >
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwKVPb601NpjyT5FbQSQxFsHUMMptme-Wj2-Wn%3DJyDJygw%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwKVPb601NpjyT5FbQSQxFsHUMMptme-Wj2-Wn%3DJyDJygw%40mail.gmail.com>
>
> >

> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwKVPb601NpjyT5FbQSQxFsHUMMptme-Wj2-Wn%3DJyDJygw%40mail.gmail.com?utm_medium=email&utm_source=footer
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwKVPb601NpjyT5FbQSQxFsHUMMptme-Wj2-Wn%3DJyDJygw%40mail.gmail.com?utm_medium=email&utm_source=footer>>.
>

Emilio Cobos Álvarez

unread,

Dec 22, 2020, 12:15:54 AM12/22/20

to blin...@chromium.org

On 12/22/20 6:11 AM, Emilio Cobos Álvarez wrote:
> On 12/21/20 11:47 PM, Joey Arhar wrote:
>> > Do you plan to honor `:visited`? See [1]
>> >
>> > [1]: https://github.com/w3c/csswg-drafts/issues/3817
>> <https://github.com/w3c/csswg-drafts/issues/3817>
>>
>> Thanks for sharing this!
>> I didn't know you could render <link>s like that.
>> After tinkering with the html you provided in that github issue, which
>> I have attached to this email, I found that my implementation will
>> support link:visited like Safari.
>> Based on the html file, it looks like firefox doesn't support
>> link:visited... are you getting the same results?
>
> It's more subtle than that. Yeah, I changed Firefox's behavior in [1],
> which is what triggered that issue.
>
> I think Safari generally doesn't support link:visited. I think they just
> have an special-case for the empty href which is silly, see [2].
>
> So I think either old or new Firefox behavior (i.e., either actually
> support link:visited, or don't support it, respectively) are preferable,
> because I don't see why the empty href special-case would be desirable.

See also https://github.com/whatwg/html/issues/4831, which I didn't find
before.

Joey Arhar

unread,

Dec 22, 2020, 8:03:32 PM12/22/20

to Emilio Cobos Álvarez, blink-dev

> It's more subtle than that. Yeah, I changed Firefox's behavior in [1],
> which is what triggered that issue.
>
> I think Safari generally doesn't support link:visited. I think they just
> have an special-case for the empty href which is silly, see [2].
>
> So I think either old or new Firefox behavior (i.e., either actually
> support link:visited, or don't support it, respectively) are preferable,
> because I don't see why the empty href special-case would be desirable.
>

> -- Emilio
>
> [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1572246
> [2]: https://crisal.io/tmp/link-visited.html

Thanks for the improved example! I see that href="" is a special case now.

With my patch, chrome will have the same behavior as safari.

Below is a screenshot with left to right: Firefox, Safari, Chrome, and Chrome with my patch.

It would seem that neither Firefox nor Safari supports link:visited except for safari supporting the href="" case, as you mentioned in this comment.

I could drop link:visited since it would technically be closer to what Firefox and Safari are doing. What do you think?

Screen Shot 2020-12-22 at 4.15.38 PM.png

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/37391555-9521-56e7-e2f0-c72abeb4a055%40crisal.io.

Emilio Cobos Álvarez

unread,

Jan 2, 2021, 9:05:29 PM1/2/21

to Joey Arhar, blink-dev

On 12/23/20 2:03 AM, Joey Arhar wrote:
> > It's more subtle than that. Yeah, I changed Firefox's behavior in [1],
> > which is what triggered that issue.
> >
> > I think Safari generally doesn't support link:visited. I think they just
> > have an special-case for the empty href which is silly, see [2].
> >
> > So I think either old or new Firefox behavior (i.e., either actually
> > support link:visited, or don't support it, respectively) are preferable,
> > because I don't see why the empty href special-case would be desirable.
> >
> > -- Emilio
> >
> > [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1572246
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1572246>
> > [2]: https://crisal.io/tmp/link-visited.html
> <https://crisal.io/tmp/link-visited.html>
>
> Thanks for the improved example! I see that href="" is a special case now.
> With my patch, chrome will have the same behavior as safari.
> Below is a screenshot with left to right: Firefox, Safari, Chrome, and
> Chrome with my patch.
> It would seem that neither Firefox nor Safari supports link:visited
> except for safari supporting the href="" case, as you mentioned in this
> comment

> <https://github.com/w3c/csswg-drafts/issues/3817#issuecomment-486646291>.

> I could drop link:visited since it would technically be closer to what
> Firefox and Safari are doing. What do you think?

Sorry for the lag (was on vacation). I think reducing the scope of
:visited is worth it, because it has caused so much security trouble
over the years.

As I mentioned in[1] I think it's sensible to try to align other
browsers with Chrome here rather than the other way around, but if
Chrome is going to support :link on <link> elements, that is also an
improvement on interop and I'd be ok just closing that issue as WONTFIX
and carrying on :)

Curious, does your patch also make <link> elements behave like actual
links (so, making them able to navigate on click, etc)? I think that's
what the spec asks for, which is what Firefox does. IIRC WebKit doesn't
do that.

[1]: https://github.com/whatwg/html/issues/4831

> <https://github.com/whatwg/html/issues/4831>, which I didn't find

> before.
>
> -- Emilio
>
> > [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1572246

> <https://bugzilla.mozilla.org/show_bug.cgi?id=1572246>
> > [2]: https://crisal.io/tmp/link-visited.html

> <https://crisal.io/tmp/link-visited.html>
> >
> >> I'm open to removing link:visited or any other behavior if a
> >> conclusion is reached in
> >> https://github.com/w3c/csswg-drafts/issues/3817
> <https://github.com/w3c/csswg-drafts/issues/3817>
> >> <https://github.com/w3c/csswg-drafts/issues/3817
> <https://github.com/w3c/csswg-drafts/issues/3817>>
> >>
> >> On Mon, Dec 21, 2020 at 1:04 PM Emilio Cobos Álvarez
> >> <emi...@mozilla.com <mailto:emi...@mozilla.com>

> <https://www.chromestatus.com/> <https://www.chromestatus.com/

> <https://www.chromestatus.com/>>>.
> >>      >
> >>      > --
> >>      > You received this message because you are subscribed to
> the Google
> >>      > Groups "blink-dev" group.
> >>      > To unsubscribe from this group and stop receiving emails
> from it,
> >>     send
> >>      > an email to blink-dev+...@chromium.org
> <mailto:blink-dev%2Bunsu...@chromium.org>

> >>     <mailto:blink-dev%2Bunsu...@chromium.org
> <mailto:blink-dev%252Buns...@chromium.org>>
> >>      > <mailto:blink-dev+...@chromium.org
> <mailto:blink-dev%2Bunsu...@chromium.org>
> >>     <mailto:blink-dev%2Bunsu...@chromium.org
> <mailto:blink-dev%252Buns...@chromium.org>>>.

> send an email to blink-dev+...@chromium.org

> <mailto:blink-dev%2Bunsu...@chromium.org>.
> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/37391555-9521-56e7-e2f0-c72abeb4a055%40crisal.io
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/37391555-9521-56e7-e2f0-c72abeb4a055%40crisal.io>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to blink-dev+...@chromium.org

> <mailto:blink-dev+...@chromium.org>.

> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwKV9ataH-aZ84a0wPG-wxkWeFEEDZUX3yWbTMDyH%2B8Ydg%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwKV9ataH-aZ84a0wPG-wxkWeFEEDZUX3yWbTMDyH%2B8Ydg%40mail.gmail.com?utm_medium=email&utm_source=footer>.

Camille Lamy

unread,

Jan 6, 2021, 5:19:59 AM1/6/21

to blink-dev, Emilio Cobos Alvarez, blink-dev, Joey Arhar

From a security perspective, we were worried that the privacy restrictions around :visited that we have in the implementation for <a> elements would be properly applied to <link> elements as well., in particular the restrictions around accessing the computed style from JavaScript. It would be good to ensure there are WPTs for this in particular, if they don't exist already.

Yoav Weiss

unread,

Jan 6, 2021, 5:43:18 AM1/6/21

to Camille Lamy, Domenic Denicola, blink-dev, Emilio Cobos Alvarez, Joey Arhar

A few points:

1) Thanks for striving to improve interop here! :)

2) It's not clear to me that there's an actual web developer need for applying :link to HTMLLinkElements. It seems better to improve the interop state by simplifying other implementations and the spec, as Emilio and +Domenic Denicola suggested, and as Emilio seems willing to do for Firefox.

3) If we choose to implement :link for HTMLLinkElement, I'd strongly object to expanding :visited to it as well. IMO, we should remove that cross-origin cache state, not expand it.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/46f92808-c420-401b-85d4-f506474b9dc2n%40chromium.org.

Joey Arhar

unread,

Jan 6, 2021, 1:18:54 PM1/6/21

to Yoav Weiss, Camille Lamy, Domenic Denicola, blink-dev, Emilio Cobos Alvarez

Thanks for the feedback!

> Curious, does your patch also make <link> elements behave like actual links (so, making them able to navigate on click, etc)?

No, it only adds the pseudo selectors.

> I think reducing the scope of :visited is worth it, because it has caused so much security trouble over the years.

> From a security perspective, we were worried that the privacy restrictions around :visited that we have in the implementation for <a> elements would be properly applied to <link> elements as well., in particular the restrictions around accessing the computed style from JavaScript. It would be good to ensure there are WPTs for this in particular, if they don't exist already.

> If we choose to implement :link for HTMLLinkElement, I'd strongly object to expanding :visited to it as well.

It sounds like we definitely shouldn't do link:visited. When you mentioned WPTs, are you saying there should be WPTs which say that :visited can't ever be applied to <link>s?

> It's not clear to me that there's an actual web developer need for applying :link to HTMLLinkElements. It seems better to improve the interop state by simplifying other implementations and the spec, as Emilio and +Domenic Denicola suggested, and as Emilio seems willing to do for Firefox.

Sounds good to me, I'm happy to hold off on this while a decision is made in that spec issue.

Camille Lamy

unread,

Jan 13, 2021, 8:38:27 AM1/13/21

to blink-dev, Joey Arhar, Camille Lamy, Domenic Denicola, blink-dev, Emilio Cobos Alvarez, yo...@yoav.ws

Not supporting :visited would be the best. For the WPT tests, we would like to make sure that window.getComputedStyle or element.querySelector will not return a value indicating that a link was visited.

Domenic Denicola

unread,

Jan 13, 2021, 11:40:01 AM1/13/21

to Camille Lamy, blink-dev, Joey Arhar, Domenic Denicola, Emilio Cobos Alvarez, yo...@yoav.ws

I've sent a spec PR at https://github.com/whatwg/html/pull/6269 for removing activation behavior and :link/:visited matching for <link>s. A good next step for moving forward on this interop issue would be writing web platform tests that match that spec patch, and then confirming that various browsers are interested in updating their implementations to match those tests.

Joey Arhar

unread,

Jan 13, 2021, 11:43:08 AM1/13/21

to Domenic Denicola, Camille Lamy, Emilio Cobos Alvarez, blink-dev, yo...@yoav.ws

I can write the WPT change.

Your spec PR implies that link will still match :any-link though, right?

Domenic Denicola

unread,

Jan 13, 2021, 11:48:20 AM1/13/21

to Joey Arhar, Domenic Denicola, Camille Lamy, Emilio Cobos Alvarez, blink-dev, yo...@yoav.ws

I believe not: https://drafts.csswg.org/selectors-4/#the-any-link-pseudo says

> It matches an element if the element would match either :link or :visited, and is equivalent to :is(:link, :visited).

Joey Arhar

unread,

Jan 13, 2021, 5:59:51 PM1/13/21

to Domenic Denicola, Camille Lamy, Emilio Cobos Alvarez, blink-dev, yo...@yoav.ws

I see in the CSS PR linked from your HTML PR it removes :any-link for <link>s as well, which would make the current chromium behavior the specced behavior. I will include this in my WPT change.

Joey Arhar

unread,

Jan 19, 2021, 6:03:43 PM1/19/21

to Domenic Denicola, Camille Lamy, Emilio Cobos Alvarez, blink-dev, yo...@yoav.ws

The spec PR to remove these pseudo selectors for <link>s has been merged: https://github.com/whatwg/html/pull/6269

Reply all

Reply to author

Forward