Dank an alle!

[var]

Hallo miteinander!

Also erstmal vielen Dank für die zahlreichen Antworten!

Dazu noch ein paar Anmerkungen meinerseits (chronologisch):

@Gunnar ( Sonntagmorgen um 7:57 Uhr, echt!? D-: )

Du wirst lachen, aber du du bist nicht der erste, der diesen Gedanken hegt. „Auszeichnungssprachen sollten schön sein“ Vielleicht ist ja Haml was für dich?

Klingt interessant, aber wirklich hübsch schaut das auch nicht aus und ist zudem Whitespace-sensitiv: Noch mehr pain in the ass... ;-)

Wenn, dann würde ich jedem Attribut eine eigene Zeile spendieren (nicht das erste hinter den Elementbezeichner setzen) und auch dem Tag-schließenden > bzw. /> (macht man ja mit } in Programmiersprachen auch).

Das schaut gar nicht so übel aus, wobei...

  <a
    href = "http://www.example.org"
  >
    www.example.org
  </a>

...auch wieder irgendwie merkwürdig aussieht.

By the way, /> bei Elementen, die nur aus einem Tag bestehen: Ist das HTML5-konform oder sogar Pflicht oder wenigstens empfehlenswert? Hab das bislang immer ohne Slash geschrieben, sollte ich das ändern?

Vielleicht einfach auf die Leerzeichen um die = verzichten.

Ja, wenn man alle Attribute in eine Zeile schreibt ist das echt empfehlenswert, es sei denn, man möchte zwischen Attributwert und dem darauf folgenden Bezeichner zusätzliche Leerzeichen Einfügen, was die Zeile dann aber natürlich noch breiter werden lässt.

@Tabellenkalk ( 9:35 Uhr )

Und dann noch alle Gleichzeichen untereinander

Nah! ;-) Das einzige Beispiel, das mir einfällt, wo mir das mal sinnvoll erschien, war bei JavaScript-Funktionen im Zusammenhang mit Matrix-Transformationen:

var identityMat4 = function (mat4) {

  mat4[0]  = 1;   mat4[1]  = 0;   mat4[2]  = 0;   mat4[3]  = 0;
  mat4[4]  = 0;   mat4[5]  = 1;   mat4[6]  = 0;   mat4[7]  = 0;
  mat4[8]  = 0;   mat4[9]  = 0;   mat4[10] = 1;   mat4[11] = 0;
  mat4[12] = 0;   mat4[13] = 0;   mat4[14] = 0;   mat4[15] = 1;

  return mat4;

}

Ansonsten sehe ich das so, wie Dedlfix sich dazu geäußert hat.

@encoder ( 9:39 Uhr )

Mit den [oder + und] Zeichen kann ich auf Anhieb nichts anfangen.

Ich auch nicht. Besoffenes Geschwätz! - War bloß zu faul mir aussagekräftige Bezeichner einfallen zu lassen.

& ich will | keine Tabelle!

;-)

Wo genau siehst du den Vorteil deines Vorschlags?

Naja, abgesehen von der offenbar wenig durchdachten Wahl der Zeichen, war der grundsätzliche Gedanke folgender - auch auf die letzte Anmerkung in Martins Beitrag...

Ich denke, das Grundproblem mit der HTML-Syntax ist, dass sie nicht nur ein statisches Dokument erzeugt, sondern auch selbst statisch ist

So? Ich kann dir da leider nicht ganz folgen. Gilt das nicht für die meisten Markup- und Programmiersprachen? Mir fällt spontan keine ein, bei der das nicht so wäre.

...bezogen:

Was ich mit meiner ungelenk formulierten Beschreibung sagen wollte ist, dass die HTML-Sytax statisch in dem Sinne ist, dass es nur eine Möglichkeit gibt, hierarchische Beziehungen darzustellen, nämlich indem man ein Element innerhalb der Tags eines anderen Elementes notiert.

Das heißt, während es in CSS (meistens) nicht darauf ankommt, wo man etwas notiert hat, sondern was man notiert hat, ist in HTML, in Ermangelung von Syntaxelementen zu Selektierung, das wo alles entscheidend, sprich, in HTML ist die Darstellung des Codes gezwungenermaßen eine direkte Abbildung der inneren Struktur des Dokuments.

Ich meine nicht, dass man nicht die Freiheit haben sollte, es genau so zu beschreiben, aber das als einzige Option? - Und dazu noch eine, welche die Hierarchien überhaupt nur dann (leidlich) erkennbar visualisiert, wenn man die Tags entsprechend und vor allem ohne Fehler zu machen einrückt?

Ich finde eine Syntax nicht besonders ausdrucksstark, deren wesentliches Merkmal in der Darstellung von Struktur und Hierarchie liegt, und die sich andererseits aber darauf verlässt, dass der Verwender einen Editor mit Auto-Indentation verwendet oder in mühseliger Kleinarbeit darauf achtet, auch über sehr lange Passagen hinweg, bloß kein Leer- oder Tabulatorzeichen zuviel oder zuwenig zu setzen!

Dazu kommt, dass insbesondere in Zeiten von JavaScript und Single Page Applications die formale Struktur des Dokumentes nicht zwingend auch die inhaltliche Struktur widerspiegelt:

<main role="main">
    <header>
        <h2> Überschrift für A1 </h2>    <!-- display: block -->
        <h2> Überschrift für A2 </h2>    <!-- display: none -->
        <h2> Überschrift für A3 </h2>    <!-- display: none -->
        <p> Kurzbeschreibung für A1 </p>    <!-- display: block -->
        <p> Kurzbeschreibung für A2 </p>    <!-- display: none -->
        <p> Kurzbeschreibung für A3 </p>    <!-- display: none -->
    </header>
    <article name="A1">
        Text für A1    <!-- display: block -->
    </article>
    <article name="A2">
        Text für A2    <!-- display: none -->
    </article>
    <article name="A3">
        Text für A3    <!-- display: none -->
    </article>
    <footer>
        <p> Anmerkungen für A1 </p>    <!-- display: block -->
        <p> Anmerkungen für A2 </p>    <!-- display: none -->
        <p> Anmerkungen für A3 </p>    <!-- display: none -->
    </footer>
</main>

Hier ist zwar die formale Struktur korrekt dargestellt, aber die inhaltliche Struktur ist demgegenüber völlig zerstückelt und der eigentliche textuelle Inhalt seines Zusammenhangs beraubt!

body {
  + main[ role = 'main' ] {
    + header {
      + h2('Überschrift für A1'),
      + h2, + h2, + p, + p, + p
    },
    + article[ name = 'A1' ],
    + article[ name = 'A2' ],
    + article[ name = 'A3' ],
    + footer {
      +p, +p, +p
    }
  }
}


main > header > p[0] ('Kurzbeschreibung für A1');

article['A1'] ('Text für A1');

main > footer > p[0] ('Anmerkungen zu A1');


main > header > h2[1] ('Überschrift A2');

main > header > p[1] ('Kurzbeschreibung für A2');

main > article[1] ('Text für A2');

main > footer > p[1] ('Anmerkungen für A2');


// usw.

Im Gegensatz zur totalen Fokussierung auf die Gesamtstruktur des Dokuments, wäre mein Ansatz eher objekt- beziehungsweise element-orientiert, das heißt, es wäre zwar nach wie vor möglich, den Dokumentinhalt nach dem herkömmlichen Konzept zu strukturieren, aber man hätte darüber hinaus die Freiheit, auch andere Zusammenhänge darzustellen (wobei da sicherlich eine bessere Syntax möglich wäre, als ich das in diesem kleinen Beispiel hier umgesetzt habe).

Also, auch wenn die Bauchschmerzen, die ich von der HTML-Syntax bekomme, nach wie vor da sind, möchte ich trotzdem allen nochmals für ihre Beiträge danken! ;-)

Beste Grüße,

var ♂