RE: Steem-Suche [03/2023]
Was mir bei deinem Index (eine sehr gute Idee) auffällt, ist, dass man nicht direkt zu den einzelnen Punkten innerhalb der Seite springen kann (dass es also nicht oben ein Inhaltsverzeichnis gibt, und dann weiter unten die einzelnen Kapitel, zu denen man von oben direkt springen kann, wie es in einem HTML-Dokument möglich wäre).
Es scheint mir fast so zu sein, dass - weder auf STEEM noch den diversen HIVE-Frontends - die jeweiligen HTML- bzw. Markdown-Befehle ('name', 'id', ..., ...) erkannt werden, die dazu nötig wären.
Falls jemand (@moecki, @michelangelo3, @steemchiller, ...) eine Möglichkeit kennt, das Springen innerhalb eigener Dokumente zu ermöglichen, wäre das eine feine Sache (wobei ich fürchte, dass es leider einfach nicht funktioniert).
An dieser Stelle sollte ich es jetzt vor lauter Lauter nicht vergessen, @moecki noch ein wohlverdientes Lob für seine STEEM-Suche-Implementierung auszusprechen! :)
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.
Ja, ein Inhaltsverzeichnis mit Springmöglichkeit wäre ganz phantastisch und ich habe es auch schon oft vermisst (in meinem Index, aber auch in der Netiquette und anderen langen "Scrolltexten). Hatte mal überlegt, zu "Einzelbeiträgen" zu verlinken, die ich dann aber mit einem No-Name-Account verfassen würde (habe tatsächlich Skrupel, wegen meiner Autovoter und treuen Leser diverse als Spam interpretierbare Kurzposts am Stück bzw. innerhalb kürzester Abstände rauszuhauen). War mir zu aufwändig.
Möglicherweise schreibe ich nochmal eine Inhaltsangabe mit den verschiedenen Themen und verlinke diese zu Kommentaren (ähnlich, wie Werner es in seiner Kneipe gemacht hat, nur eben mehr Kategorien). Kann man machen und ist dem wirklich Interessierten vielleicht eine Hilfe. Allerdings ist es auch mal wieder nichts Halbes und nichts Ganzes - ein HTML-Springen sollte wie auf jeder Internetseite wahrlich drin sein!
Danke dir!
Ich kenne auch keine Möglichkeit, innerhalb von Posts zu Verweisen zu springen. Normalerweise wird dafür ja unter anderem das '#' - Zeichen verwendet. Könnte mir vorstellen, dass es was mit den Tags zu tun hat. Genaues kann ich dazu aber nicht sagen. Nur, dass ich es in diversen Varianten in Posts versuchte, es mir aber nicht gelang.
Eine Möglichkeit wäre, so wie ich es bei meinen Suchergebnissen Markierung im original Beitrag gemacht habe.
Bei einem Inhaltsverzeichnis im eigenen Post, so wie es sich @jaki01 wünscht, leider etwas aufwändig, da man, falls die URL zum Post nicht wie erwartet ausfällt, die Links nachträglich korrigieren muss. Außerdem wird der Post neu geladen und springt nicht direkt einen Anker an.
So könnte ein Inhaltsverzeichnis z.B. aussehen:
Was gibt's sonst noch?
Und was gibt's künftig noch?
Moecki is now a Steem Witness
Wie bei Links oben zu sehen, wird am Ende der URL zum Post einfach der Text für "Sprungmarke" angehängt:
.../steem-suche-03-2023#:~:text=Moecki is now a Steem Witness, das ist alles.Im Browser kann man sich den "Anker"-Link auch direkt in die Zwischenablage kopieren lassen, sieht bei mir so aus:
Leider nur eine halbe Lösung, denn soweit ich weiß, funktionieren diese Links nur mit Chromium-basierten Browsern. Mit Firefox geht es schon mal nicht, das habe ich gerade ausprobiert.
Ach, wenn ich deine Anleitungsposts oder -kommentare sehe, bin ich immer hin und weg. Das sieht immer richtig professionell aus und ist total nachvollziehbar. Das nur so mal am Rande :-)
Kann ich bestätigen. Ist bei mir genauso.
Diese Möglichkeit kannte ich noch gar nicht. Danke!
Oh, danke für Blumen, freut mich!
Hab übrigens gerade mit meinem Test-Acc versucht a, div, sup, hr, und center eine id zu geben, steemit filtert (wie du schon geschrieben hast) das raus. Na ja, ich kann damit leben ;-)
Mit diesem commit wird die
idimdiv-Tag nicht mehr gefiltert. Hab es aber eingeschränkt auf id's mit dem Präfix "anchor", um möglichen Namenskollisionen aus dem Weg zu gehen. Das war wohl auch einer der Gründe, warum das bisher so nicht weiterverfolgt wurde.Der Sprung funktioniert zwar, allerdings klappt das Rendering dann nicht mehr richtig. Der obere Teil des Posts wird abgeschnitten... Das muss ein React-spezifisches Problem sein, dem ich mich aktuell nicht widmen kann.
Wahrscheinlich muss man am
UniservalRenderetwas drehen. Da wird das Scroll-Verhalten angepasst...Ups, ich sollte ab und zu meine Augen aufmachen :-)
Hab es gerade auf steemit ausprobiert und erst danach gesehen, die Änderung ist ja auf deinem GitHub.
Recht hast, so Kleinigkeiten können ganz schön zeitraubend werden.
Das ist schon seltsam:
Dein Beispiel mit @moecki s Suche funktioniert bei mir im Chrome-Browser aber nicht in Brave (der ja Chrome-basiert ist).
Ein Beispiel mit folgendem Text funktioniert bei mir in beiden Browsern nicht:
Hive-Post
Code:
<a href="https://peakd.com/genetik/@jaki01/von-inseln-weinbergen-blinden-mannern-und-heterozygoten-konduktorinnen-genetikaufgabe#:~:text=Zusatzhinweise für Hiver und andere Nichtbiologen: :-)">Hive-Post</a>
Ei, mir scheint diese Funktion führt ein Eigenleben. Habe deinen Link kurz ausprobiert, erst ging es nicht, beim 2. Anlauf (URL beim Tab mit dem geöffneten Post eingefügt) dann schon und dann in einem neuen Browserfenster wieder nicht. Also zuverlässig sieht eindeutig anders aus.
Verstehe, also wenn man ein Post verfasst, müsste man sich schon dann überlegen, wie der Link des Posts aussehen wird (oder diesen nachträglich anpassen) und dann jeweils an diesen vermuteten Link #:~:text={text] dranhängen, so dass man nach neuem Laden des Posts an die entsprechende Textstelle gelangen würde (sofern man den passenden Browser benutzt) ...
Tja ... interessant, aber es ist die Frage, ob das pragmatisch genug ist. Jedenfalls gute Idee.
Ja, genau. Nur leider funktioniert es halt bei einigen Browsern wie z.B. dem Firefox nicht.
Hab eben die Links in meinem vorigen Kommentar nochmal ausprobiert und bin ganz erstaunt, wenn der Post "normal" geladen wurde (über die Post-URL ohne Verweis auf Kommentare) dann geht der Sprung ganz fix, anscheinend ohne den Post neu zu Laden.
Fällt vielleicht eher in die Kategorie "Spielwaren" :-)
Oh, ich bin nochmal erstaunt, gem. dieser Statistik sind doch die meisten mit Chromium-Browsern unterwegs, Edge und Opera gehören glaub ich auch dazu, das wären dann ca. 80%.
Das geht mit HTML-Anchor. Dafür müsste allerdings ein neuer Editor her oder der alte besser ausgestattet werden..