RE: Steem-Suche [03/2023]
… das Springen innerhalb eigener Dokumente zu ermöglichen, wäre das eine feine Sache (wobei ich fürchte, dass es leider einfach nicht funktioniert).
Das, lieber Jaki01, geht mit der HTML-Anchor Methode. Die habe ich mir bereits 2016, also in meinem ersten Monat auf dem Steem gewünscht. Seitdem hat sich am Frontend nichts geändert. Schon seit Jahren wünsche ich mir einen besseren Condenser, in dem sowohl HTML-Standards, wie auch jene von Markdown funktionieren, die bis heute nicht berücksichtigt wurden.
Technisch ist das machbar, aber dafür wollte nie jemand Geld ausgeben. @Moecki tastet sich langsam in der Materie vor was Anlass zur Hoffnung gibt, dass wir in ein paar Jahren den Condenser bekommen, den wir uns schon immer wünschen. Moeckis Suchfunktion ist immerhin mal wieder bemerkenswert,
Das sollte damit gehen, tut es aber nicht. Jedenfalls ist mir auf STEEM und HIVE auf keinerlei Art und Weise gelungen, was in normalen HTML-Dokumenten kein Problem darstellt.
Soweit ich das bisher ermitteln konnte, kann man durchaus in einem Post einen Ankerpunkt ansprechen (z. B. mit
href="#ein_anker). Was aber wohl augenscheinlich unterbunden wird, ist die Eintragung des Ankers selbst. Wenn man zum Beispiel einer Überschrift eine ID mitgeben will (<h4 id="ein_anker">), die mit einem Anker-href angesprungen werden kann, wird das zwar in der BC gespeichert, aber nicht im HTML-Code umgesetzt. Damit findet der Anker-href das Ziel nicht und der Link läuft ins Leere. Ich habe die entsprechenden Code-Zeilen, die die id herausfiltern noch nicht ausfindig machen können...Das waren auch meine Erkenntnisse in 2016. Eventuell liegt der Editorcode gar nicht im Condenser. An der Stelle wird vielleicht ein externes Editor-Programmmodul in den Condenser eingebunden. Dort wird auch nichts gefiltert. Ich denke, dass dort außer den zugelassenen HTML-Statements einfach keine anderen Befehle bearbeitet werden. Es gibt ja einige Markdown Editoren. Das Teil musste Dan Larimer auch 2015/16 nicht neu erfinden. Er hat nur alle unerwünschten HTML-Statements gelöscht, die dort noch zugelassen waren.
Ich denke schon, dass der Editorcode im Condenser liegt. Das verblüffende ist, dass dort viel mehr Funktionalität zu sein scheint, als letztlich angeboten wird. Ich habe ja die Anfangszeiten nicht so ausführlich mitbekommen. Wurde denn beim Editor zwischenzeitlich mal bei der Funktionalität abgespeckt? Es gibt sowohl eine Komponente ReplyEditorNew als auch ReplyEditor.
Leider kann ich die React-Suppe so schlecht debuggen, so dass es etwas mühsam ist, herauszufinden, was wann wie eingebunden und ausgeführt wird...
Ich vermute aber weiterhin (bzw. bin mir ziemlich sicher), dass es letztlich "nur" eine Rendering-Einschränkung ist. Schau dir zum Beispiel die FAQ an. Da gibt es funktionierende Anker-Verweise. Die Seite wird aber nicht vollständig dynamisch ausgeliefert, sondern ist eher statisch hinterlegt.
Nachtrag:
Mit der Suche habe ich einige alte Beiträge gefunden, die das Problem bereits beschrieben (habe ich schon erwähnt, dass ich die Suche toll finde ;-)) ). Wie du schon geschrieben hast, ist es dasselbe Problem wie schon in 2016. Auf github findet man auch eine (kurze) Erklärung dazu in diesem Kommentar zum Issue. Die
id-Attribute werden also wirklich bei der "Säuberung" entfernt.Ein Lösungsansatz wurde dort zwar beschrieben, aber irgendwie nicht weiter verfolgt (zu geringe Priorität)... naja, und nach der Fork ist die Priorität auch nicht mehr gestiegen ;-)
Deine Suche ist natürlich das Sahnehäubchen auf dem Kuchen, keine Frage.
Einmal hat sich im Editor auch was geändert. Da haben sie die DIV-Statements eingeführt. Du weißt schon. Die zum Links- und Rechtsstellen von zulässigen Elementen.. Da keimte Hoffnung auf. Es entpuppte sich als Strohfeuer. Ansonsten kann ich mich an keine Neuerung erinnern.
Ich denke vielmehr, dass damit Blog- und Relply-Editor gemeint sind.
Ei, genau das sag ich doch seit Jahren. Ich glaube, ich habe mich nicht deutlich genug ausgedrückt.