[Elchi3]

This PR refactors a few docs to avoid HTMLHyperlinkElementUtils mixin pages.
It shows a proof of concept for #1940

Currently, we have these pages (marked as "Experimental" which is hilarious)
https://developer.mozilla.org/en-US/docs/Web/API/HTMLHyperlinkElementUtils
https://developer.mozilla.org/en-US/docs/Web/API/HTMLHyperlinkElementUtils/hash
https://developer.mozilla.org/en-US/docs/Web/API/HTMLHyperlinkElementUtils/host
etc.

With this PR, the whole mixin nomenclature is avoided and these pages exist:
https://developer.mozilla.org/en-US/docs/Web/API/HTMLAnchorElement
https://developer.mozilla.org/en-US/docs/Web/API/HTMLAnchorElement/hash
https://developer.mozilla.org/en-US/docs/Web/API/HTMLAnchorElement/host
etc.
https://developer.mozilla.org/en-US/docs/Web/API/HTMLAreaElement
https://developer.mozilla.org/en-US/docs/Web/API/HTMLArea/hash
https://developer.mozilla.org/en-US/docs/Web/API/HTMLArea/host
etc.

I've made separate commits which are worthwhile to preserve (so, maybe no squash and merge).

[Elchi3]

Reviewers: you won't see compat tables for the moment. mdn/browser-compat-data#8933 is the analog proof of concept in BCD land.

[peterbe]

I noticed one of the redirects looks weird. So I filed https://github.com/mdn/yari/issues/2790
But I noticed a bunch of others that look equally weird. E.g.

/en-US/docs/Mozilla_event_reference/DOMContentLoading	(event)

/en-US/docs/URI/www	and

/en-US/docs/Web/Reference/Functions_and	classes_available_to_workers

I think it's a bug that the redirect validation stuff in CI didn't complain about these. So @Elchi3 would you mind manually look into those for now, whilst @fiji-flo and I worry about the validation script needing some improvements in https://github.com/mdn/yari/issues/2790

[Ryuno-Ki]

Am I assuming right, that a „Proof of concept” is not meant to be merged?
If so, could you mark this PR as draft to prevent an accidential merge?

[chrisdavidmills]

So this is all looking pretty damn good, Mr Scholz!

A few thoughts here:

1. So for the redirects you are putting in place from the old mixin pages, what is the thought process here? Basically just redirect it to the likely most popular implementation of the mixin feature? It looks like you're redirected all the HTMLHyperlinkElementUtils pages to their HTMLAnchorElement, which makes sense as the <a> element is much more commonly used than <area>, but I just wanted to be sure of the logic here.

2. Well, one page there doesn't seem to be a redirect present for is the actual /en-US/docs/Web/API/HTMLHyperlinkElementUtils interface page.

3. on /en-US/docs/Web/API/HTMLAnchorElement and /en-US/docs/Web/API/HTMLAreaElement, password should be below origin for alphabetic order.

4. Do you think the specification table on the interface pages needs to include a row for the mixin, i.e. pointing to https://html.spec.whatwg.org/multipage/links.html#htmlhyperlinkelementutils? I'm not sure about it. I mean, when you got to the spec definition for the interface itself, the WebIDL includes a line about the mixin anyway, e.g. HTMLAnchorElement includes HTMLHyperlinkElementUtils;

5. Related to the above point, on member pages you have no mention anywhere that they are defined on a mixin rather than on the actual interface they appear on. I don't think it matters for the most part, but I reckon that we should at least have some kind of note in the specification table or somewhere that says (for example for http://localhost:5000/en-US/docs/Web/API/HTMLAnchorElement/origin) "In the specification, the origin property is defined on the HTMLHyperlinkElementUtils mixin". Most people won't care, but it'd be nice to clarify it for people that do.

6. The standard syntax subsections (i.e. "Return value" for properties, "Parameters" and "Returns" for methods) are not included. Is this just for brevity while you do your experiment?

[Elchi3]

1. So for the redirects you are putting in place from the old mixin pages, what is the thought process here? Basically just redirect it to the likely most popular implementation of the mixin feature? It looks like you're redirected all the HTMLHyperlinkElementUtils pages to their HTMLAnchorElement, which makes sense as the <a> element is much more commonly used than <area>, but I just wanted to be sure of the logic here.

Yeah, exactly this. I'm not sure it will be always like this but I thought it makes sense here.

2. Well, one page there doesn't seem to be a redirect present for is the actual /en-US/docs/Web/API/HTMLHyperlinkElementUtils interface page.

I tried to do yarn content add-redirect /en-US/docs/Web/API/HTMLHyperlinkElementUtil /en-US/docs/Web/API/HTMLAnchorElement but as far as I can tell it removes the redirects for the subpages. I'm getting entries like these as a diff:

-/en-US/docs/Web/API/HTMLHyperlinkElementUtils/hash     /en-US/docs/Web/API/HTMLAnchorElement/hash

So, I thought having the individual pages redirect is more important than the main page redirect.

3. on /en-US/docs/Web/API/HTMLAnchorElement and /en-US/docs/Web/API/HTMLAreaElement, password should be below origin for alphabetic order.

Done in 5041ded

4. Do you think the specification table on the interface pages needs to include a row for the mixin, i.e. pointing to https://html.spec.whatwg.org/multipage/links.html#htmlhyperlinkelementutils? I'm not sure about it. I mean, when you got to the spec definition for the interface itself, the WebIDL includes a line about the mixin anyway, e.g. HTMLAnchorElement includes HTMLHyperlinkElementUtils;

As discussed in the other issue, I don't think this is needed. (also having in mind we want to auto-generate the spec table in the future).

5. Related to the above point, on member pages you have no mention anywhere that they are defined on a mixin rather than on the actual interface they appear on. I don't think it matters for the most part, but I reckon that we should at least have some kind of note in the specification table or somewhere that says (for example for http://localhost:5000/en-US/docs/Web/API/HTMLAnchorElement/origin) "In the specification, the origin property is defined on the HTMLHyperlinkElementUtils mixin". Most people won't care, but it'd be nice to clarify it for people that do.

My feeling from the discussion is that a mixin is a concept that doesn't need to appear in docs necessarily. I don't think we need to worry about it at this stage. If there is demand that we should note that a feature comes to an interface via a mixin we can think about this. Right now, the idea is that it doesn't really matter and confuses everyone a lot when there is talk about a thing that only exists in the abstract / the spec.

6. The standard syntax subsections (i.e. "Return value" for properties, "Parameters" and "Returns" for methods) are not included. Is this just for brevity while you do your experiment?

I copied from existing docs. Probably should have copied from a more current template. Sorry about that. Not sure it is mission-critical for this PR, though.

[Elchi3]

Merge conflicts resolved, redirect issue resolved, comments addressed. Marking as ready for review.

[chrisdavidmills]

I'm really happy wit h this. Let's get it merged!