Matthias Scharwies: Code-Blöcke in Markdown mit rotem Hintergrund

Servus!

@Gunnar Bittersmann hat in seinen Antworten teilweise Code-Blöcke mit fehlerhaftem Code rot eingefärbt.

Jetzt habe ich natürlich auch in der Suche nichts gefunden!

Könnt ihr mir eine solche Stelle, oder den Kramdown-Code zeigen?

TIA + Herzliche Grüße

Matthias Scharwies

--
Es gibt viel zu tun: ToDo-Liste
  1. Hi,

    test
    

    cu,
    Andreas a/k/a MudGuard

  2. Hallo Matthias Scharwies,

    Könnt ihr mir eine solche Stelle, oder den Kramdown-Code zeigen?

    Beispiel hast du ja jetzt, die fee macht eine schöne Farbe.

    Bis demnächst
    Matthias

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

      Vielen Dank euch beiden, nehme es ins Wiki auf!

      Herzliche Grüße

      Matthias Scharwies

      --
      Es gibt viel zu tun: ToDo-Liste
    2. @@Matthias Apsel

      die fee macht eine schöne Farbe.

      Fee? Nee.

      HSL macht eine schöne Farbe.

      LLAP 🖖

      --
      “I love to go to JS conferences to speak about how to avoid using JavaScript. Please learn CSS & HTML to reduce your JS code bloat.” —Estelle Weyl
  3. @@Matthias Scharwies

    @Gunnar Bittersmann hat in seinen Antworten teilweise Code-Blöcke mit fehlerhaftem Code rot eingefärbt.

    Jetzt habe ich natürlich auch in der Suche nichts gefunden!

    Könnt ihr mir eine solche Stelle, oder den Kramdown-Code zeigen?

    Du kannst in Markdown für Abschnitte (sei es *, **, _, __, ⁠`⁠) in einem nachgestellten {}-Block Attribute angeben: bspw. _en vogue_{: lang="fr"} ergibt <em lang="fr">en vogue</em>.

    Für Klassen gibt es eine Abkürzung: **wichtig**{: .important} bspw. ist das Gleiche wie **wichtig**{: class="important"} und ergibt <strong class="important">. Das wird bei Inline-Code für die language-…-Klassen so verwendet.

    Als Attribut kann auch ein Inline-style-Attribut verwendet werden: __rebeccapurple__{: style="background: rebeccapurple; color: white"} ergibt <strong style="background: rebeccapurple; color: white"> und wird als rebeccapurple gerendert.

    Bei Markdown-Blöcken steht der {}-Block in einer neuen Zeile:

    ~~~markdown
    # The color rebeccapurple #
    ~~~
    {: style="background: rebeccapurple; color: white"}
    

    wird gerendert als

    # The color rebeccapurple #
    

    Wie man an der Trennlinie sieht, geht das auch bei Trennlinien.


    Überlegung:

    Da man™ rot hinterlegten Quelltext ja wie festgestellt doch desöfteren braucht, sollte man dafür vielleicht eine Klasse vorsehen und die Regel in Forums-Stylesheet schreiben:

    .bad { background-color: hsl(0, 100%, 95%) }
    

    Dann kann man einfach `schlechtes Beispiel⁠`⁠{: .bad} bzw.

    ~~~
    schlechtes Beispiel⁠
    ~~~
    {: .bad}
    

    verwenden und es wird schlechtes Beispiel mit rotem Hintergrund gerendert.

    Als Gegenstück dazu auch

    .good { background-color: hsl(120, 100%, 95%) }
    

    für ein gutes Beispiel.

    LLAP 🖖

    --
    “I love to go to JS conferences to speak about how to avoid using JavaScript. Please learn CSS & HTML to reduce your JS code bloat.” —Estelle Weyl
    1. Servus!

      Vielen Dank für die ausführliche Antwort!

      Da man™ rot hinterlegten Quelltext ja wie festgestellt doch desöfteren braucht, sollte man dafür vielleicht eine Klasse vorsehen und die Regel in Forums-Stylesheet schreiben:

      .bad { background-color: hsl(0, 100%, 95%) }
      

      Dann kann man einfach `schlechtes Beispiel⁠`⁠{: .bad} [...]

      verwenden und es wird schlechtes Beispiel mit rotem Hintergrund gerendert.

      Als Gegenstück dazu auch

      .good { background-color: hsl(120, 100%, 95%) }
      

      für ein gutes Beispiel.

      Das sind sehr gute Vorschläge, die man so übernehmen könnte/sollte - meint Ihr @all nicht?

      Herzliche Grüße

      Matthias Scharwies

      --
      Es gibt viel zu tun: ToDo-Liste
      1. Hallo Matthias Scharwies,

        Das sind sehr gute Vorschläge, die man so übernehmen könnte/sollte - meint Ihr @all nicht?

        Bisher sind die inline-styles absichtlich nicht im Wiki gelandet. Um quietschbunten Beiträgen und Meinungsäußerungen durch riesige Buchstaben vorzubeugen.

        Das CSS für ein schlechtes Codebeispiel könnte/sollte übernommen werden. Dann könnte die Formatierung mit {: .bad-example} ins Wiki. Mehr imho nicht.

        Bis demnächst
        Matthias

        --
        Dieses Forum nutzt Markdown. Im Wiki erhalten Sie Hilfe bei der Formatierung Ihrer Beiträge.
        1. Bisher sind die inline-styles absichtlich nicht im Wiki gelandet. Um quietschbunten Beiträgen und Meinungsäußerungen durch riesige Buchstaben vorzubeugen.

          Ach?
          

          Sowas geht?

          1. Hallo,

            Sowas geht?

            Ja, aber im Zweifel nur kurzzeitig :)

            Gruß
            Kalk

            1. Hallo Tabellenkalk,

              Ja, aber im Zweifel nur kurzzeitig :)

              Genau.

              Bis demnächst
              Matthias

              --
              Dieses Forum nutzt Markdown. Im Wiki erhalten Sie Hilfe bei der Formatierung Ihrer Beiträge.
      2. @@Matthias Scharwies

        Das sind sehr gute Vorschläge

        Und warum kriegst du dann die Pluspunkte?

        (Nicht, dass ich welche nötig hätte. ;-))

        LLAP 🖖

        --
        “I love to go to JS conferences to speak about how to avoid using JavaScript. Please learn CSS & HTML to reduce your JS code bloat.” —Estelle Weyl
    2. @@Gunnar Bittersmann

      bspw. _en vogue_{: lang="fr"} ergibt <em lang="fr">en vogue</em>. […]

      Da man™ rot hinterlegten Quelltext ja wie festgestellt doch desöfteren braucht […]

      Und noch eine Überlegung, da man™ Sprachangaben ja wie festgestellt doch desöfteren braucht:

      Könnte man sowas wie _en vogue_{: @fr} vorsehen und der Markdown-Prozessor macht daraus ein lang-Attribut?

      Das wäre bestimmt eine Erweiterung des Markdown-Prozessors und in dessen Kern möchte man nicht rumpatchen. Bietet Kramdown an, sowas als Plugin vorzusehen?

      Wäre das machbar, @Christian Kruse?

      LLAP 🖖

      --
      “I love to go to JS conferences to speak about how to avoid using JavaScript. Please learn CSS & HTML to reduce your JS code bloat.” —Estelle Weyl
      1. Hallo Gunnar,

        Und noch eine Überlegung, da man™ Sprachangaben ja wie festgestellt doch desöfteren braucht:

        Dass man die braucht halte ich für ein Gerücht… du bist der einzige, der die „braucht” ;-)

        Könnte man sowas wie _en vogue_{: @fr} vorsehen und der Markdown-Prozessor macht daraus ein lang-Attribut?

        Vermutlich ist das ohne grössere Arbeiten möglich, ich muss mir das aber anschauen um sicher zu gehen.

        Das wäre bestimmt eine Erweiterung des Markdown-Prozessors und in dessen Kern möchte man nicht rumpatchen. Bietet Kramdown an, sowas als Plugin vorzusehen?

        Kramdown bietet keine Plugin-Schnittstelle, nur die im Rahmen von OOP vorgesehenen Möglichkeiten der Ableitung; und genau das muss ich eh schon tun, um etwa die Entity- und HTML-Parser auszuschalten.

        LG,
        CK

        1. @@Christian Kruse

          Und noch eine Überlegung, da man™ Sprachangaben ja wie festgestellt doch desöfteren braucht:

          Dass man die braucht halte ich für ein Gerücht… du bist der einzige, der die „braucht” ;-)

          Gebraucht“ ist wohl treffender.

          Ich brauche die Sprachangaben nicht, Nutzer brauchen sie. Besonders solche, die auf Screenreader angewiesen sind.

          Und wer meint, solche hätten wir hier im Forum nicht, sollte sich fragen: warum nicht?

          IIRC verwendet @Matthias Apsel Sprachangaben auch.

          LLAP 🖖

          --
          “I love to go to JS conferences to speak about how to avoid using JavaScript. Please learn CSS & HTML to reduce your JS code bloat.” —Estelle Weyl
          1. Aloha ;)

            Und wer meint, solche hätten wir hier im Forum nicht, sollte sich fragen: warum nicht?

            Just a guess, aber ich gehe davon aus, dass Webentwicklung nicht direkt zu den gewöhnlichsten Hobbies von Menschen gehört, die auf Screenreader angewiesen sind. Dementsprechend sind Fachforen zur Webentwicklung wohl auch nicht die geeignetste Umgebung, um Menschen zu finden, die auf Screenreader angewiesen sind - noch dazu wenn das betreffende Forum nicht mehrere tausend aktive Teilnehmer vorweisen kann. Es ist also nicht fragwürdig, sondern eher sehr wahrscheinlich, hier solche nicht im Forum zu haben. Frage beantwortet? ;-)

            Grüße,

            RIDER

            P.S.: Ja, ich weiß was du sagen willst, ja, du hast prinzipiell Recht damit, nein, wir brauchen keine Grundsatzdiskussion. Trotzdem ist es nicht immer zielführend, auf Prinzipien zu reiten.

            --
            Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
            # Facebook # Twitter # Steam # YouTube # Self-Wiki # Selfcode: sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[
            1. @@Camping_RIDER

              Just a guess, aber ich gehe davon aus, dass Webentwicklung nicht direkt zu den gewöhnlichsten Hobbies von Menschen gehört, die auf Screenreader angewiesen sind.

              Mir fallen auf Anhieb Marco Zehe und Léonie Watson ein. Die Webentwicklung übrigens nicht bloß als Hobby betreiben, sondern als Beruf.

              Und man sollte sich hüten, bei Nutzerm von irgendwas auszugehen:

              “When designing for The Web, your users could be anyone. Make fewer decisions about them so they can make more for themselves.”Heydon Pickering

              P.S.: Ja, ich weiß was du sagen willst, ja, du hast prinzipiell Recht damit, nein, wir brauchen keine Grundsatzdiskussion.

              Wir brauchen eine Diskussion um die Bedeutung von Barrierefreiheit. Und das ist eine Grundsatzdiskussion.

              Trotzdem ist es nicht immer zielführend, auf Prinzipien zu reiten.

              Bist du genervt? Gut.

              “Arguing with teammates over ‘bothering with accessibility’ makes me so angry.
              Every. Time.
              So. Angry.
              Yes. ‘Bother’. It’s your job.
              Jen Simmons

              LLAP 🖖

              --
              “I love to go to JS conferences to speak about how to avoid using JavaScript. Please learn CSS & HTML to reduce your JS code bloat.” —Estelle Weyl
              1. Aloha ;)

                Just a guess, aber ich gehe davon aus, dass Webentwicklung nicht direkt zu den gewöhnlichsten Hobbies von Menschen gehört, die auf Screenreader angewiesen sind.

                Mir fallen auf Anhieb Marco Zehe und Léonie Watson ein. Die Webentwicklung übrigens nicht bloß als Hobby betreiben, sondern als Beruf.

                Ich sagte nicht, dass es nicht auch Ausnahmen geben kann. Ausnahmen. :D

                Und man sollte sich hüten, bei Nutzerm von irgendwas auszugehen:

                “When designing for The Web, your users could be anyone. Make fewer decisions about them so they can make more for themselves.”Heydon Pickering

                Ungefähr das wollte ich mit

                P.S.: Ja, ich weiß was du sagen willst, ja, du hast prinzipiell Recht damit, nein, wir brauchen keine Grundsatzdiskussion.

                vermeiden. xD

                Wir brauchen eine Diskussion um die Bedeutung von Barrierefreiheit. Und das ist eine Grundsatzdiskussion.

                Nein, die führen wir hier schon oft genug.

                Trotzdem ist es nicht immer zielführend, auf Prinzipien zu reiten.

                Bist du genervt? Gut.

                Nein, wie kommst du darauf? Ich ruhe in mir, was das Thema angeht, konnte mir nur die Spitze nicht verkneifen. ;)

                “Arguing with teammates over ‘bothering with accessibility’ makes me so angry.
                Every. Time.
                So. Angry.
                Yes. ‘Bother’. It’s your job.
                Jen Simmons

                Ich habe nie angedeutet man solle sich nicht mit Zugänglichkeit auseinandersetzen, ich habe nur deine Frage beantwortet, warum wir hier eher keine Menschen haben, die Screenreader benutzen :P

                Grüße,

                RIDER

                --
                Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
                # Facebook # Twitter # Steam # YouTube # Self-Wiki # Selfcode: sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[
                1. @@Camping_RIDER

                  Just a guess, aber ich gehe davon aus, dass Webentwicklung nicht direkt zu den gewöhnlichsten Hobbies von Menschen gehört, die auf Screenreader angewiesen sind.

                  Mir fallen auf Anhieb Marco Zehe und Léonie Watson ein. Die Webentwicklung übrigens nicht bloß als Hobby betreiben, sondern als Beruf.

                  Ich sagte nicht, dass es nicht auch Ausnahmen geben kann. Ausnahmen. :D

                  Irgendetwas/irgendjemanden als „Ausnahme“ abzutun birgt die Gefahr, dasjenige/denjenigen als nicht beachtenswert herabzustufen und aus der weiteren Betrachtung auszuschließen.

                  Von daher ist die „Ausnahmen“-Diskussion müßig. Es gibt auf Screenreader angewiesene Webentwickler. Sie verdienen Beachtung.

                  Wir brauchen eine Diskussion um die Bedeutung von Barrierefreiheit. Und das ist eine Grundsatzdiskussion.

                  Nein, die führen wir hier schon oft genug.

                  Solange sich noch nicht barrierefreie „Lösungen“ im Web breitmachen, führen wir die Diskussion noch nicht oft genug.

                  Ich habe nie angedeutet man solle sich nicht mit Zugänglichkeit auseinandersetzen, ich habe nur deine Frage beantwortet, warum wir hier eher keine Menschen haben, die Screenreader benutzen :P

                  Erstens denke ich nicht, dass du eine Antwort auf die Frage geliefert hast.

                  Zweitens hatte die Frage den Hintergrund aufzuzeigen, dass „Wir haben hier keine Menschen, die Screenreader benutzen“ etwa denselben Aussagewert hat wie „Wir haben bei unserer SPA keine Nutzer, die JavaScript deaktiviert haben“.

                  LLAP 🖖

                  --
                  “I love to go to JS conferences to speak about how to avoid using JavaScript. Please learn CSS & HTML to reduce your JS code bloat.” —Estelle Weyl
                  1. Aloha ;)

                    Ich denke eine detaillierte Antwort ist müßig, da du sachlich exakt auf demselben Standpunkt stehst wie ich. Mir ging es lediglich darum, darauf hinzuweisen, dass es nicht in jedem Kontext sinnvoll ist, alles was zur Erfüllung eines Prinzips möglich ist auch einzufordern. Da du auf den konkreten Kontext aber gar nicht eingehst sondern nur auf das allgemeine Prinzip, in dem wir uns in unserer Meinung ja gar nicht unterscheiden, werden wir hier sowieso nicht auf einen Nenner kommen, da wir ausschließlich aneinander vorbeireden. Nicht zuletzt habe ich ja auch die ganze Zeit eine Frage beantwortet, die mit Barrierefreiheit höchstens am Rande zu tun hat, während du fast ausschließlich mit Barrierefreiheit geantwortet hast.

                    Grüße,

                    RIDER

                    --
                    Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
                    # Facebook # Twitter # Steam # YouTube # Self-Wiki # Selfcode: sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[
        2. Hallo Christian,

          Könnte man sowas wie _en vogue_{: @fr} vorsehen und der Markdown-Prozessor macht daraus ein lang-Attribut?

          Vermutlich ist das ohne grössere Arbeiten möglich, ich muss mir das aber anschauen um sicher zu gehen.

          [x] done.

          Die Vermutung war richtig.

          LG,
          CK

          1. Hallo Christian Kruse,

            [x] done.

            Danke. Sieht im Wiki jetzt so aus.

            Bis demnächst
            Matthias

            --
            Dieses Forum nutzt Markdown. Im Wiki erhalten Sie Hilfe bei der Formatierung Ihrer Beiträge.
          2. @@Christian Kruse

            Hallo Christian,

            Könnte man sowas wie _en vogue_{: @fr} vorsehen und der Markdown-Prozessor macht daraus ein lang-Attribut?

            Vermutlich ist das ohne grössere Arbeiten möglich, ich muss mir das aber anschauen um sicher zu gehen.

            [x] done.

            Cool.

            Die Vermutung war richtig.

            Na wenn das so einfach ist, dann wünsch ich mir neben dem Kürzel für lang="…" auch noch ein Kürzel für style="…". Welches Zeichen nehmen wir dafür? ^?

            Aber ernsthaft: Inline-Styles sind nicht gerade das, was man vereinfacht anbieten sollte, sonst kann’s einem hier schnell zu bunt werden.

            Aber einige vordefinierte Klassen wünschte ich mir neben good (oder good-example?) und bad (oder bad-example) noch – mit Stil:

            normal (oder normal-text)
            Stil: { font-weight: inherit; text-style: inherit }
            um die Formatierung von _/__/*/** wieder aufzuheben
            (für sowas wie _Qapla’_{: @tlh}, das weder kursiv noch fett gesetzt werden soll; es gibt ja keine Möglichkeit in Markdown, ein span-Element zu generieren?)
            line-through
            Stil: { text-decoration: line-through }
            als Ersatz für ^W (^H) von damals™

            LLAP 🖖

            PS: Präsentationsbezogene Klassen sind selbstredend im Allgemeinen böse™. Aber wir sind ja hier was Spezielles.

            --
            “I love to go to JS conferences to speak about how to avoid using JavaScript. Please learn CSS & HTML to reduce your JS code bloat.” —Estelle Weyl
            1. Hallo Gunnar Bittersmann,

              Na wenn das so einfach ist, dann wünsch ich mir neben dem Kürzel für lang="…" auch noch ein Kürzel für style="…". Welches Zeichen nehmen wir dafür? ^?

              keins.

              Aber ernsthaft: Inline-Styles sind nicht gerade das, was man vereinfacht anbieten sollte, sonnst kann’s einem hier schnell zu bunt werden.

              Ebennt.

              Aber einige vordefinierte Klassen wünschte ich mir neben good (oder good-example?) und bad (oder bad-example)

              Wie ich schon vorschlug.

              Am besten so:

              ~~~html, bad  
                <octypue html>  
              

              Bis demnächst
              Matthias

              --
              Dieses Forum nutzt Markdown. Im Wiki erhalten Sie Hilfe bei der Formatierung Ihrer Beiträge.
              1. @@Matthias Apsel

                sonnst kann’s einem hier schnell zu bunt werden.

                Ebennt.

                😏

                Wie ich schon vorschlug.

                „Aber bitte, der Herr, nach Ihnen!“ 😈

                LLAP 🖖

                --
                “I love to go to JS conferences to speak about how to avoid using JavaScript. Please learn CSS & HTML to reduce your JS code bloat.” —Estelle Weyl
              2. Hallo Matthias,

                Am besten so:

                  <octypue html>  
                
                  <doctype html>  
                

                [x] done.

                LG,
                CK

                1. Das finde ich jetzt mal richtig gut. 
                  

                  THX*10^3!

                  1. Hallo Jörg,

                    ich bin ehrlich gesagt etwas erstaunt darüber, dass das so gut ankommt. Aber freut mich, gern :)

                    LG,
                    CK

                2. Hallo Christian Kruse,

                  Am besten so:

                    <octypue html>  
                  
                    <doctype html>  
                  

                  [x] done.

                  Cool. Jetzt sieht man garnicht mehr, wie es funktioniert. 😅

                  Bis demnächst
                  Matthias

                  --
                  Dieses Forum nutzt Markdown. Im Wiki erhalten Sie Hilfe bei der Formatierung Ihrer Beiträge.
                  1. Hallo Matthias,

                    Cool. Jetzt sieht man garnicht mehr, wie es funktioniert. 😅

                    Reply löst das Rätsel ;)

                    LG,
                    CK

                    1. Hallo Christian Kruse,

                      Cool. Jetzt sieht man garnicht mehr, wie es funktioniert. 😅

                      Reply löst das Rätsel ;)

                      Für manche Leute auch edit ;-) oder ein Blick ins Wiki.

                      Bis demnächst
                      Matthias

                      --
                      Dieses Forum nutzt Markdown. Im Wiki erhalten Sie Hilfe bei der Formatierung Ihrer Beiträge.
              3. Hallo Matthias.

                Am besten so:

                ~~~html, bad  
                  <octypue html>  
                

                Am besten in der Hauptsprache des Forums oder durch allgemein verständliche Symbole.

                MfG, at