nicht angemeldet
HTML ist hässlich!
JürgenB
Gunnar Bittersmann
Der Martin
Tabellenkalk
Matthias ApselHallo miteinander!
Also zunächst mal, bitte entschuldigt den reißerischen Titel, aber das musste mal raus! ;-)
Jedenfalls, was mich mal interessieren würde: Gibt es hier noch jemanden, der HTML zu schreiben als ebenso qualvoll empfindet wie ich es tue, oder betrifft mich das allein?
Ich meine, trotz vieler Rückschläge bin ich doch immer darin bestrebt, meinen Code nach Möglichkeit nicht nur inhaltlich korrekt zu schreiben, sondern gleichfalls dafür zu sorgen, dass er auch gewissen Ansprüchen hinsichtlich der formalen Übersichtlichkeit und Ästhetik genügt.
Nun lässt sich natürlich anstrengungslos zum Beispiel auch in JavaScript oder irgendeiner anderen Programmiersprache hässlicher und unübersichtlicher Code schreiben, aber zumindest ist es in diesen Sprachen in der Regel ebenso möglich, elegant zu formulieren und den Code in eine übersichtliche und zuweilen sogar ästhetisch ansprechende Form zu bringen.
Aber die Syntax von HTML und anverwandter Auszeichnungssprachen widersetzt sich hartnäckig jedem Versuch, diesem Anspruch auf Klarheit und vielleicht sogar Schönheit auch nur annähernd gerecht zu werden!
Es ist wirklich deprimierend!
Sogar CSS Code lässt sich, wenn schon nicht schön im engeren Sinne, so doch immerhin übersichtlich und wenigstens den minimalen ästhetischen Ansprüchen genügend formatieren, aber wenn ich HTML schreibe, sieht der Code am Ende immer irgendwie kacke aus, ganz gleich für welchen Stil der Notation ich mich entscheide.
Es scheint wirklich egal zu sein, wie ich es drehe und wende: Ich finde einfach keine akzeptable Schreibweise, die sowohl dokumentweit einheitlich und konsistent ist, darüber hinaus aber auch in jeder Situtation zu übersichtlichem und gut aussehendem Code führt.
Ich meine, beispielhaft könnte man den Inhalt des head Elementes auf folgende Weise notieren:
<head>
<meta charset = "utf-8">
<title> Seitentitel </title>
<meta http-equiv = "expires"
content = "0">
<meta name = "viewport"
content = "width = device-width, initial-scale = 1.0">
<link rel = "stylesheet"
href = "style/layout.css">
<meta name = "description"
content = "Blafasel">
</head>
Das schaut einigermaßen hübsch und übersichtlich aus.
Wollte man nun aber die gleichen Regeln zum Beispiel auf ein Navigationsmenü oder irgendeine andere Liste anwenden, selbst wenn man sie für diesen konkreten Fall ein wenig anpassen würde, dann käme am Ende immer irgendetwas heraus, was entfernt an die Aufzeichnungen eines Seismographen auf Endlospapier erinnert!
Überhaupt bereiten mir Listen jeder Art die größte Pein, und es wird dadurch nicht besser, dass wenn man die Inhalte semantisch korrekt auszeichnen möchte, man an jeder Ecke über textuellen Inhalt stolpert, der eigentlich in irgendeiner Form von Liste untergebracht werden sollte...
Man hat offenbar wirklich nur die Qual der Wahl:
Entweder man packt alles was an Attributen so dazu gehört, der allem Anschein nach allgemeinen Konvention gemäß in eine Zeile, angereichert mit dem ein oder anderen Schachtelelement, was in der Regel dann zu absurd breiten Zeilen führt und einem hässlichen und schwer lesbaren Codeblock (mit Betonung auf block).
Oder man fügt freudig Leerzeilen und -zeichen ein, in der Hoffnung dadurch ein klareres Bild des Codes zu erzeugen, was dann aber wiederum in vielen Situationen zu einer zu starken Zergliederung und mithin das Ansinnen höchstselbst ad absurdum führt.
Wie soll man es also damit halten?
Abstumpfen? Resignation? Die vier Stadien der Bewältigung? Eine bessere Syntax entwerfen und eine Art Präprozessor für HTML basteln? lol
Oder gibt es irgendeine Form von goldenem Schnitt, den ich bloß noch nicht gefunden habe?
Würde mich freuen, eure Meinung dazu zu hören!
Beste Grüße,
var ♂
-
Hallo
Wie soll man es also damit halten?
vielleicht einfach auf die vielen Leerzeilen verzichten und weniger einrücken:
<head> <meta charset = "utf-8"> <title> Seitentitel </title> <meta http-equiv = "expires" content = "0"> <meta name = "viewport" content = "width = device-width, initial-scale = 1.0"> <link rel = "stylesheet" href = "style/layout.css"> <meta name = "description" content = "Blafasel"> </head>Gruß Jürgen
-
Hallo Jürgen
Vielleicht einfach auf die vielen Leerzeilen verzichten und weniger einrücken:
<head> <meta charset = "utf-8"> <title> Seitentitel </title> <meta http-equiv = "expires" content = "0"> <meta name = "viewport" content = "width = device-width, initial-scale = 1.0"> <link rel = "stylesheet" href = "style/layout.css"> <meta name = "description" content = "Blafasel"> </head>Ja, so ähnlich sehen HTML-Quelltexte üblicherweise aus, aber findest du sowas echt übersichtlich oder gar ästhetisch?
Ich denke, das Grundproblem mit der HTML-Syntax ist, dass sie nicht nur ein statisches Dokument erzeugt, sondern auch selbst statisch ist, was aber natürlich auch Vorteile mit sich bringt, wie man meinen sollte, etwa bei der Geschwindigkeit, mit der solcher Quelltext geparst werden kann.
Aber andererseits glaube ich, und man möge mich korrigieren wenn ich damit falsch liege, dass die Verarbeitung von Quelltext - zumindest heutzutage - in der Regel nicht der Flaschenhals ist, wenn es um die Geschwindigkeit geht mit der ein Dokument auf den Bildschirm gebracht wird, sondern wenn es daran hapert werden wohl eher eine schlechte Internetverbindung, eingebundene Bild- oder Videodateien oder von verschiedenen Quellen geladene externe Skripte und Ähnliches daran schuld sein, so dass eine flexiblere Art des Markups, richtig Umgesetzt, kaum ins Gewicht fallen dürfte.
Ich meine, spinnen wir doch mal etwas rum und spielen wünsch dir was! ;-)
Wie wäre es alternativ mit einer Mischung aus ECMAScript Objekt-Literal-Syntax und CSS-Selektoren (natürlich plus HTML-spezifische Features), also etwas in der Art von...
{ html | lang : 'de' } { title | 'Seitentitel' } { meta & charset : 'utf-8' & expires : '0' & description : 'Lorem ipsum dolor sit amet' & author : 'Name' } { meta & viewport : { width : 'device-width', initial-scale : '1.0' } } { link & stylesheet | 'style/layout.css' & stylesheet | 'style/default.css' } { body + header + nav + ul | + li + a : { 'url' | 'Beschreibung' } + li + a : { 'url' | 'Beschreibung' } } { body > header + h1 : 'Überschrift' ~ [0] } { body + main | role : 'main' | + h2 : 'Überschrift' + { article | name : 'Lorem ipsum' } } { body > main > article | + h3 : 'Überschrift' + p + i : 'Lorem ipsum dolor' + p : ( #Text ) } { #Text | Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. } { body + footer + a : { 'url' | 'Impressum' } }...naja, Spinnerei! :-)
Jedenfalls Dank und Gruß,
var ♂
-
Wo genau siehst du den Vorteil deines Vorschlags? Mit den | und & Zeichen kann ich auf Anhieb nichts anfangen. Ich kann mir denken dass der Text ein "titel" sein soll, wenn "titel" davor steht. | bzw. & liest ein Programmierer als oder / und. Hilfreich ist das nicht ganz, ein = hat da schon mehr Bedeutung. Ich würde wetten hier spielt die subjektive Komponente eine sehr große Rolle, dein Vorschlag gefällt dir wahrscheinlich deshalb so gut weil er von dir ist :-)
Ich finde das von dir gezeigte HTML jedenfalls nicht weniger übersichtlich als deinen anderen Vorschlag. Vor allem mit Syntaxhighlighting erkennt man worum es sich handelt. HTML Tags mit etlichen Attributen gibt es praktisch nicht, da sehe ich auch kein Problem wenn 2 oder 3 in einer Zeile stehen. Außerdem finde ich es durchaus sinnvoll wenn ein langes Element (<p> sehr sehr sehr viel Text über viele viele Zeilen</p>) nicht mit einem neutralen Abschlusszeichen endet sondern ausdrücklich mit dem Elementnamen.
Vielleicht hilft dir das alles ja ein bisschen, mit der ungeliebten Syntax doch etwas mehr Frieden zu schließen.
-
@@encoder
HTML Tags mit etlichen Attributen gibt es praktisch nicht
Nicht?
<article lang="en" vocab="http://schema.org/" resource="http://och-teatr.example/events/hamlet" typeof="Event" ><span property="address" typeof="PostalAddress" resource="_:postalAddress" ><span property="name" lang="pl" translate="no" >LLAP 🖖
--
Ist diese Antwort anstößig? Dann könnte sie nützlich sein.-
Hallo,
diese Schreibweise ist zwar sehr übersichtlich, aber da sie sehr viele Zeilen benötigt, passt „fast nichts“ auf den Bildschirm und so geht die Übersicht verloren. Ich bin ein Freund von „Einzeilern“, Leerzeilen verwende ich gerne, um logische Blöcke zu trennen.
Gruß Jürgen
-
@@JürgenB
diese Schreibweise ist zwar sehr übersichtlich, aber da sie sehr viele Zeilen benötigt, passt „fast nichts“ auf den Bildschirm und so geht die Übersicht verloren.
Das hängt vom Bildschirm ab. Zum Programmieren hab[^1] ich den Monitor immer hochkant gedreht.
Dreiundzwölfzig Zeichen in der Breite braucht man nicht, aber mehr Zeilen auf dem Schirm zu haben, schafft Übersicht.
LLAP 🖖
--
Ist diese Antwort anstößig? Dann könnte sie nützlich sein. [^1]: Eher hatte. Zu Zeiten, als ich noch Rechner mit externem Monitor hatte.
-
-
HTML Tags mit etlichen Attributen gibt es praktisch nicht Nicht?
Ich sehe nur vier Attribute, aber längst nicht "etliche". Daher würd ich sagen: sieht nicht danach aus ;-)
-
@@Encoder...
Ich sehe nur vier Attribute, aber längst nicht "etliche". Daher würd ich sagen: sieht nicht danach aus ;-)
Natürlich kommen noch einige hinzu:
classmit etlichen Klassen. Zum Stylen natürlich. Nicht. (Folien 19—21)LLAP 🖖
--
Ist diese Antwort anstößig? Dann könnte sie nützlich sein.
-
-
-
-
Moin,
Vielleicht einfach auf die vielen Leerzeilen verzichten und weniger einrücken:
gute Idee. Vor allem die vielen Leerzeilen und Zeilenumbrüche stören mich auch.
<head> <meta charset = "utf-8"> <title> Seitentitel </title> <meta http-equiv = "expires" content = "0"> <meta name = "viewport" content = "width = device-width, initial-scale = 1.0"> <link rel = "stylesheet" href = "style/layout.css"> <meta name = "description" content = "Blafasel"> </head>Ja, so ähnlich sehen HTML-Quelltexte üblicherweise aus, aber findest du sowas echt übersichtlich oder gar ästhetisch?
Ja, übersichtlicher als dein Vorschlag auf jeden Fall. Denn Leerzeilen schaffen eine optische Gliederung, indem sie Teile des Quelltexts visuell voneinander trennen. Bei dir trennen sie aber auch Teile, die eigentlich zusammengehören, etwa Attribute ein- und desselben Elements. Das macht es IMO unübersichtlich, und so verunstaltet finde ich HTML tatsächlich auch hässlich.
Ich bin eher der Ansicht, dass jede Zeile einem gedanklichen Schritt entsprechen sollte, so halte ich es auch in Programmiersprachen wie Javascript, PHP oder C. Daher würde ich Start-Tags und ihre Attribute in der Regel in einer Zeile zusammenhalten, bei sehr kurzem Elementinhalt sogar das gesamte Element mit Start-Tag, Inhalt und End-Tag.
Und ich würde Leerzeilen innerhalb eines logischen Blocks vermeiden, denn sie schaffen eine optische Zäsur, wo eigentlich keine sein soll.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.
So long,
Martin
-
-
@@JürgenB
vielleicht einfach auf die vielen Leerzeilen verzichten und weniger einrücken:
<head> <meta charset = "utf-8"> <title> Seitentitel </title> <meta http-equiv = "expires" content = "0"> <meta name = "viewport" content = "width = device-width, initial-scale = 1.0"> <link rel = "stylesheet" href = "style/layout.css"> <meta name = "description" content = "Blafasel"> </head>Attributname und -wert desselben Attributs sind visuell stärker getrennt als verschiedene Attribute voneinander.
Vielleicht einfach auf die Leerzeichen um die
=verzichten.LLAP 🖖
--
Ist diese Antwort anstößig? Dann könnte sie nützlich sein.-
Hallo Gunnar,
Vielleicht einfach auf die Leerzeichen um die
=verzichten.mach ich normalerweise auch, hier habe ich nur aus dem Beispiel von Var die Leerzeilen entfernt.
Gruß Jürgen
-
-
-
@@var
Eine bessere Syntax entwerfen und eine Art Präprozessor für HTML basteln? lol
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?
LLAP 🖖
--
Ist diese Antwort anstößig? Dann könnte sie nützlich sein. -
@@var
Das schaut einigermaßen hübsch und übersichtlich aus.
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).<head> <meta charset = "utf-8" /> <title> Seitentitel </title> <meta http-equiv = "expires" content = "0" /> <meta name = "viewport" content = "width = device-width, initial-scale = 1.0" /> <link rel = "stylesheet" href = "style/layout.css" /> <meta name = "description" content = "Blafasel" /> </head>LLAP 🖖
--
Ist diese Antwort anstößig? Dann könnte sie nützlich sein.-
Hallo,
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).Und dann noch alle Gleichzeichen untereinander:
<head> <meta charset = "utf-8" /> <title> Seitentitel </title> <meta http-equiv = "expires" content = "0" /> <meta name = "viewport" content = "width = device-width, initial-scale = 1.0" /> <link rel = "stylesheet" href = "style/layout.css" /> <meta name = "description" content = "Blafasel" /> </head>Und dann kann auch bald HTML-Seiten mit einem Tabellenkalkulationsprogramm schreiben...
Gruß
Kalk-
@@Tabellenkalk
Und dann kann auch bald HTML-Seiten mit einem Tabellenkalkulationsprogramm schreiben...
Dau machst deinem Namen alle Ehre.
LLAP 🖖
--
Ist diese Antwort anstößig? Dann könnte sie nützlich sein. -
Tach!
Code muss lesbar sein und kein Kunstwerk.
Und dann noch alle Gleichzeichen untereinander:
Eine solche Formatierung ist in meinen Augen der größte Formatierunsinn. Da ist selbst die Platzverschwendung durch Extrazeilen für Klammern harmlos.
Die so formatierten Zeilen bilden statt dieser nunmehr Blöcke - einer links, einer rechts. Damit bilden diese Blöcke optische Einheiten und der eigentliche Zusammenhang von Schlüssel und Wert geht verloren. Und das desto mehr je weiter der Abstand ist.
Noch ein Wort zu den Klammern: Dass der Coding Style, öffnenden Klammern eine separate Zeile zu spendieren, eine Menge Platz frisst, ist auch bei den Schöpfern von Entwicklungsumgebungen angekommen. Im Visual Studio beispielsweise gibt es eine Option, solche nicht sinntragenden Zeilen in der Zeilenhöhe und Fontgröße zu verkleinern. Das ergibt ein Wasch-mich-aber-mach-mich-nicht-nass-Paradoxon.
dedlfix.
-
-
-
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 ♂
-
Tach,
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?notwendig ist es wenn du das HTML auch als XML verarbeiten willst; der Slash wird in HTML5 als Element schließend betrachtet, und ist entsprechend erlaubt, wenn das Element _empty_sein darf. Ich schreibe es aus der Zeit von XHTML immer noch so, aber es ist nicht nötig und muss auch nicht konsequent sein, solange man kein valides XML erzeugen will.
mfg
Woodfighter -
Hallo var,
& ich will | keine Tabelle!
& Du willst | keine Tabelle?
Bis demnächst
Matthias--
Signaturen sind bloed (Steel) und Markdown ist mächtig.-
Hallo Matthias
& ich will | keine Tabelle!
& Du willst | keine Tabelle?
Nein, | keine Tabelle.
Irgendwann raff' ich's... ;-)
Dank und Gruß,
var
-
-
@@var
@Gunnar ( Sonntagmorgen um 7:57 Uhr, echt!? D-: )
Der frühe Vogel … kann mich mal.
[Haml] Klingt interessant, aber wirklich hübsch schaut das auch nicht aus und ist zudem Whitespace-sensitiv: Noch mehr pain in the ass... ;-)
Finde ich auch. Weshalb ich auch die SCSS-Syntax der Sass-Syntax vorziehe.
Aber irgendwie muss man die Hierarchie ja codieren:
-
Einrückungen. Willst du nicht. (Ich auch nicht.)
-
Start- und End-Tags. Willst du nicht.
-
Klammern. Das wäre dann sowas wie JSON. Wäre etwas kürzer als Tags (Elementbezeichner wird nicht im End-Tag nochmal wiederholt), aber nichts grundlegend anderes.
{ "html": { "lang": "en", "#": [ "head": { "#": [ "meta": { "charset": "utf-8" }, "title": { "#": "Sample page" } ] }, "body": { "#": [ "h1": { "#": "Hello world" } ] } ] } }Auch nicht wirklich übersichlich.
Gerade die Wiederholung des Elementbezeichners im End-Tag macht HTML-Code (XML etc.) für Menschen besser lesbar.
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.
Wie willst du eine Baumstruktur sonst codieren?
In RDF gäbe es die Möglichkeit, durch Attribute auszudrücken, dass getrennte Einträge an verschiedenen Stellen im Code denselben Knoten betreffen. Aber übersichtlicher wird Quelltext dadurch auch nicht.
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?
Das Entwicklerwerkzeug deines Browsers stellt dir das DOM richtig eingerückt als Baumstruktur dar – egal wie dein HTML-Quelltext formatiert ist.
LLAP 🖖
--
Ist diese Antwort anstößig? Dann könnte sie nützlich sein.-
Hallo Gunnar
Wie willst du eine Baumstruktur sonst codieren?
Naja, man kann ein hierarchisches Verhältnis wie in HTML implizit ausdrücken, in dem man die Kindelemente innerhalb der Tags oder Klammern des Elternelementes notiert, aber man könnte dies ja auch explizit machen, beispielsweise indem man einem selektierten Element mit einer Anweisung / einem Operator, zum Beispiel mit dem Pluszeichen, ein Kindelement zuweist (wobei die Selektierung der Elemente analog zur Syntax in CSS erfolgen könnte).
Also, nehmen wir beispielsweise mal die folgende Struktur...
<body> <header> <h1>Hello World!</h1> <h2>Hello Spencer!</h2> </header> </body>...dann könnte ich die selben Informationen theoretisch auch so darstellen...
// { [Selektor] + neues Element } { [body] + header } { [body > header] + h1, h2 } { [body > header > h1] ('Hello World!') } { [body > header > h2] ('Hello Spencer!') } // oder wahlweise wie bisher { [body] + header { + h1 ('Hello World!'), + h2 ('Hello Spencer!') } }Auf die Art würde man sich von dem Zwang lösen, die Struktur 1:1 abbilden zu müssen, und hätte die Möglichkeit, unabhängig von formalen Zusammenhängen, auch inhaltliche Zusammenhänge korrekt darzustellen, wie in dem Beispiel am Ende meines Beitrags auf den sich deine Antwort bezieht.
Die Idee ist also, auch innerhalb des HTML-Dokumentes Elemente nicht nur deklarieren zu können, sondern sie eben auch selektieren zu können.
Letztlich ist das HTML-Dokument ja ohnehin nur die Informationsgrundlage für den Browser, von der ausgehend er dann seine Repräsentation des DOM erstellt, welche wiederum nach dem Einlesen etwaiger Skripte gegebenenfalls nicht mehr viel mit dem Ausgangsdokument gemein hat.
Ich sehe also nicht, warum der Code zwingend implizit die Struktur abbilden muss.
Zwar ist die Syntax meiner Beispiele für alternative Schreibweisen, die ich hier bislang gepostet habe, zweifellos stark verbesserungswürdig, aber ich hoffe meinen Grundgedanken konnte ich jetzt irgendwie verständlich machen! ;-)
Beste Grüße,
var ♂
-
@var
...dann könnte ich die selben Informationen theoretisch auch so darstellen...
Naja, in diesem Fall nicht die selben Informationen, da der Kindselektor
>ja alle Kindelemente eines Typs selektiert, das heißt man müsste hier sowas wie[ body > header[0] ]schreiben.Aber das nur nebenbei. ;-)
Gruß,
var
-
-
-
