[bug][feat] support internal anchors or dont crash on references

[mckaygerhard]

This can be managed also as bug, but not cos this project is a debload version and prety minimalistic one..

so i used the feature request. cos can be not so easy to implement but easy to generate the rendering code (i guess it rely on the markdown rendering engine)

Bug present

By example i can check this same issue with https://github.com/arnaudsm/raito/issues/32 and https://github.com/arnaudsm/raito/issues/32# as same .. but

Explanation

1. When you click on an internal anchor link, you will scroll automatically to the referred section and display it on your browser.
2. Markdown rendering by default makes the titles or heads also anchors or internal references for those kind of links

Expected results

To understand internal link see the below examples.

## mytitle

Will become by markdown rendering as:

<h2><a href="#mytitle">mytitle</a><h2>

or more complex will become something like:

<h2><a id="mytitle">mytitle</a></h2>

Curren results

currently raito does not support such thing by default:

[mckaygerhard]

as note its also a bug (by the moment is not necesary to provide the feature of goni to the anchor.. just to fix the rendering issue)

i can check this same issue with https://github.com/arnaudsm/raito/issues/32 and https://github.com/arnaudsm/raito/issues/32# as same .. but in raito just break the rendering..

[arnaudsm]

That's a good idea. Marked supports it out of the box, we'd only have to patch the fetch code. Will implement soon

[mckaygerhard]

so then, should i slipt the issue into the bug reported and the feature requst ? @arnaudsm

[arnaudsm]

It's more of a bug, this projects aims to respect web standards as much as possible :)

[mckaygerhard]

ok, @arnaudsm first of all try to fix the rendering problem with anchors , i mean just to do not crash when xxx# are used..

later, lest check if the rendering of marked.js renders the anchor link reference

[mckaygerhard]

ok, checked marked.js and seems this is a bug complety:

takend from implementation of GFM and CM the links are almost 100% supported at marked V4.2.2 from https://github.com/markedjs/marked/discussions/1202#discussioncomment-4124069

GFM	Count	Percent
Link reference definitions	25 of 27	93%
Links	75 of 90	83%

CM	Count	Percent
Link reference definitions	27 of 27	100%
Links	75 of 90	83%

The example 500 it our case of test and seem this is a bug inside raito.. cos seems marked already support embebed links with internal references

Seems the required feature (apart of the bug) its included in test cases https://github.com/markedjs/marked/blob/9a3d0892f8673b3e5d8aae7f94c1fca263700a39/test/specs/commonmark/commonmark.0.30.json#L4000 @arnaudsm

git-crap-hub actions https://github.com/markedjs/marked/actions/runs/5529652188 do not reports faults so seems is supported the feature request here in first post of this issue..

[mckaygerhard]

ok it worked but, with minor (not so important by now) details: when i check "#links" worked but a side effect :laughing: :rofl:

At the left, the working current behaviour, at the right the right way must be

Of course this is a problem on upstream, marked just due rendering does not take into consideration or not know that there are other elements, but rather assumes that there is only the same markup rendering engine

Its a upstream problem that affects to railto.. @arnaudsm in minimal way and must be pointed in a kind of "know issues" section in future documentations (i will proposed),

wheantime i guess you should send a issue report to marked project to provide a workaround.. cos if you provide such workaround the raito project will raise more code and will lost simplicity

[mckaygerhard]

what about, this hack

index 4deecda..d607c3d 100644
--- a/index.html
+++ b/index.html
@@ -11,8 +11,9 @@
 <!-- USER CONFIG -->
 <script>
        const config = {
                sitePath: "/",
                browserRouter: false,
+               scrollworkaround: true,
                name: "Raito",
                components: ["docs/navbar", "docs/github"],
                errorMessage: "Page not found",
@@ -415,9 +412,17 @@
                                                loadContent();
                                        };
                        });
-               if (selector) document.getElementById(selector).scrollIntoView()
-
+               if (selector) {
+                       offsettag = window.innerHeight / 8
+                       taganchor = document.getElementById(selector);
+                       taganchor.scrollIntoView({behavior: "smooth", block: "start", inline: "start", offset: offsettag})
+                       if(config.scrollworkaround) {
+                               const y = taganchor.offsetTop - (offsettag);
+                               window.scrollTo( { top: y, left: 0, behavior: 'smooth' } );
+                       };
+               };
                document.body.classList.add("loaded");
+               
                if (!config.browserRouter) window.location.replace(config.sitePath + path);
        };

[mckaygerhard]

with that proposal, scrollIntoView is used cos autodetects with a vertical writing mode, you’d scroll horizontally, so in those cases, start means right, end means left on the block axis.

but we can use tricky with options object behabiour, that only are partial suported, and if user are not so happy, just falback by configuration to scrollTo.

this automatically detect any header offset, cos the scroll will goin directly to the anchor but with minimal offset based on window size.. (take into consideration retina screen etc etc)