nicht angemeldet
Code-Blöcke in Markdown mit rotem Hintergrund
Matthias Scharwies
Code-Blöcke in Markdown mit rotem Hintergrund
Matthias Scharwies
MudGuard
Matthias Apsel
Gunnar Bittersmann
Tabellenkalk
Camping_RIDERServus!
@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
Es gibt viel zu tun: ToDo-Liste
-
Hi,
testcu,
Andreas a/k/a MudGuard -
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-
Servus!
Vielen Dank euch beiden, nehme es ins Wiki auf!
Herzliche Grüße
Matthias Scharwies
--
Es gibt viel zu tun: ToDo-Liste -
@@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
-
-
@@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 dielanguage-…-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 Beispielmit 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-
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 Beispielmit 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-
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-
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?
-
Hallo,
Sowas geht?
Ja, aber im Zweifel nur kurzzeitig :)
Gruß
Kalk-
Hallo Tabellenkalk,
Ja, aber im Zweifel nur kurzzeitig :)
Genau.
Bis demnächst
Matthias
-
-
-
-
@@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
-
-
@@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 einlang-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-
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 einlang-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-
@@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-
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
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 SimmonsLLAP 🖖
--
“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-
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 SimmonsIch 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
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-
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
-
-
-
-
-
-
Hallo Christian,
Könnte man sowas wie
_en vogue_{: @fr}vorsehen und der Markdown-Prozessor macht daraus einlang-Attribut?Vermutlich ist das ohne grössere Arbeiten möglich, ich muss mir das aber anschauen um sicher zu gehen.
[x] done.
LG,
CK-
-
@@Christian Kruse
Hallo Christian,
Könnte man sowas wie
_en vogue_{: @fr}vorsehen und der Markdown-Prozessor macht daraus einlang-Attribut?Vermutlich ist das ohne grössere Arbeiten möglich, ich muss mir das aber anschauen um sicher zu gehen.
[x] done.
Cool.
Na wenn das so einfach ist, dann wünsch ich mir neben dem Kürzel für
lang="…"auch noch ein Kürzel fürstyle="…". 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(odergood-example?) undbad(oderbad-example) noch – mit Stil:normal(odernormal-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, einspan-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-
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ürstyle="…". 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(odergood-example?) undbad(oderbad-example)Wie ich schon vorschlug.
Am besten so:
~~~html, bad <octypue html>Bis demnächst
Matthias-
@@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 -
Hallo Matthias,
Am besten so:
<octypue html><doctype html>[x] done.
LG,
CK-
Das finde ich jetzt mal richtig gut.THX*10^3!
-
Hallo Jörg,
ich bin ehrlich gesagt etwas erstaunt darüber, dass das so gut ankommt. Aber freut mich, gern :)
LG,
CK
-
-
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-
Hallo Matthias,
Cool. Jetzt sieht man garnicht mehr, wie es funktioniert. 😅
Reply löst das Rätsel ;)
LG,
CK-
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
-
-
-
-
Hallo Matthias.
Am besten so:
~~~html, bad <octypue html>Am besten in der Hauptsprache des Forums oder durch allgemein verständliche Symbole.
MfG, at
-
-
-
-
-