↑

Diskussion 2019
Platz für Vorschläge und allgemeine Anmerkungen zu Aneamal

  1. # und @ sind derzeit gewissermaßen „semitransparent“. Man könnte auch sagen, dass die Zeichen einen String zwar beginnen, aber nicht beenden. Damit meine ich, dass einerseits dies

    @author: martin
    abc#def->/
    sand@author->/

    umgeformt wird in

    abc<a href='/'><span id='def'>def</span></a><br>
    sand<a href='/'>martin</a>

    wobei "abc" und "sand" nicht Teil des Linktextes werden. Das heißt, # und @ unterbrechen sozusagen den String vor dem Link. Andererseits aber werden

    #ein#mal
    #the@author

    umgewandelt in

    <span id='einmal'>ein<span id='mal'>mal</span></span><br>
    <span id='theauthor'>themartin</span>

    wobei das # und @ in der Mitte der Strings nicht verhindern, dass sich das # am Zeilenanfang auf den ganzen String bezieht. So werden aus #ein#mal nicht die IDs "ein" und "mal", sondern "einmal" und "mal". Aus jener Richtung unterbrechen # und @ den String nicht. Das wirkt inkonsequent. Sollte man es ändern?

    Ein Vorteil des Umstandes, dass insbesondere # einen String nicht beendet, ist, dass so die Konstruktion ->##foo möglich wird: ein Link zu sich selbst. Würde (das zweite) # einen String beenden, müsste man, um Gleiches zu erreichen, ->#`#foo` schreiben. So ein Link zu sich selbst ist übrigens sinnvoll, wenn man Lesern erleichtern möchte zu erkennen, dass sie an eine bestimmte Stelle im Text verlinken können. Dies ist ein praktischer Nutzen, während das evtl. irritierende Verhalten bei #ein#mal eher theoretischer Natur ist.

  2. Während mehrere aneinander gekettete Hinweise normalerweise nicht erlaubt sind, zum Beispiel

    12{zwölf}{Dutzend}

    gibt es derzeit keine Fehlermeldung, wenn der erste Hinweis als „unsichtbares“ Ziel für Links dient:

    #{zwölf}{Dutzend}

    Das wird klaglos umgewandelt nach:

    <span title='Dutzend'><span id='zwxc3xb6lf' title='zwölf'></span></span>

    Ist zwar nicht schlimm und kein praktisches Problem, aber es wäre vermutlich schöner, wenn auch da dieselbe Fehlermeldung wie im ersten Fall käme.

  3. Ich habe @1 wiefolgt gelöst: # und @ sind nicht mehr semitransparent außer am Anfang eines Wortes. So werden

    @author: martin
    #ein#mal
    #the@author

    nun umgewandelt in

    <span id='ein'>ein</span><span id='mal'>mal</span><br>
    <span id='the'>the</span>martin

    Das heißt, # und @ in der Wortmitte teilen das Wort, sodass sich # am Zeilenanfang nur auf die erste Hälfte bezieht. Hingegen ist so etwas wie

    #@author und ->##foo

    weiterhin möglich, da @ und (das zweite) # am Wortanfang stehen, und wird umgewandelt in

    <span id='author'>martin</span> und <a href='#foo'><span id='foo'>foo</span></a>

  4. Ergänzund zu @3: Linkadressen werden freilich nicht durch # oder @ in der Mitte beendet. Das heißt beispielsweise,

    Schnüre->/hut#schnur

    wird weiterhin umgewandelt in

    <a href='/hut#schnur'>Schnüre</a>

  5. Ähnliches wie in @2 dargestellt wäre für eine Multiple-Choice-Option zu überdenken:

    { }{Bitte ankreuzen!}

    ergibt derzeit keinen Fehler, aber auch nicht, was man vielleicht erwarten würde. In HTML wird daraus:

    <fieldset><input type='checkbox' id='_1' value=''> <label for='_1'><span title='Bitte ankreuzen!'></span></label></fieldset>

    Der Hinweis erscheint also nicht, wenn man über dem Kästchen zum Anhaken verweilt.

  6. Bei eingebundenen Bilder kann eine versteckte Beschreibung als Argument angegeben werden, im Beispiel "Bär":

    [i:Bär]->baloo.jpg

    Bei vielen anderen Dateitypen ist das nicht möglich. Sollte es aber überall möglich sein – wenn man von [x-…] und [t-…] absieht, welche das Argument ggf. anders verwenden als für eine Beschreibung?

  7. Ich habe in @5 Beschriebenes behoben, indem nach { } für die Checkbox in einer Multiple-Choice-Liste Whitespace folgen muss. Damit gibt es auch bei { }->foo in einer Multiple-Choice-Liste keine unerwartete Ausgabe.

    Den Fall in @2 kann man dagegen vielleicht hinnehmen? Es ist wohl immer möglich, etwas zu machen, was wenig sinnvoll ist. Da braucht es nicht immer eine Fehlermeldung. Auch `12{zwölf}`{Dutzend} ergibt beispielsweise keine Fehlermeldung. Aber das wird wohl kaum jemand schreiben und als Ausgabe etwas anderes erwarten, als er erhält.

  8. David hat vorgeschlagen, für Bilder einen Textumfluss links/rechts vorgeben zu können.

  9. Als Option zur Textausrichtung könnten neben links-, rechtsbündig und zentriert auch zentrierte Absätze, die links- oder rechtsbündigen Text enhalten, hinzugefügt werden. Wenn alle Zeilen in einem solchen Absatz kürzer sind als der zur Verfügung stehende Platz, wie man es bei Gedichten oft hat, dann würde das ganze Gedicht im Stück in die Mitte rücken, obwohl die Zeilen untereinander weiterhin links oder rechtsbündig abschließen. In HTML ginge das so:

    <p style="display:table; margin-left:auto; margin-right:auto; text-align:left">…</p>

    In Aneamal könnte es mit :. bzw. .: markiert werden.

  10. Eine Markup-Alternative zu @9 wäre ::. bzw. .:: als Überlagerung von :.. bzw. ..: mit .:.

  11. David regte an, über

    [j]
    | /foo/bar.jpeg
    | /foo/mash.jpeg
    |
    | Photos von der Reise

    nachzudenken.

  12. Die Idee in @9 wird mit der Syntax von @10 umgesetzt.

    Die Idee in @8 wird mit der Übersetzung von :. in die Klassen _float _left eines <div>s, mit der Übersetzung von .: in die Klassen _float _right und mit der Übersetzung von :: in die Klasse _clear umgesetzt, wenn die Markierungen am Blockanfang stehen.

    Beide Ideen lassen sich auf beliebige Blockelemente anwenden.

  13. Man könnte eine Metadeklaration @align einführen, um mit @align: .:. auch für einen großen Bereich Ausrichtungsvorgaben mit Aneamal-Syntax machen zu können. Im Hauptdokument sollte die zugehörige Klasse dann wohl im HTML-<main>-Element gesetzt werden, nicht in <body>, wie das bei @class üblich ist.

  14. Man könnte eine HTML-Datei/Aneamal-Datei ähnlich statt wie per [h]/[a] mit einem neuen File-Token alternativ als Iframe laden, sodass es isoliert vom Rest der Seite ist und bspw. keine Styles erbt. Herausforderung: die Höhe des Frames automatisch (?) sinnvoll einstellen.

    Nutzen könnte man das zum Beispiel zur Funktionsdemo von Aneamal-Markierungen.

  15. Wenn in @meta.nml eine Sprache mit @lang festgelegt ist, wird diese in aufgerufenen Aneamal-Dateien automatisch übernommen. Per [a]-> verknüpfte Dateien erhalten aber keine automatische Sprachangabe aus derselben oder einer anderen @meta.nml-Datei, sodass die Sprache in ihnen individuell angegeben werden muss. Sollte und kann man das sinnvoll ändern?

  16. Ziehe in Betracht, für x-Module mehrere Links zuzulassen:

    [x-foo]->link1->link2->link3

    Das Modul könnte Aneamal mitteilen, wie viele Links es mindestens erwartet und wie viele es höchstens erlaubt. Idee: Kommuniziere das über die zurückgegebene Closure-Deklaration des Moduls. Während diese bisher die Form

    return function (array $_)

    hat wobei ein Link erwartet wird, könnte per

    return function (array $_, int $optional = 3, int $required = 2)

    an Aneamal kommuniziert werden, dass mindesens zwei Links erwartet werden und drei ebenfalls akzeptiert werden. Per https://www.php.net/manual/en/reflectionparameter.getdefaultvalue.php müssten sich diese Zahlen auslesen lassen. Dies wäre zwar ein missbräuchlicher/kreativer Einsatz von Funktionsparametern, denn übergeben würde an $optional bzw. $required nie etwas (die zusätzlichen Linkdaten würden mit im Array $_[0] untergebracht), aber doch elegant.

  17. Habe die Idee aus @16 für die nächste Aneamal-Version 28 implementiert, wobei die Zahl der erwarteten Links von einem x-Modul per Parameter min und max in der an den Aneamal-Kern übergebenen die Closure-Deklaration angegeben werden kann:

    return function ($_, $min = 2, $max = 3)

    Ohne Angabe von min oder max wird jeweils 1 angenommen, was dem bisherigen Verhalten entspricht.

  18. Idee: Ersetze &? automatisch durch die verwendete Aneamal-Version.

  19. @18: Statt &? enthält @version die Versionsnummer.

  20. Modulen könnte Hilfe beim Implementieren von Übersetzungen gegeben werden. Siehe dazu https://www.php.net/manual/de/book.gettext.php

  21. Module könnte eine Exception-Klasse bereitgestellt werden, um Aneamal-Fehlermeldungen auszulösen.

    Dabei könnten sie theoretisch auch einen Link zu mehr Informationen übergeben, der wie sonst auch zu Aneamal-Fehlermeldungen mit ausgegeben wird. Wenn Aneamal-eigene Fehlermeldungen allerdings keine fremden Links handhaben sollen (denn was ist, wenn die fremde Seite zwischenzeitlich einen neuen Eigentümer erhält, der darauf Schadcode verbreitet?), könnte auch gar kein Link zu mehr Informationen für diese in Modulen bewusst ausgelösten Fehler angegeben werden.

  22. @6: In Aneamal 28 wird das bei allen Typen außer [a] und [t] möglich sein, in Aneamal 29 dann auch bei jenen. Grund für die Verzögerung bei [a] und [t] ist, dass der Doppelpunkt dort früher einmal die Funktion des Bindestrichs hatte, was übergangsweise auch noch unterstützt wurde. Die Unterstützung dafür muss wie schon in Aneamal 27 angekündigt in Version 28 erst abgestellt werden, bevor der Doppelpunkt in Version 29 die Funktion erhalten kann, die er auch bei anderen Dateitypen hat.

  23. Beim Einbinden mit [a]-> könnte es nützlich sein, die Überschriftenlevel der eingebundenen Datei zu verschieben, sodass aus === darin bsp. <h2>, aus --- dann <h3> und aus - - dann <h4> wird.

  24. Ich schließe die Diskussion, da 2019 vorbei ist. Weitere Kommentare zu hier gesagtem können auf https://prlbr.de/projekt/aneamal/diskussion/2020 diskutiert werden.

  25. @21: Module können ab Aneamal 28 eine Nachricht per Aneamal-Fehlermeldung ausgeben, vorerst ohne Link. Dafür steht die Exception namens \prlbr\aneamal\ModuleMessage zur Verfügung.

  26. In Aneamal 29 wird die Sprache für verknüpfte Dateien sowie automatisch eingebundene Dateien (@header.nml etc.) genau wie bereits bei eingebetteten Dateien vom einbindenden Dokument übernommen, wenn sie in der eingebundenden Datei nicht explizit deklariert ist.

    Damit wird zwar die in @15 aufgeworfene Frage nicht bestmöglich beantwortet. Es kann nun passieren, dass eine Datei, direkt aufgerufen, eine andere Sprache per @meta.nml zugeordnet bekommt als wenn die gleiche Datei in einer anderen verknüpft wird und deren Sprache erbt.

    In der Praxis aber bedeutet das, dass in der HTML-Ausgabe keine unbekannte Sprache per Attribut lang='' mehr gesetzt wird, wenn sie nicht auch in Aneamal explizit als unbekannt gesetzt wurde. Und für die nun geerbte Sprache wird in HTML auch kein HTML-Attribut eingesetzt, da dieses nur bei abweichender Sprache vom umgebenden Text auftaucht.

    Dies ist ein zufriedenstellender Zustand.