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

Lighthouse warns when an anchor tag is just a placeholder #15820

Open
2 tasks done
romainmenke opened this issue Feb 21, 2024 · 7 comments · May be fixed by #16287 or #16292
Open
2 tasks done

Lighthouse warns when an anchor tag is just a placeholder #15820

romainmenke opened this issue Feb 21, 2024 · 7 comments · May be fixed by #16287 or #16292
Assignees
Labels

Comments

@romainmenke
Copy link

romainmenke commented Feb 21, 2024

FAQ

URL

https://www.romainmenke.com/lighthouse-bug-anchors-without-href-attribute/without.html

What happened?

I used an anchor tag without an href attribute and placed an image inside:

<a>
	<img src="https://picsum.photos/200/300" alt="" width="200" height="300" loading="lazy">
</a>

Our actual template code looks much more like :

<a
  {% if link %}
    href="{{ link }}"
  {% endif %}
>
  {# ±200 lines of template code #}
  <img src="https://picsum.photos/200/300" alt="" width="200" height="300" loading="lazy">
  {# ±200 more lines of template code #}
</a>

And then I got this error:

Links are not crawlable

Screenshot 2024-02-21 at 19 24 27

There are a bunch of warnings on that page but only Links are not crawlable is relevant to this issue.

What did you expect?

The HTML specification clearly envisions a dual mode for anchor elements.

Either they have an href attribute, which makes them true anchor elements or they do not, in which case they represent a placeholder.

This concept is also used in CSS for the location pseudo classes : https://drafts.csswg.org/selectors/#the-any-link-pseudo

These only match anchors that do have an href attribute.


When templating (server-side) it really helps to be able to wrap a bunch of html with an anchor tag and optionally give it an href attribute only when it needs to be a link.

This makes the variable part in the template much smaller (only 1 attribute).


I expect Lighthouse to embrace the relevant specifications and to not give any warnings here.

I also expect Lighthouse to have consistent behavior between anchor tags without href when they contain text vs. when they contain images.

What have you tried?

N/A

How were you running Lighthouse?

Chrome DevTools

Lighthouse Version

latest

Chrome Version

latest

Node Version

N/A

OS

N/A

Relevant log output

N/A
@adamraine
Copy link
Member

I expect Lighthouse to embrace the relevant specifications and to not give any warnings here.

Yeah I think we can discuss changing this. Although the link is not crawlable this doesn't appear to be a bad practice that search documentation warns against.

I also expect Lighthouse to have consistent behavior between anchor tags without href when they contain text vs. when they contain images.

Not sure what you are referring to here, what differences did you noticed between anchor tags containing images vs text?

@romainmenke
Copy link
Author

I also expect Lighthouse to have consistent behavior between anchor tags without href when they contain text vs. when they contain images.

Not sure what you are referring to here, what differences did you noticed between anchor tags containing images vs text?

This triggers a warning:

<a>
	<img src="https://picsum.photos/200/300" alt="" width="200" height="300" loading="lazy">
</a>

This does not:

<a>
	Hello
</a>

@adamraine
Copy link
Member

<a>
	Hello
</a>

The audit fails for me here as well. Not noticing any difference between images/text.

@romainmenke
Copy link
Author

You are right!

I was testing with an anchor element that also had an id attribute.
My assumption that it had to do with image/text content was incorrect.

@adamraine adamraine changed the title Lighthouse warns when an anchor tag doesn't have a href attribute and does contain an image tag. Lighthouse warns when an anchor tag is just a placeholder Feb 21, 2024
@romainmenke
Copy link
Author

romainmenke commented Feb 21, 2024

Thank you for updating the title.
I've also crossed out the incorrect statement in the initial report and updated the html content of the example page

This better reflects the issue.

@connorjclark
Copy link
Collaborator

relevant spec

If the a element has an href attribute, then it represents a hyperlink (a hypertext anchor) labeled by its contents.

If the a element has no href attribute, then the element represents a placeholder for where a link might otherwise have been placed, if it had been relevant, consisting of just the element's contents.

The target, download, ping, rel, hreflang, type, and referrerpolicy attributes must be omitted if the href attribute is not present.

If the itemprop attribute is specified on an a element, then the href attribute must also be specified.

Agreed we should not flag <a> as an uncrawlable link based on the spec.

We should still call it out if it has any of these must-not-be-present attributes when href is missing.

Thanks for bringing this to us!

@hiroya-uga
Copy link

hiroya-uga commented Dec 16, 2024

This is a very interesting discussion.

I agree that pointing out <a> elements without an href attribute is valuable.
On the other hand, the placeholder role that a:not([href]) can serve is also significant from an HTML perspective.

Looking at the already closed PR #15894, it seems too complex to resolve quickly.
As a temporary solution, how about excluding cases where the aria-current attribute from WAI-ARIA is present?

Because, a:not([href])[aria-current="page"] clearly indicates a placeholder use case, so I believe it doesn't need to be flagged as an error.

Thank you for reading!


Related specs:

@hiroya-uga hiroya-uga linked a pull request Dec 17, 2024 that will close this issue
@adamraine adamraine linked a pull request Dec 19, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment