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.

Sign up for GitHub

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

Jump to bottom

Ignore <a href="#"> when checking internal links #118

Closed
akoeplinger opened this issue Sep 28, 2014 · 15 comments
Closed

Ignore <a href="#"> when checking internal links #118

akoeplinger opened this issue Sep 28, 2014 · 15 comments
Labels
bug help wanted

Comments

@akoeplinger
Copy link
Contributor

Using such anchors is quite a common practice (e.g. by Bootstrap Dropdowns) and generates the following error:

index.html: linking to internal hash # that does not exist

I think they shouldn't trigger an error as they are just used as a placeholder and not for linking to a specific part of the document.
@nschonni
Copy link
Contributor

You need to set the href_ignore setting like https://github.com/wet-boew/wet-boew/blob/8f77ef8f418dd714cf244b499b7e3718538df672/Rakefile#L10

@akoeplinger
Copy link
Contributor Author

Ah, thanks, wonder how I missed this when looking at the help ;-)
Though I'd still argue it should be excluded by default?

@nschonni
Copy link
Contributor

@gjtorikian did ignore some protocols by default like in the README

Certain URIs, like mailto and tel, are always ignored.

It probably is a safe default, but if there is no way to opt out of the built in ignore it might hide bad links for other projects that don't use the "#" links for JS actions

@akoeplinger
Copy link
Contributor Author

Yep, good point. As long as I can ignore it with the href_ignore I don't mind, so feel free to close this if you think it shouldn't be ignored by default :-)

@doktorbro
Copy link

@nschonni Thank you for pointing to the href_ignore option.

@ssbarnea
Copy link

I think that this bug should be reopen, Jekyll should ignore this one by default, because as already pointed, that's valid, and also quite common. Default settings should be friendly.

@doktorbro
Copy link

Jekyll should ignore this one by default.

You mean Proofer, right?

@jacebrowning
Copy link

I think htmlproof <site> --href-ignore "#" should be the default.

@akoeplinger akoeplinger mentioned this issue Nov 3, 2015
Closed
@einverne
Copy link

It seems in version 3.0.5 there is no option --href-ignore "#". However, after I add --allow-hash-href or --url-ignore "#". I still got error like this:

linking to internal hash #left that does not exist (line 205)

@einverne
Copy link

einverne commented May 11, 2016 •
edited
Loading

After I lot of search, I figure I have to write RegExps like --url-ignore "/#.*/" to ignore "#left" etc internal hash.

vorburger added a commit to lastnpe/lastnpe.github.io that referenced this issue Nov 29, 2016
@vorburger
CI througth Travis with validation of HTML gen. by Jekyll
27ca18f 
https://jekyllrb.com/docs/continuous-integration/

