Codeblöcke – inline oder block?

Das [Old Book Theme](https://github.com/moderndragon/oldbook) schon wieder. Aber naja, ich dachte, das ist eine Notiz, die ich zumindest für mich festhalten sollte.

Eigentlich hatte ich mir gedacht, setze ich Codeblöcke doch hübsch vom Rest des Textes ab, etwa so:

Da tritt nur [ein Problemchen](https://github.com/moderndragon/oldbook/issues/9) auf…
$mensch weiß nie, wie die Leute ein Feature einsetzen werden. Ich habe ja in der Vergangenheit den code-Tag hauptsächlich als Block-Element verwendet, aber das geht ja auch als inline-Element (was ich ja auch schon so genutzt habe). Definiere ich code grundsätzlich als Blocklevel-Element, zerstört das u.U. den Text. Noch schlimmer allerdings, wenn ich es als inline-Element definiere und dann mehrzeilige Codebeispiele habe. (Davon kein Screenshot, vertraut mir, es ist gräßlich!)

Jetzt will ich aber kein Design machen, wo ich die Wahl zwischen doof und noch doofer habe.
Eigene CSS-Klassen zu definieren, ist auch keine Lösung. Irgendwann will ich vielleicht wieder ein Standard-Theme verwenden (warum auch immer), und die eigens festgelegten Klassen sind dann futsch und alles sieht wieder scheiße aus. Und wenn andere mein Theme benutzen wollen, müssen sie sich erst mit meinen CSS-Klassen vertraut machen; habe ich evtl. Mitschreiber_innen, die mit CSS nicht vertraut sind, sind eigene Klassen auch nicht so dolle… Also: Besser bei den Standards bleiben.

Ich lege also die Idee „Codeblöcke mit border und anderer Hintergrundfarbe“ erstmal ad acta, es sei denn, jemandem fällt dazu die ultimative Lösung ein.

Beiträge zu ähnlichen Themen:

  1. Neues Theme: SnowMorning

8 thoughts on “Codeblöcke – inline oder block?”

  1. Das code-Tag sollte immer als inline definiert bleiben, so ist es per default ja auch deklariert.

    Für Blöcke einfach immer pre benutzen. Mit einer zusätzlichen CSS-Klasse kannst du hier ggf. immer noch zwischen Code und sonstigem Monospace-Text unterscheiden lassen.

    Ja, du wirst in diesem Fall nicht um CSS herum kommen. Aber das machen alle anderen auch so, ist also schon Usus und hier braucht mensch sich ja nicht sträuben, es wird ja nur einmal gemacht und dann genutzt. ;o)

    Falls du die pre-Blöcke, so wie ich auch, eh nur für Code benutzt, kannst du dir die CSS-Klasse natürlich auch sparen.

    Für WordPress gibt es doch auch solche Syntax-Highlighting-Plugins, die kannst du ja ggf. auch testen/nutzen.

    TL;DR
    Das Tag code bleibt inline. Für Code-Blöcke bitte pre benutzen. Danke!

  2. Ach, was mir da noch einfällt:

    Ich bilde mir ein, auch schon solche „code pre … /pre /code“-Blöcke gesehen zu haben. An sich gefällt mir diese Form ja nicht so, aber so kannst du zumindest die CSS-Formatierung ja an den pre-Block weitervererben lassen.

    Ich habe davon Abstand genommen, weil ich ohnehin für inline-Codesnippets andere Formatierungen verwende als für Code-Blöcke.

  4. @Markus & all: Das Beispiel bestätigt genau das, was ich schrub; code für inline-Code und pre für Blöcke. Das Wiki zeigt hier sehr anschaulich diese Vorgehensweise.

  5. Super, danke für die Klarstellung, asaaki. Dann habe ich den code – Tag die ganze Zeit mißbraucht.
    Hm, mal sehen, wie ich damit jetzt umgehe… mir wird da schon was einfallen.

  6. Sematisch im HTML gesehen, gehört Code zwischen code-Elemente.

    Wenn du statt inline das Ganze als block-Element willst, verwende pre-code /code /pre

    Das ist alles.

  7. Ich muß da noch was klarstellen…

    Ja, du wirst in diesem Fall nicht um CSS herum kommen. Aber das machen alle anderen auch so, ist also schon Usus und hier braucht mensch sich ja nicht sträuben, es wird ja nur einmal gemacht und dann genutzt. ;o)

    Falls du die pre-Blöcke, so wie ich auch, eh nur für Code benutzt, kannst du dir die CSS-Klasse natürlich auch sparen.

    Also, ich meine: CSS-Klassen, die ich neu definiere, die in WordPress so nicht vorgesehen sind; Klassen, die ich dann händisch in einem Artikel verwenden müßte, die ich quasi als eigenes Süppchen neben den WP-Bordmitteln (bzw. entsprechenden Plugins) selbst geköchelt habe. Das will ich vermeiden, denn

    1. weiß da jemand, der das Theme benutzt (außer mir) nicht unbedingt, daß die da sind. Meine Güte, wer liest schon jedes README? Gastautor_innen bekommen das evtl. gar nicht mal zu Gesicht.
    2. ist das dann wieder futsch, wenn ich, k.a., irgendwann der Meinung bin, daß das Theme doch doofe Ohren hat und ich lieber TwentyEleven verwenden will. Oder ich muß da dann auch meine selbstgebrauten Klassen einpflegen.

    Eine Semi-Ausnahme: Ich verwende das Plugin FD Footnotes, und um die Fußnoten, die das erzeugt, hübsch zu formatieren, habe ich Klassen erzeugt. Aber diese Klassen bleiben ja erhalten, wenn ich das Theme wechsle, und das sieht auch ohne die Formatierung nicht vollkommen scheiße aus.

    Das meinte ich mit „eigenen CSS-Klassen“.

  8. Was die Semantik angeht, gebe ich GwenDragon recht, obwohl mir diese Doppel-Tags nicht gefallen. Und: Gerade für nicht eingewiesene Schreiber das gleiche Problem auftritt wie mit selbst definierten CSS-Klassen. Von daher hat es sich wohl tatsächlich allgemein eingebürgert, für Blöcke das pre-Tag allein zu nutzen, also ohne umschließendes code-Tag.

    Damit werden die „eigene CSS-Klassen“ obsolet, da konsistentes Handeln zwingend erforderlich ist, um über Artikel hinweg immer dieselbe Ansicht zu gewährleisten.

    Ich glaube, deswegen mag ich auch solche Auszeichnungssprachen wie Markdown ganz gerne, die durch ihr beschränktes Vokabular und ebenfalls beschränkte Syntax ein einheitliches Erscheinungsbild gewährleisten (siehe github.com).

    Das Footnotes-Plugin ist nebenbei ein schönes Beispiel für halbgare Sachen, denn: wenn du dein Theme wechselst, kann es durchaus passieren, dass du das CSS vom Footnotes anpassen wirst, damit es im neuen Theme auch wieder chic aussieht.* ;o)

    *) Ging mir des Öfteren selbst so.

Comments are closed.