Standardize behavior for internal vs external links

[mjherzog]

I recommend that we follow a standard approach for internal vs external links on the website.

• For external links we use the current approach with an https link that opens a new browser tab
• For internal links (pages within the website) we should use an internal link which does not open a new browser tab. In this scenario you can navigate back/forward within the website.

This approach is smoother for display and navigation.

One question is: Does this makes it harder for someone to copy an internal link for use elsewhere.

[mjherzog]

There is a current example from the handling of links to PURL type definitions from the PURL Types grid.

• These links currently go to: https://packageurl.org/docs/purl-spec/types-doc/ and stay on the packageurl.org website.
• This has become a problem because it requires copying files from the purl-spec/types-doc folder to packageurl.org/docs/purl-spec/types-doc. At the current moment the website files are 3 months old.
• Although we could automate the copying it would probably be better to change these to external links opening in a new window.

[johnmhoran]

@mjherzog I don't understand your comment -- which links do what? The link you provided takes me to this page, which I have not seen before:

[johnmhoran]

BTW I created the current structure at @pombredanne 's request -- #119 -- and I noted the updating and other potential problems in a comment. 👎 on manually updating repo 1 when repo 2 changes.

[mjherzog]

Sorry about the link - I generalized it without the html file so it makes sense that you got the directory list.
And thank you for the reminder for #119. So I guess we need to focus on automating updates from the purl-spec to the packageurl.org repo.

[johnmhoran]

No no -- actually @mjherzog I'm glad you used that link initially, which has prompted me to dig a bit just now into the companion purl-spec and www.packageurl.org repo Markdown type-def folders. I'm not certain atm but it's possible that I have not run the necessary manual command(s) to regen the files following each even-minor change in one (or addition of a new file).

Looking into this now.

[johnmhoran]

The golang and npm .md definition files are a month old on purl-spec and older on the website repo.