SVG element pages that start with "mesh" are missing

[asummers1]

Summary
Found while viewing https://developer.mozilla.org/en-US/docs/Web/SVG/Element. All of the links to elements that start with "mesh" return 404 errors.

Steps To Reproduce (STR)
How can we reproduce the problem?

1. Go to https://developer.mozilla.org/en-US/docs/Web/SVG/Element.
2. Click an element that begins with "mesh". (E.g. "meshgradient", "meshrow")*
3. Witness the sight of a missing page.

Actual behavior
The page corresponding to those particular SVG elements are missing.

Expected behavior
Display the relevant documentation.

Additional context
Is there anything else we should know?

*Standard angle bracket formatting removed due to GitHub restrictions.

[escattone]

@eatmorepies-dev I don't believe those document pages have ever existed. cc @chrisdavidmills

@peterbe Shouldn't we have detected these as broken links in Yari's local server?

[chrisdavidmills]

Yup, the pages for <mesh>, <meshgradient>, <meshpatch>, and <meshrow> don't exist, and need to be written. I've triaged this bug accordingly.

We could remove the links for now, but personally I'd rather keep them and update the styling of "dead" internal links to some kind of red color like we used to have them, maybe with some kind of readout at the bottom of the page to say that these pages don't exist, please consider contributing, or something similar to that. I'd rather not do titles/tooltips again , as we made a decision to move away from those for accessibility's sake.

[peterbe]

Shouldn't we have detected these as broken links in Yari's local server?

Huh. Weird. Yeah, it should have noticed that as a flaw but it didn't. Strange.

What should ultimately happen is that instead of:

<a href="/en-US/docs/Web/SVG/Element/mesh"><code>&lt;mesh&gt;</code></a>

it should become something like:

<a class="new" title="This page does not exist yet. Consider contributing"><code>&lt;mesh&gt;</code></a>

But first of all, it's a regular link (once KS is done making the HTML) and the flaw broken_link checker should have noticed it and listed it when you click "Show flaws".

[peterbe]

Ah!! This is interesting. The broken_links flaw checker does find that they're broken, but because they're not mentioned in the index.html source, it's skipped. So basically, it doesn't know how to deal with broken links that came from KS macros.
I think this is a shortcoming of the flaw system. In a sense. The flaw itself lies with the .ejs code. That macro should have done a better job (e.g. using wiki.pageExists() etc). The person who's touching the index.html shouldn't be held "guilty" of a bug in the KS macro as they're editing the page.

What's cool about flaws is that they're very visual. You can console.log them or see them in localhost:3000 on the toolbar or list them in the Flaws Dashboard.

But one thing we could do in build/flaws.js is whenever a <a href="...this..."> is broken, but not in the source, we can:

• mutate the hyperlink to become something like <a href="..." class="possibly-broken" title="This link is broken but not in the original index.html source.">
• log some other flaw. E.g. broken_inferred_link.
• still log it as a flaw but tag it differently so when it displays in "Show flaws" it doesn't scream for attention the same way.

Thoughts and ideas?

[peterbe]

To make this actionable, I think the KS macro that produces these links should get the first improvement. I.e. instead of just:

for (const subpage of subpages) {
    <a href="{base}{subpage}">...</a>
}

it should instead be expanded to something like:

for (const subpage of subpages) {
   if (pageExists(base + subpage) {
      <a href="{base}{subpage}">...</a>
  } else {
      <a class="new" title="The page {subpage} hasn't been created yet! Please consider helping out">...</a>
  }
}

[Ryuno-Ki]

Related to https://github.com/mdn/mdn-minimalist/issues/443

From an accessibility point of view:

• Meaning should not be carried by colour alone. (I'm not sure, whether „red” is understood as an alarming colour in different cultures)
• title attributes are not accessible on non-hover-devices, too (as far as I know)

My suggestion would be to add an endnote (perhaps using dagger as anchor text?) and explain there, that this page does not exist.
It can still be a title attribute on the <a>, but not only there.

@chrisdavidmills Have you created issues to ask for writing of those articles? (There was something editorial steeting commitee you mentioned in #1506 (comment))

[Ryuno-Ki]

@eatmorepies-dev Thanks for catching this!

[ghost]

If the page is 404 does the editor remove href as a fix?

[Ryuno-Ki]

We could remove the links for now, but personally I'd rather keep them and update the styling of "dead" internal links to some kind of red color like we used to have them

I read @chrisdavidmills in a way, that they should not be removed, but marked up as broken instead.

(Likely also relevant for #1510)

[ghost]

https://developer.mozilla.org/en-US/docs/Web/CSS/:link

This Is a minimalist issue anyway.

[peterbe]

Related to mdn/mdn-minimalist#443

From an accessibility point of view:

* Meaning should not be carried by colour alone. (I'm not sure, whether „red” is understood as an alarming colour in different cultures)

* title attributes are not accessible on non-hover-devices, too (as far as I know)

My suggestion would be to add an endnote (perhaps using dagger as anchor text?) and explain there, that this page does not exist.
It can still be a title attribute on the <a>, but not only there.

@chrisdavidmills Have you created issues to ask for writing of those articles? (There was something editorial steeting commitee you mentioned in #1506 (comment))

Yeah, our solution for all these <a class="new" title="Page doesn't exist yet bla bla"> definitely has some interesting problems.
Would you mind starting a fresh new discussion about this in mdn/yari? It certainly can be improved and solution might end being a mix of some new HTML + some new SCSS.

[Ryuno-Ki]

Would you mind starting a fresh new discussion about this in mdn/yari? It certainly can be improved and solution might end being a mix of some new HTML + some new SCSS.

Filled mdn/yari#2705

[sideshowbarker]

There are no longer any mesh* elements listed on https://developer.mozilla.org/en-US/docs/Web/SVG/Element