gjtorikian/html-proofer#118
martinbjeldbak added a commit to martinbjeldbak/martinbjeldbak.github.io that referenced this issue Dec 11, 2016
@martinbjeldbak
Update .travis.yml to fix gjtorikian/html-proofer/issues/118
f3becb5
RossGammon added a commit to RossGammon/the-gammons.net that referenced this issue Dec 15, 2016
@RossGammon
Fix build failure by ignoring # with href-ignore
7f595e8 
Stolen from gjtorikian/html-proofer#118
orthodoc added a commit to orthodoc/medtoolkit that referenced this issue Dec 25, 2016
@orthodoc
Merge pull request #2 from orthodoc/dev
129f9bc 
with --ignore-url option internal link(#) must be the primary value

gjtorikian/html-proofer/issues/118
@orthodoc orthodoc mentioned this issue Dec 25, 2016
Merged
@afeld afeld mentioned this issue Apr 25, 2017
Merged
@fulldecent
Copy link
Collaborator

I'm just writing a note here to clarify since I see other people are linking to this page. To set the record straight:

If you use <a href="#xxx"> when #xxx does not exist, then you are doing it wrong.

A lot of people do it, but it's wrong. Usually the correct solution is to have <span class=...> or <div class=...>. The Bootstrap people are pretty smart. Their examples are full of "#" but those represent links for content you still need to make.

Exception: if you have something like Gmail where the fragment is #inbox-message-12546 and it intentionally changes to reflect page state then maybe that is special. But in that case, I would argue that you should have <body id="inbox-message-12546">.

EldarEccor added a commit to EldarEccor/backup_eldareccor.github.io_ that referenced this issue Aug 1, 2018
@EldarEccor
removed htmlproofer because of problels with internal links
a52fb52 
gjtorikian/html-proofer#118
DenisKramer pushed a commit to DenisKramer/elchemroutes2018.events that referenced this issue Oct 27, 2018
Hash references
8cf7197 
See: gjtorikian/html-proofer#118
@aduth aduth mentioned this issue Jul 1, 2020
Merged
@aduth
Copy link

aduth commented Jul 2, 2020

While true that empty anchor fragment # is often misused, it is considered in the HTML specification as a valid value referencing the top of the current document:

If fragment is the empty string, then the indicated part of the document is the top of the document; return.

https://html.spec.whatwg.org/multipage/browsing-the-web.html#scroll-to-the-fragment-identifier

It could be used this way for "Back to Top" links shown at the bottom of a page, for example.

See also #421, which added explicit support for #top links (which pass currently using htmlproofer).

@aduth aduth mentioned this issue Jul 2, 2020
Closed
@fulldecent
Copy link
Collaborator

There may be some confusion in WHATWG as to what is a null fragment and what is an empty string fragment.

But here is the authoritative text:

A URL’s fragment is either null or an ASCII string that can be used for further processing on the resource the URL’s other components identify. It is initially null.

https://url.spec.whatwg.org/#concept-url-fragment

If c is U+0023 (#), then set url’s fragment to the empty string and state to fragment state.

https://url.spec.whatwg.org/#path-state

And also, for the relative URL "#", here is the respective line:

Otherwise, if base’s cannot-be-a-base-URL flag is set and c is U+0023 (#), set url’s scheme to base’s scheme, url’s path to a clone of base’s path, url’s query to base’s query, url’s fragment to the empty string, set url’s cannot-be-a-base-URL flag, and set state to fragment state.

https://url.spec.whatwg.org/#no-scheme-state

And then as you note:

If fragment is the empty string, then the indicated part of the document is the top of the document; return.

https://html.spec.whatwg.org/multipage/browsing-the-web.html#scroll-to-the-fragment-identifier

Therefore, a link to "#" is always valid. Thank you, I stand corrected. Issue is valid.

@fulldecent fulldecent reopened this Jul 2, 2020
@ufonzak ufonzak mentioned this issue May 24, 2021
Merged
deFractal added a commit to deFractal/continuous-integration-circle that referenced this issue Jun 23, 2021
@deFractal
Ignore empty hash hrefs to prevent false error
772a7f6 
Arguably a bug in HTMLProofer, ref: gjtorikian/html-proofer#118
deFractal added a commit to deFractal/continuous-integration-circle that referenced this issue Jun 23, 2021
@deFractal
Ignore empty hash hrefs to prevent false error
9f3145c 
Arguably a bug in HTMLProofer, ref: gjtorikian/html-proofer#118
@DaveSkender DaveSkender mentioned this issue Nov 22, 2021
Closed
@yktoo
Copy link

yktoo commented Dec 20, 2021

For those ended up here via search, passing --allow-hash-href causes htmlproofer to ignore href="#".

@gjtorikian
Copy link
Owner

Closing this out as an old issue. I'm working on the next major upgrade for HTMLProofer and guaranteed that allow-hash-href does still work.

SoerenHenning added a commit to cau-se/theodolite that referenced this issue Jan 11, 2022
@SoerenHenning
Ignore empty hash hrefs to prevent false error
2c596c9 
Arguably a bug in HTMLProofer, ref: gjtorikian/html-proofer#118
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug help wanted
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
10 participants
@gjtorikian @ssbarnea @fulldecent @jacebrowning @nschonni @akoeplinger @yktoo @aduth @einverne @doktorbro