@@Christian Kruse

Ich sehe keine Möglichkeit der Verwendung des Forums ohne Inline-Styles.

Das heisst nicht, dass es keine gibt.

Ja, gibt es: Nutzer erhalten die Möglichkeit, ihre Beiträge nicht nur mit Markdown einzugeben, sondern wahlweise auch in HTML. Wäre das sinnvoll?

Ich behaupte mal ganz keck: Solange man auf Markdown beschränkt ist, werden Inline-Styles (zumindest in Form von präsentationsbezogenen Klassen) im Spiel sein. Und das wäre in dem Fall auch nicht so schlimm. Es geht hier um die Formatierung der Beiträge, nicht um semantisch 100%ig korrekte Auszeichnung. Für letzteres wäre oben genannte Möglichkeit zu schaffen, wenn man denn will.

Die richtige Lösung wäre, eine Markdown-Erweiterung zu schaffen, die es erlaubt, span-Elemente zu erzeugen. War es das, was du im Sinn hast?

Ich hatte gar nichts im Sinn, denn bis gerade war ich mir nicht im klaren darüber, dass diese Anforderung besteht.

Angenommen, sie tut es. Wäre sowas wie *foo*[span] denkbar, was nicht <em>foo</em>, sondern <span>foo</span> generiert?

Ansonsten muss man halt font-style bzw. font-weight auf inherit (oder normal) setzen. Dafür könnte man auch eine Klasse "normal-font" bereitstellen Nein, man müsste eine Klasse foreign-language oder sowas setzen bei Elemente, die einen @<lang>-Tag haben.

Du willst bei *foo*{: @und} also <em lang="und" class="foreign-language">foo</em> generieren und

  .foreign-language
  {
    font-style: inherit;
    font-weight: inherit;
  }

im Stylesheet stehen haben? Das löst das Problem nicht, sondern verschiebt es. Was, wenn du das „foo“ doch kursiv oder/und fett haben willst?

Für Inline-Code braucht man die Möglichkeit, Zeilenumbruch innerhalb zu verhindern.

Auch hier: mir war nichtmal klar, dass es diese Anforderung gibt. Und ich verstehe auch jetzt noch nicht, warum du sie hast.

Beispiel: Inline-Code foo bar { property: value } irgendwo im Text. Man weiß also nicht, ob ein Teil davon noch in die Zeile passt.

Ein Zeilenumbruch zwischen foo bar und { property: value } wäre hinnehmbar, auch nach {. Es sollte aber nicht zwischen property: und value umbrochen werden; und keinesfalls zwischen foo und bar.

Am besten aber gar kein Zeilenumbruch in diesem Inline-Code. Der ist ja kurz genug, dass er auch bei schmalen Viewports noch in eine Zeile passt.

Andere Inline-Codes sind länger; da will man den Zeilenumbruch nicht verhindern. Der Autor braucht also eine Möglichkeit, die Präsentation zu beeinflussen – also einen Inline-Style.

Es hilft auch wenig, um der Vermeidung von präsentationsbezogenen Klassennamen Willen Klassen wie "short-line" oder "long-line" bereitzustellen, die man erst aufwendig erklären müsste, wozu sie gedacht sind (nämlich für die Präsentation). Dann doch lieber ehrlich sein und sagen: wir brauchen hier präsentationsbezogene Klassen; hier habt ihr eine: "nowrap".

Frage: Was wäre für Forumsnutzer eingängiger, eine funktionelle Klasse wie "keyword" oder eine präsentationsbezogene Klasse wie "no-border" (Inline-Style)?

Ich denke nicht, dass hier ein Inline-Style notwendig ist oder überhaupt eine Klasse. Aber ich verstehe die Bedürfnisse noch nicht genug, um da wirklich etwas zu sagen zu können.

Beispiel: dieses Posting, an dem die Diskussion hier ihren Ursprung nahm. Die vielen Rahmen in den Zeilen stören den Lesefluss.

Bei „background-Eigenschaft“ und „nav-Element“ sollte kein Rahmen erscheinen; ohne ist es besser lesbar. Es sollte aber die Möglichkeit geben, background bzw. nav als Inline-Code auszuzeichnen. Per Default hebt es sich durch dicktengleiche Schrift vom übrigen Fließtext ab, der bei mir in Proportionalschrift erscheint. (Das sollte er bei anderen auch, aber das ist eine andere Diskussion.)

header::before { height: 42px } hingegen fällt nicht in die Kategorie "keyword"; da kann durchaus ein Rahmen drum. Auch hier: Der Autor braucht also eine Möglichkeit, die Präsentation zu beeinflussen.

Ich mache einen Vorschlag. Ich schalte die style-Attribute wieder frei, wenn im Gegenzug dafür dieses sinnlose setzen der Styles aufhört und stattdessen nach Lösungen gesucht wird.

Fair enough. Ich nehm das <I> auf mich und erstelle mal ein paar Style-Regeln für Klassen, die mir sinnvoll erscheinen. Ergänzungen willkommen.

LLAP 🖖