Gunnar Bittersmann: Styles im Forum kaputt?

problematische Seite

Da hab ich mir alle Mühe gegeben, um in diesem Posting die störenden Rahmen zu entfernen, und dann wirkt

`background`{: style="border: none; padding: 0; background: transparent"}

nicht mehr‽

Hat das jemand unabsichtlich kaputtgemacht? Oder gar absichtlich? Hab ich die Diskussion darüber verpasst?

LLAP 🖖

--
“When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
  1. problematische Seite

    Hallo Gunnar Bittersmann,

    offensichtlich werden gar keine inline-style-Angaben mehr umgesetzt. 😟

    Bis demnächst
    Matthias

    --
    Dieses Forum nutzt Markdown. Im Wiki erhalten Sie Hilfe bei der Formatierung Ihrer Beiträge.
  2. problematische Seite

    Hallo Gunnar Bittersmann,

    Ich habe nachgefragt.

    Bis demnächst
    Matthias

    --
    Dieses Forum nutzt Markdown. Im Wiki erhalten Sie Hilfe bei der Formatierung Ihrer Beiträge.
    1. problematische Seite

      @@Matthias Apsel

      Ich habe nachgefragt.

      Und keine befriedigende Antwort erhalten. Ich mach das Ticket gleich wieder auf.

      LLAP 🖖

      --
      “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
      1. problematische Seite

        Hallo Gunnar Bittersmann,

        Ich habe nachgefragt.

        Und keine befriedigende Antwort erhalten.

        Ich war auch ein wenig traurig, vor allem, weil die Links in meiner ehemaligen Signatur nicht mehr grundsätzlich hellblau sind, aber grundsätzlich hat Christian Recht.

        Bis demnächst
        Matthias

        --
        Rosen sind rot.
        1. problematische Seite

          @@Matthias Apsel

          aber grundsätzlich hat Christian Recht.

          Nein.

          Zum einen fand ich nicht, dass die unsachgemäße(!!) Verwendung von Styles überhand genommen hätte.

          Im Gegenteil: Ich habe sie bewusst eingesetzt, um die Lesbarkeit meiner Postings zu verbessern. Der den Lesefluss störende Rahmen um Code-Keywords ist ein Beispiel.

          Ein anderes ist, dass man ja gezwungen ist, bei Sprachkennzeichnungen ein em- oder strong-Element zu generieren. Wenn man den Text gar nicht hervorheben will, muss man die Kusiv- bzw. Fettschrift auf Normalschrift setzen können.

          Nächstes Beispiel: Durchstreichungen. Wenn style="text-decoration: line-through" nicht mehr wirkt, sind unzählige Postings im Archiv nicht mehr sinnvoll lesbar.

          Die Abschaffung der Inline-Styles war ein unüberlegter Schnellschuss und sollte ASAP rückgängig gemacht werden.

          LLAP 🖖

          --
          “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
          1. problematische Seite

            Hallo Gunnar,

            Zum einen fand ich nicht, dass die unsachgemäße(!!) Verwendung von Styles überhand genommen hätte.

            Ich sprach von der Verwendung. Ob sie in deinen Augen unsachgemäß ist oder nicht ist irrelevant.

            Im Gegenteil: Ich habe sie bewusst eingesetzt, um die Lesbarkeit meiner Postings zu verbessern. Der den Lesefluss störende Rahmen um Code-Keywords ist ein Beispiel.

            Und genau das ist der Grund, warum ich sie abgeschaltet habe. Anstatt dich einzubringen und Vorschläge zur Verbesserung zu machen bist du hingegangen und hast versucht deine Vorstellungen durchzusetzen. Wenn ein Problem mit dem Styling besteht erwarte ich gerade von dir, dass du an der Verbesserung mitwirkst und nicht auf einen unsinnigen Mechanismus wie Inline-Styles zurück fällst. Das hast du trotz wirklich häufiger Aufforderung nicht getan und es hat auf andere abgefärbt, die dann in gleicher Art und Weise reagiert haben. Das führt insgesamt zu einer deutlichen Verschlechterung der Situation statt zu einer Verbesserung.

            Ein anderes ist, dass man ja gezwungen ist, bei Sprachkennzeichnungen ein em- oder strong-Element zu generieren. Wenn man den Text gar nicht hervorheben will, muss man die Kusiv- bzw. Fettschrift auf Normalschrift setzen können.

            Falsch. Es muss eine Lösung für das Problem gefunden werden. Inline-Styles sind keine Lösung.

            Die Abschaffung der Inline-Styles war ein unüberlegter Schnellschuss und sollte ASAP rückgängig gemacht werden.

            Nein und nein. Das akzeptieren der Inline-Styles ware ein unüberlegter Schnellschuss, das deaktivieren war ein durchaus überlegtes vorgehen. Dass du anderer Meinung bist sei dir unbenommen.

            Nächstes Beispiel: Durchstreichungen. Wenn style="text-decoration: line-through" nicht mehr wirkt, sind unzählige Postings im Archiv nicht mehr sinnvoll lesbar.

            Das ist ein valides Argument. Ich werde mir etwas einfallen lassen. Das wird aber nicht des reaktivieren der Inline-Styles sein. Edit: ✅ done.

            LG,
            CK

            1. problematische Seite

              @@Christian Kruse

              Zum einen fand ich nicht, dass die unsachgemäße(!!) Verwendung von Styles überhand genommen hätte.

              Ich sprach von der Verwendung.

              Ich sehe keinen Grund, die sachgemäße Verwendung einzuschränken. Für unsachgemäße Verwendung fehlen mir Belege.

              Welches Problem sollte mit der Abschaffung gelöst werden? Ein nicht bestehendes, wier mir scheint. Durch die Abschaffung werden erst Probleme geschaffen.

              Und genau das ist der Grund, warum ich sie abgeschaltet habe. Anstatt dich einzubringen und Vorschläge zur Verbesserung zu machen bist du hingegangen und hast versucht deine Vorstellungen durchzusetzen.

              Dass der Rahmen um Inline-Styles unsinnig ist, hatte ich irgendwann mal angesprochen. Auf taube Ohren gestoßen. Aber wenigstens meine Postings konnte ich besser lesbar machen. (Die von anderen hätte ich für mich per Userstylesheet auch besser lesbar machen können; aber das ist nicht Sinn der Sache.)

              Wenn ein Problem mit dem Styling besteht erwarte ich gerade von dir, dass du an der Verbesserung mitwirkst und nicht auf einen unsinnigen Mechanismus wie Inline-Styles zurück fällst. Das hast du trotz wirklich häufiger Aufforderung nicht getan

              Hab ich was verpasst?

              und es hat auf andere abgefärbt, die dann in gleicher Art und Weise reagiert haben.

              Und wo genau ist daran das Problem?

              Das führt insgesamt zu einer deutlichen Verschlechterung der Situation statt zu einer Verbesserung.

              ?? Belege?

              Ein anderes ist, dass man ja gezwungen ist, bei Sprachkennzeichnungen ein em- oder strong-Element zu generieren. Wenn man den Text gar nicht hervorheben will, muss man die Kusiv- bzw. Fettschrift auf Normalschrift setzen können.

              Falsch. Es muss eine Lösung für das Problem gefunden werden. Inline-Styles sind keine Lösung.

              Vielleicht nicht, vielleicht doch. Dann sollte aber erst eine Lösung gefunden werden (und zwar für alle von mir angesprochenen Probleme zuzüglich derer, die mir noch entgangen sind), danach kann man über die Abschaffung der Inline-Styles nachdenken.

              Die Abschaffung der Inline-Styles war ein unüberlegter Schnellschuss und sollte ASAP rückgängig gemacht werden.

              Nein und nein.

              Fürs erste: ganz klares Ja. IMHO eine Aktion, die kein Problem löst, aber welche schafft.

              Eine sinnvolle Herangehensweise wäre gewesen, das Problem zu benennen *wie gesagt, ich sehe gar keins), die Abschaffung der Inline-Styles vorzuschlagen und zu diskutieren, was das für Folgen hätte.

              LLAP 🖖

              --
              “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
              1. problematische Seite

                Hallo Gunnar,

                Ich sehe keinen Grund, die sachgemäße Verwendung einzuschränken.

                Ich sehe keine Möglichkeit sachgemäßer Verwendung von Inline-Styles.

                Durch die Abschaffung werden erst Probleme geschaffen.

                Nein, sie werden nur offensichtlich. Ich schließe einen Weg sie zu umgehen.

                Und genau das ist der Grund, warum ich sie abgeschaltet habe. Anstatt dich einzubringen und Vorschläge zur Verbesserung zu machen bist du hingegangen und hast versucht deine Vorstellungen durchzusetzen.

                Dass der Rahmen um Inline-Styles unsinnig ist, hatte ich irgendwann mal angesprochen. Auf taube Ohren gestoßen.

                Nein. Ich hatte dir die Constraints genannt (sichtbare Abhebung von Inline-Code vom Fließtext) und dich um einen Alternativ-Vorschlag gebeten. Da ist nichts mehr gekommen, das hast du dann weg-ignoriert, wie so oft wenn ich um Hilfe bitte.

                Aber wenigstens meine Postings konnte ich besser lesbar machen.

                Und genau das ist das Problem. Du deine. Eine allgemeine Verbesserung der Lage wird nicht erreicht, weder das Projekt noch die Software werden dadurch besser.

                Wenn ein Problem mit dem Styling besteht erwarte ich gerade von dir, dass du an der Verbesserung mitwirkst und nicht auf einen unsinnigen Mechanismus wie Inline-Styles zurück fällst. Das hast du trotz wirklich häufiger Aufforderung nicht getan

                Hab ich was verpasst?

                Offensichtlich. Ich habe dich (beinahe?) jedes einzelne mal, wenn du gemeckert hast, darum gebeten einen sinnvollen Gegenvorschlag zu machen. Wenn einer kam, dann nur bei deutlichem meckern und beharrlichem nachhaken.

                Das hier ist ein FLOSS-Projekt, da steckt keine Firma hinter. Ich bin auf die Mithilfe der Community angewiesen. Wenn du das nicht verstehen kannst oder willst tut es mir leid.

                und es hat auf andere abgefärbt, die dann in gleicher Art und Weise reagiert haben.

                Und wo genau ist daran das Problem?

                Hehe, hast du das tatsächlich gefragt? Du bist einer derjenigen, die die Nicht-Verwendung von Inline-Styles sehr vehement vertritt. Oder soll ich einen deiner Web-Helden heraussuchen, was er zur großflächigen Verwendung von Inline-Styles sagt?

                Das führt insgesamt zu einer deutlichen Verschlechterung der Situation statt zu einer Verbesserung.

                ?? Belege?

                Die habe ich dir genannt. Probleme werden nicht angegangen, stattdessen werden Inline-Styles verwendet. Das führt zu bekannten Problemen und nicht zu einer allgemeinen Verbesserung der Situation.

                Ein anderes ist, dass man ja gezwungen ist, bei Sprachkennzeichnungen ein em- oder strong-Element zu generieren. Wenn man den Text gar nicht hervorheben will, muss man die Kusiv- bzw. Fettschrift auf Normalschrift setzen können.

                Falsch. Es muss eine Lösung für das Problem gefunden werden. Inline-Styles sind keine Lösung.

                Vielleicht nicht, vielleicht doch. Dann sollte aber erst eine Lösung gefunden werden (und zwar für alle von mir angesprochenen Probleme zuzüglich derer, die mir noch entgangen sind), danach kann man über die Abschaffung der Inline-Styles nachdenken.

                Ich sage dazu nur eins: das hier ist meine zweite Eskalations-Stufe.

                Ich habe wirklich dein Eindruck, dass du an dieses Forum den Maßstab legst, es sollte entwickelt werden wie das Produkt einer Firma. Man meldet einen Bug oder ein Problem, oft nichtmal besonders spezifisch und überlegt, und die Firma hat sich darum zu kümmern, sie verdienen ja Geld damit.

                Nun, ich habe eine Neuigkeit für dich: da steckt keine Firma hinter. Das ist ein FLOSS-Projekt, dass in der Freizeit von Freiwilligen bearbeitet wird. Ich bin auf die Mithilfe anderer angewiesen. Die von mir oben beschriebene Vorgehensweise ist fehl am Platze. Ich gebe dir zu diesem Thema mal eine Leseliste:

                Und so weiter.

                Die Abschaffung der Inline-Styles war ein unüberlegter Schnellschuss und sollte ASAP rückgängig gemacht werden.

                Nein und nein.

                Fürs erste: ganz klares Ja. IMHO eine Aktion, die kein Problem löst, aber welche schafft.

                Deine Meinung sei dir unbenommen. Meine Intention war hier jedoch nicht Probleme zu lösen, sondern die Community dazu zu zwingen an Lösungen zu arbeiten anstatt mit Inline-Styles drum herum zu schiffen.

                LG,
                CK

                1. problematische Seite

                  @@Christian Kruse

                  Ich sehe keine Möglichkeit sachgemäßer Verwendung von Inline-Styles.

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

                  Beispiel: Sprachauszeichnung

                  Geht nur mit em-Element[1] *user experience*{: @en} (bzw. strong-Element mit **). 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?

                  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, für die im Stylesheet steht:

                  .normal-font
                  {
                    font-style: inherit;
                    font-weight: inherit;
                  }
                  

                  Was wäre damit gewonnen?

                  1. Man spart sich als Schreiber Tipparbeit. ✅
                  2. Andere Forumsnutzer könnten auch die Klasse zur Formatierung ihrer Postings verwenden. ✅

                  Beides gute Punkte. Das ist vermutlich das, was du im Sinn hast. Und da bin ich völlig bei dir.

                  Was ändert sich damit nicht? Inline-Styles. Die sind nach wie vor da. Ob nun style="font-weight: inherit" oder class="normal-font"beides sind Inline-Styles.

                  Beispiel: Codeformatierung

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

                  .nowrap
                  {
                     white-space: nowrap;
                  }
                  

                  ↑ Inline-Style.

                  Außerdem eine Klasse für Inline-Code ohne Rahmen. (Oder eine für mit Rahmen; kein Rahmen wäre vielleicht ein sinnvollerer Default, wenn keine Klasse angegeben wird.)

                  Ebenfalls Inline-Style. – Es sei denn, man benennt die Klasse nach der beabsichtigten Verwendung bspw. "keyword" mit

                  .keyword
                  {
                     border: none;
                     padding: 0;
                     background: transparent;
                  }
                  

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

                  Beispiel: Durchstreichung

                  Geht nur mit em- oder strong-Element. (EDIT: Oder mit del-Element per ~~, was semantisch aber auch meist falsch ist.) Die richtige Lösung wäre, eine Markdown-Erweiterung zu schaffen, die es erlaubt, s-Elemente zu erzeugen. War es das, was du im Sinn hast?

                  Ansonsten:

                  .line-through
                  {
                    text-decoration: line-through;
                  }
                  

                  ↑ Inline-Style. Und nicht vergessen, das mit dem Inline-Style "normal-font" zu kombinieren.

                  Ich hatte in Postings auch schon Änderungen wie in Diff-Tools mit rotem bzw. grünem Hintergrund versehen. Sollen dafür auch noch Inline-Style-Klassen geschaffen werden? Man kann aber nicht alles vorhersehen.

                  Wie gesagt, solche Klassen sind hier fürs Forum sicher eine gute Idee. Und wenn diese dann Verwendung finden, stört es auch nicht, wenn man mit {: style="…"} zusätzliche Möglichkeiten in die Hand bekommt. Wenn sich herausstellt, dass eine Formatierung öfter gebraucht wird, wird dafür eine weitere Klasse bereitgestellt.

                  Das ist IMHO der Weg, den wir gehen sollten. Nicht restriktive Wegnahme vorhandener Möglichkeiten.

                  LLAP 🖖

                  --
                  “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory

                  1. Da sich Keywords in dicktengleicher Schrift momentan nicht mehr stylen lassen, muss ich dafür Fettschrift missbrauchen. Tut mir leid. ↩︎

                  Folgende Beiträge verweisen auf diesen Beitrag:

                  1. problematische Seite

                    Hallo Gunnar,

                    Ich sehe keine Möglichkeit sachgemäßer Verwendung von Inline-Styles.

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

                    Das heisst nicht, dass es keine gibt.

                    Beispiel: Sprachauszeichnung
                    Geht nur mit em-Element[^keywords] *user experience*{: @en} (bzw. strong-Element mit **). 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. Eine Markdown-Erweiterung dafür macht vermutlich wenig Sinn, denn…

                    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, für die im Stylesheet steht:

                      .normal-font
                      {
                        font-style: inherit;
                        font-weight: inherit;
                      }
                    

                    Nein, man müsste eine Klasse foreign-language oder sowas setzen bei Elemente, die einen @<lang>-Tag haben. Einerseits entfernt es die Notwendigkeit überhaupt etwas beachten zu müssen und andererseits hast du damit kein präsentationsbezogenes CSS.

                    Beispiel: Codeformatierung
                    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.

                    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: Durchstreichung
                    Geht nur mit em- oder strong-Element.

                    Ja. Nein.

                    Das ist IMHO der Weg, den wir gehen sollten. Nicht restriktive Wegnahme vorhandener Möglichkeiten.

                    Das ist der Weg, den ich versucht habe zu gehen, aber der dazu geführt hat, dass immer mehr style="" gesetzt wurde und immer weniger kommuniziert wurde.

                    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. Denn das ist alles, was ich damit erreichen will (und was ganz offensichtlich auch gut geklappt hat: dieses Posting war ausgesprochen konstruktiv!). 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.

                    LG,
                    CK

                    1. problematische Seite

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

                      --
                      “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
                      1. problematische Seite

                        Hallo Gunnar,

                        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.

                        Ich habe gerade nicht genug Zeit um auf alles einzugehen, was du geschrieben hast; das kommt vermutlich in der Mittagspause. Aber bevor du dir hier Arbeit machst: denk bitte out of the box. Hör auf in Klassen zu denken und fang an darüber nachzudenken, was du eigentlich wirklich erreichen willst. Beispiel: du möchtest kein normal-font, sondern du möchtest eine Möglichkeit ungestyled Sprachangaben zu verfassen.

                        LG,
                        CK

                        1. problematische Seite

                          @@Christian Kruse

                          denk bitte out of the box.

                          Du meinst: beyond tellerrand? 😉

                          Sieht man sich mal wieder auf Klassenfahrt?

                          LLAP 🖖

                          --
                          “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
                      2. problematische Seite

                        Hallo Gunnar,

                        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.)

                        War da nicht das Problem, dass in alten Beiträgen im Fließtext mit ASCII-Art und Code gearbeitet wurde? Ab der Umstellung auf die 4er hat man dafür ja – wenn überhaupt – sowieso die Codeblöcke benutzt, weil ASCII-Art mit Markdown kein Zuckerschlecken ist. Man müsste also wie bei der Geschichte mit dem style-Attribut eine Weiche einbauen, die sich am Datum des Beitrags orientiert...

                        Ich habe nichts gegen Änderungen, sehe es aber kritisch, wenn dadurch Beiträge kaputt gemacht werden, die unter anderen Voraussetzungen geschrieben wurden.

                        Gruß
                        Julius

                        --
                        „Unterschätze niemals die Datenübertragungsrate eines mit Bändern vollgeladenen Kombis, der über die Autobahn rast.“
                        Andrew S. Tanenbaum (Quelle)
                    2. problematische Seite

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

                      --
                      “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
                      1. problematische Seite

                        Hallo Gunnar,

                        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.

                        Ich habe doch erklärt, was ich für ein Problem damit habe. Es werden unsinnigerweise style-Attribute gesetzt und die Software wird nicht besser weil nicht an den Problemen gearbeitet wird.

                        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ßtest abheben, sondern den Fließtext vom Inline-Code – durch Porportionalschrift. Problem gelöst. ;-)

                        Selbst wenn man hier proportionale Schriften verwendet (mir ist das egal): Nein, die Abhebung durch eine diktengleiche ist kaum wahrnehmbar.

                        LG,
                        CK

                        1. problematische Seite

                          @@Christian Kruse

                          Es werden unsinnigerweise style-Attribute gesetzt

                          Hm, die Unsinnigkeit liegt im Auge des Betrachters.

                          Aber wegen den zwei ✅ eine Lösung anzustreben, die noch sinnvoller ist[1], gerne.

                          Selbst wenn man hier proportionale Schriften verwendet (mir ist das egal): Nein, die Abhebung durch eine diktengleiche ist kaum wahrnehmbar.

                          Auch die Abhebung liegt im Auge des Betrachters. Mir würde sie genügen, aber da kann man gern auch farblich noch etwas mehr nachhelfen.

                          LLAP 🖖

                          --
                          “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory

                          1. Das habe ich doch sprachlich geschickt hinbekommen, oder? ;-) ↩︎

                  2. problematische Seite

                    Hallo Gunnar,

                    Ich hatte in Postings auch schon Änderungen wie in Diff-Tools mit rotem bzw. grünem Hintergrund versehen. Sollen dafür auch noch Inline-Style-Klassen geschaffen werden? Man kann aber nicht alles vorhersehen.

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

                    -foo
                    +bar
                    

                    LG,
                    CK

                    1. problematische Seite

                      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

                      --
                      Wenn man ausreichende Vorsichtsmaßnahmen trifft, muss man keine Vorsichtsmaßnahmen mehr treffen.
                      Toller Dampf voraus von Terry Pratchett

                      1. Nicht, dass damit zu rechnen wäre, dass gerade diese Sprache hier genutzt würde. ↩︎

                      1. problematische Seite

                        Hallo Auge,

                        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.

                        Was hindert dich daran, eine solche Seite anzulegen? 😃

                        Edit: und vorgeschlagen habe ich gar nichts, ich hatte seine Frage nach einer solchen Liste beantwortet 😉

                        LG,
                        CK

                        1. problematische Seite

                          Hallo

                          Was hindert dich daran, eine solche Seite anzulegen? 😃

                          Na, nichts. Der auch mir gegenüber schon vorgebrachte Einwurf, die unterstützten Sprachen ließen sich auf der Pygments-Seite ermitteln, ließ in mir die Vermutung reifen, dass eine solche Liste unerwünscht sei.

                          Tschö, Auge

                          --
                          Wenn man ausreichende Vorsichtsmaßnahmen trifft, muss man keine Vorsichtsmaßnahmen mehr treffen.
                          Toller Dampf voraus von Terry Pratchett
                          1. problematische Seite

                            Hallo Auge,

                            Na, nichts. Der auch mir gegenüber schon vorgebrachte Einwurf, die unterstützten Sprachen ließen sich auf der Pygments-Seite ermitteln, ließ in mir die Vermutung reifen, dass eine solche Liste unerwünscht sei.

                            Also, von meiner Seite aus war da kein Einwurf. Ich hatte nur eine Frage beantwortet, prinzipiell halte ich persönlich eine solche Liste in der Forums-Hilfe für sinnvoll. Ich will sie nur nicht pflegen 😉

                            LG,
                            CK

      2. problematische Seite

        @@Gunnar Bittersmann

        Ich mach das Ticket gleich wieder auf.

        Hm, geht das gar nicht?

        LLAP 🖖

        --
        “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory