@@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 🖖

@@Christian Kruse

Oops, etwas zu früh auf „speichern“ (was eher „abschicken“ heißen sollte) geclickt. Das wollte ich doch noch loswerden:

wenn im Gegenzug dafür dieses sinnlose setzen der Styles aufhört

Ich verstehe immer noch nicht ganz, was du für ein Problem damit hast. Ich verstehe, was ich damit für ein Problem habe: Tipparbeit, die Inline-Styles zu setzen. Aber das ist doch mein Problem, nicht deins.

Der Rahmen um Inline-Code ist da wirklich ein perfektes Beispiel, weder Matthias noch ich bestehen auf diesem Rahmen (wir hatten darüber kommuniziert, aber uns beiden war keine gute Alternative eingefallen), mir ist nur wichtig, dass er sich abhebt vom Fließtext.

Nicht den Inline-Code vom Fließtext abheben, sondern den Fließtext vom Inline-Code – durch Porportionalschrift. Problem gelöst. ;-)

LLAP 🖖

Hallo

Oh, der Jan hat mich gerade daran erinnert: Diffs gibt es schon.

-foo
+bar

Das ist ja cool. Ohne diese Vorstellung hätte es wieder keiner gewusst. :-(

Deshalb reicht es meiner Meinung nach auch nicht, für die vom Highlighter unterstützten Sprachen auf dessen Website zu verweisen, wie du es vor kurzem gegenüber @TS in einem Posting getan hast und wie es auf der Hilfeseite mit dem Link zur Seite der unterstützten Sprachen geschieht.

Dort sind nämlich nicht die Bezeichnungen, die mit der Forensoftware genutzt werden können, sondern nur die Namen der Sprachen aufgeführt. Einige Namen, wie z.B. „MoinMoin/Trac Wiki markup“ ^[1] oder eben auch „Diff files“ funktionieren aber nicht.

Meiner Meinung nach sollten wir auf der Hilfeseite im Wiki eine Liste der hier verwendbaren Sprachenkürzel haben. Diese unterscheiden sich ja in einigen auch hier relevanten Fällen von den auf der Pygments-Seite aufgeführten Namen.

Tschö, Auge