nicht angemeldet
Hallo Tim,
über Syntax-Highlighting habe ich schon nachgedacht, bin aber noch in einem noch recht frühen Erstellungsstadium und hatte noch keine konkreten Ideen, wie dies zu realisieren wäre. Danke für Deine Anregungen, ebenso wie die für verlinkbare Codezeilen, das ist eine nette Idee. Da hätte ich mir sonst wohl die Zähne dran ausgebissen, und ein schlechtes Gewissen gehabt, wenn ich für jede Zeile ein eigenes Element eingebaut hätte. Damit hast Du mich vor vielen schlaflosen Nächten bewahrt.
Und plötzlich landet man bei Extrembeispielen wie da oben, die man nicht schreiben, sondern per Programm erzeugen lassen will.
Auch eine gute Idee. Mal sehen, wie komplex meine Codebeispiele werden, und welche Funktionalität wirklich nötig ist. Ich würde schon gerne auf softwaregenerierten Code verzichten. Menschenlesbarer und -editierbarer HTML-Code hat ja immer noch was für sich. So könnte auch jemand anders problemlos meine Dokumentation weiterführen, ohne viel Erklärung und Vorbereitung.
white-space:pre
In CSS 2.1 gibt es auch den Wert pre-wrap, experimentell wird der von Browsern schon länger implementiert.
Danke für den Hinweis.
[Erklärungen zu XHTML 2 und (X)HTML 5] Bitte keine Fragen warum, und wieso die komische Namensbenennung [...]
Keine Sorge, ich frage nicht, wenn ich schon vorgewarnt werde. ;-)
In XHTML 2 gibt es das Element <blockcode>, dass sich zu <code> so verhält wie derzeit <blockquote> zu <q>:
Also macht <blockcode> dasselbe wie <pre><code> ... </code></pre>?
Man betreibt Semantik ja nicht als blossen Scherz, sondern immer aus einem Zweck: Struktur, die der Mensch intuitiv begreift, auch für Programme begreifbar und nutzbar zu machen [...]
Je mehr man dem Benutzer bieten will (Syntax-Highlighting, anklickbare Quellcodezeilen, Anmerkungen zu einzelnen Passagen, etc.), desto schwerer lesbar wird leider auch der Quellcode. Dagegen kann man halt nichts machen.
Dabei ist eine nette Richtlinie, wie leicht oder wie schwer die Struktur es Programmen (Wie z.B. eigenen Javascript-Anwendungen) macht, das zu verarbeiten. Obiges Extrembeispiel ist zwar toll zu stylen, aber extrem hässlich in JS zu verarbeiten, wenn man nur das DOM zur Verfügung hat. Da landet man dann automatisch auf einem Mittelweg.
Idealweise hat man für jedes zusätzliche Element, das man im Baum einfügt eine Begründung.
Ich glaube, über diese Richtlinien lohnt es sich nachzudenken.
Vielen Dank und schöne Grüße
Def
Der Martin
Gernot Back