before: content - wieviel/welcher text ist erlaubt?

[Henry]

Hallo,

bestimmt trivial, habe aber leider keine Antwort in den Spezifikationen gefunden.

q::before { 
  content: "...endlos....?";
}

Wieviel Text darf da rein?

Welcher Text, ist es erlaubt alles reinzuschreiben. Beispiel: Content: "<h1><script>irgendwas...</h1>"

Damit meine ich jetzt nicht, dass das als Code/Auszeichnung ausgeführt wird, sondern ob es Probleme damit geben kann. Oder ist das vergleichsweise mit Sachen innerhalb eines Kommentars, wo(korrigiert mich bitte, wenn ich mich irre) alles erlaubt ist(außer natürlich Kommentar-Endzeichen)?

Gruss
Henry

[Matthias Apsel]

Hallo Henry,

Eine aus CSS−Sicht gültige Zeichenkette. An eine mögliche Längenbegrenzung solltest du nicht stoßen, denn relevante Inhalte sollte man nicht im CSS verstecken. Sie gehören ins HTML.

Bis demnächst
Matthias

[Henry]

Hallo Matthias,

Eine aus CSS−Sicht gültige Zeichenkette.

bedeutet was genau? Ist die Zeichenkette in meinem Beispiel OK?

An eine mögliche Längenbegrenzung solltest du nicht stoßen, denn relevante Inhalte sollte man nicht im CSS verstecken. Sie gehören ins HTML.

Also ist eine Längenbegrenzung nicht bekannt?

Gruss
Henry

[Erwin]

Eine aus CSS−Sicht gültige Zeichenkette. bedeutet was genau?

in CSS besteht ein String aus keinem oder mehr Zeichen umschlossen von einfachen oder doppelten Anführungszeichen; gewisse Zeichen müssen maskiert werden (eben jene Anführungszeichen und Zeilenumbrüche)

Ist die Zeichenkette in meinem Beispiel OK?

ja

An eine mögliche Längenbegrenzung solltest du nicht stoßen, denn relevante Inhalte sollte man nicht im CSS verstecken. Sie gehören ins HTML.

Also ist eine Längenbegrenzung nicht bekannt?

Es ist bekannt, dass es eine solche geben muss (auch wenn ich in der CSS-Spec keine Vorgabe dazu finde), wir arbeiten schließlich mit reellen Computern und nicht mit universellen Turingmaschinen mit unbegrenztem Speicherplatz; wo diese in der jeweiligen UA-Implementation liegt, wird also vermutlich mindestens (ich würde erwarten, dass vorher ein anderes Limit zuschlagen wird) davon abhängen, wie die entsprechenden Variablen definiert sind, für welches System der UA kompiliert wurde und welche Programmiersprache verwendet wurde (in Java würde ich z.B. erwarten, dass keinesfalls mehr als 2147483647 Zeichen erlaubt wären). Edit: Im IE<10 gab es wohl eine Grenze von 288 kB pro CSS-Datei (was für mich älteren Menschen sehr großzügig wirkt).

[Gunnar Bittersmann]

@@Henry

Die Frage

Welcher Text

ist einfach beantwortet: dekorativer.

ist es erlaubt alles reinzuschreiben.

Nein. Inhalte gehören ins HTML.

LLAP 🖖

[Henry]

Hallo,

Die Frage

Welcher Text

ist einfach beantwortet: dekorativer.

Was meinst du denn damit schon wieder? Dekorativer Text? Bilder?

ist es erlaubt alles reinzuschreiben.

Nein. Inhalte gehören ins HTML.

Also deiner Meinung nach überhaupt kein Text da rein oder was?

Gruss
Henry

[marctrix]

Hej Henry,

Die Frage

Welcher Text

ist einfach beantwortet: dekorativer.

Was meinst du denn damit schon wieder? Dekorativer Text? Bilder?

Nein, sondern Text. Zum Beispiel: "…" am ende von Teaserm oder Anführungsstriche in einer besonderen Formatierung (z.B. übergroß) für die otpische Kennzeichnung von zitaten (die logisch als blockquote ausgezeichnet sind).

Gerne auch anders bereits zugängliche Informationen wie Hinweise auf ein Linkziel o.ä. noch mal optisch hervorhebn. Auch Beschreibungen von Icons durch Verwendung des alt-Textes als Inhalt für ::before oder ::after sind denkbar.

ist es erlaubt alles reinzuschreiben.

Nein. Inhalte gehören ins HTML.

Also deiner Meinung nach überhaupt kein Text da rein oder was?

Wo hat er das geschrieben?

CSS dient der Gestaltung von Dokumenten, HTML enthält strukturierten Inhalt. Nennt man separation of concerns und ist die Grundlage eines jeden Website-Konzeptes.

Marc

[Gunnar Bittersmann]

@@Henry

ist einfach beantwortet: dekorativer.

Was meinst du denn damit schon wieder? Dekorativer Text? Bilder?

Das können Symbole sein, bspw.

a.prev::before { content: '◀︎\a0 ' }
a.next::after  { content: '\a0 ▶︎' }

Aber auch Text, bspw.

:lang(en) h1::before { content: 'Chapter ' }
:lang(en) h2::before, :lang(en) h3::before { content: 'Section ' }

:lang(de) h1::before { content: 'Kapitel ' }
:lang(de) h2::before, :lang(de) h3::before { content: 'Abschnitt ' }

für

<h1>12 Generated content, automatic numbering, and lists</h1>
<h2>12.1 The :before and :after pseudo-elements</h2>

Nein. Inhalte gehören ins HTML.

Also deiner Meinung nach überhaupt kein Text da rein oder was?

Die Frage ist: Ist der Seiteninhalt ohne den Text verständlich? Wenn nein, gehört er wohl ins HTML.

Eine Ausnahme fällt mir aber doch ein, wo ein Dokument erst durch CSS-generierten Text brauchbar wird:

@media print
{
  a::after { content: ' (' attr(href) ')' }
  nav a::after { content: none }
}

LLAP 🖖

[marctrix]

Hej Gunnar,

@@Gunnar Bittersmann

<h1>12 Generated content, automatic numbering, and lists</h1>
<h2>12.1 The :before and :after pseudo-elements</h2>

Die Nummerierung kann man auch per CSS erzeugen (weißt du, logo), aber die Frage ist, was besser ist (HTML oder CSS). Ich würde sagen: kommt drauf an. 😉

Wenn der Text aus einer Textverarbeitung kommt, die die Nummerierung automatisch erstellt hat, spricht nichts dagegen, diese ins HTML aufzunehmen. - Man muss dann nur alle zukünftien Aktiualisierungen des Textes - insbesondere wenn die Nummerierung betroffen ist - auch wieder in der Textverarbeitung erledigen und nicht direkt im HTML.

Denn: Solche Nummerierungen per Hand zu erstellen ist ziemlich fehleranfällig und ich würde die eher von CSS machen lassen, als die Nummerierung selber durchzuführen - vor allem bei längeren Texten. Wenn man sich da vertut, ist das verwirrender, als die Nummerierung ganz weg zu lassen.

Da CSS-generierte Inhalte selbst den meisten Screenreadern zugänglich sind, spricht da IMHO auch kaum was gegen, denn die Nummerierung ist meist nicht für das Verständnis nötig und sollte auch ohne explizite Ausgabe bei vernünftig ausgezeichneten und gestalteten Dokumenten erkennbar sein (selbst wenn das CSS abgeschaltet ist, erkennbar an einer nachvollziehbaren Überschriftenstruktur).

Screenreader-Nutzer sind, was die Analyse-Möglichkeiten für eine Webseite betrifft, Sehenden Nutzern ohnehin weit voraus - sie können sich Angaben zu Anzahl der Links, Anzahl der Überschriften u.v.a.m. ausgeben lassen und bekommen zu allen Listen beispielsweise automatisch die Anzahl der enthaltenen Einträge vorab angesagt.

Klar ist: wenn die Nummerierung unabdingbar für das Verständnis ist, muss sie ins HTML, damit sie nicht verloren geht bei abgeschaltetem oder aktivierten Benutzer-CSS!

Das ist grundsätzlich die Regel: in ::before und ::after gehören nur Dinge, die für das Verständnis nciht notwendig sind!

Marc

[Gunnar Bittersmann]

@@marctrix

Denn: Solche Nummerierungen per Hand zu erstellen ist ziemlich fehleranfällig und ich würde die eher von CSS machen lassen, als die Nummerierung selber durchzuführen

Dann sollte man aber nirgends im Text sowas haben wie „siehe Abschnitt 1.2.3“. Es kann ja durch Hinzufügen eines Abschnitts schnell 1.2.4 draus werden. Oder durch Wegfall eines anderen 1.1.3.

Das ist grundsätzlich die Regel: in ::before und ::after gehören nur Dinge, die für das Verständnis nciht notwendig sind!

Ein Gegenbeispiel hatte ich genannt.

LLAP 🖖

[marctrix]

Hej Gunnar,

@@marctrix

Denn: Solche Nummerierungen per Hand zu erstellen ist ziemlich fehleranfällig und ich würde die eher von CSS machen lassen, als die Nummerierung selber durchzuführen

Dann sollte man aber nirgends im Text sowas haben wie „siehe Abschnitt 1.2.3“. Es kann ja durch Hinzufügen eines Abschnitts schnell 1.2.4 draus werden. Oder durch Wegfall eines anderen 1.1.3.

Eben! So etwas sollte automatisch erledigt werden oder (besser) man verzichtet darauf.

Das ist grundsätzlich die Regel: in ::before und ::after gehören nur Dinge, die für das Verständnis nciht notwendig sind!

Ein Gegenbeispiel hatte ich genannt.

Progressive Enhancement ist die Ausnahme von jeder Regel.

Heißt: lieber etwas für einen eingeschränkten Nutzerkreis bereit stellen, als für niemanden — manchmal ist das die einzige Wahl, die man hat.

Marc

[Gunnar Bittersmann]

@@marctrix

Denn: Solche Nummerierungen per Hand zu erstellen ist ziemlich fehleranfällig und ich würde die eher von CSS machen lassen, als die Nummerierung selber durchzuführen

Dann sollte man aber nirgends im Text sowas haben wie „siehe Abschnitt 1.2.3“. Es kann ja durch Hinzufügen eines Abschnitts schnell 1.2.4 draus werden. Oder durch Wegfall eines anderen 1.1.3.

Eben! So etwas sollte automatisch erledigt werden oder (besser) man verzichtet darauf.

Eine Textverarbeitung sollte das hinbekommen. CSS kann das aber nicht.

LLAP 🖖

[marctrix]

Hej Gunnar,

@@marctrix

Denn: Solche Nummerierungen per Hand zu erstellen ist ziemlich fehleranfällig und ich würde die eher von CSS machen lassen, als die Nummerierung selber durchzuführen

Dann sollte man aber nirgends im Text sowas haben wie „siehe Abschnitt 1.2.3“. Es kann ja durch Hinzufügen eines Abschnitts schnell 1.2.4 draus werden. Oder durch Wegfall eines anderen 1.1.3.

Eben! So etwas sollte automatisch erledigt werden oder (besser) man verzichtet darauf.

Eine Textverarbeitung sollte das hinbekommen. CSS kann das aber nicht.

Daher schrieb ich:

Wenn der Text aus einer Textverarbeitung kommt, die die Nummerierung automatisch erstellt hat, spricht nichts dagegen, diese ins HTML aufzunehmen. - Man muss dann nur alle zukünftien Aktiualisierungen des Textes - insbesondere wenn die Nummerierung betroffen ist - auch wieder in der Textverarbeitung erledigen und nicht direkt im HTML.

Trifft natürlich auf Fälle zu, in denen man sich auf die Nummerierungen bezieht… Marc

[dedlfix]

Tach!

Denn: Solche Nummerierungen per Hand zu erstellen ist ziemlich fehleranfällig und ich würde die eher von CSS machen lassen, als die Nummerierung selber durchzuführen

Dann sollte man aber nirgends im Text sowas haben wie „siehe Abschnitt 1.2.3“. Es kann ja durch Hinzufügen eines Abschnitts schnell 1.2.4 draus werden. Oder durch Wegfall eines anderen 1.1.3.

In Hypertextdokumenten kann man das verlinken, so dass die Änderung der Nummerierung weniger ein Problem ist. Eher sehe ich solch eine Angabe als nicht ganz ausgereifte Benutzerführung, denn sie wirkt ähnlich wie eine Abkürzung, die nicht, beziehungsweise erst nach einem Klick oder gar einer Suche nach dem Zielort erklärt wird. In Papierdokumenten ist die Nummerierung ja noch sinnvoll, weil man dadurch das Ziel besser findet als wenn es nur mit Text beschrieben wäre.

Im Hypertextkontext ist im Prinzip aufgrund der Verlinkbarkeit eine solche Nummerierung gänzlich überflüssig. Sie hat dennoch einen Sinn, wenn medienfremde Verweise darauf genutzt werden sollen.

dedlfix.

[marctrix]

Hej dedlfix,

Im Hypertextkontext ist im Prinzip aufgrund der Verlinkbarkeit eine solche Nummerierung gänzlich überflüssig.

FULL ACK

Ich mag sie, finde sie schön (steht für mich gleich mit dekoration und ist damit ein klarer Fall für CSS - man sollte sie nur nicht notwendig machen, indem man auf die Nummern verweist).

Marc

[marctrix]

Hej marctrix,

Dann sei bitte so ehrlich und vergiss nicht zu erwähnen, dass du es hasst CSS-Zähler zu erstellen!

Marc

[marctrix]

Hej marctrix,

Dann sei bitte so ehrlich und vergiss nicht zu erwähnen, dass du es hasst CSS-Zähler zu erstellen!

Ja, das stimmt. Da sind wir uns einig.

Marc

[Henry]

Hallo Gunnar,

Was meinst du denn damit schon wieder? Dekorativer Text? Bilder?

Das können Symbole sein, bspw.

a.prev::before { content: '◀︎\a0 ' }
a.next::after  { content: '\a0 ▶︎' }

ok verstehe, das macht Sinn.

Aber auch Text, bspw.

:lang(en) h1::before { content: 'Chapter ' }
:lang(en) h2::before, :lang(en) h3::before { content: 'Section ' }

:lang(de) h1::before { content: 'Kapitel ' }
:lang(de) h2::before, :lang(de) h3::before { content: 'Abschnitt ' }

für

<h1>12 Generated content, automatic numbering, and lists</h1>
<h2>12.1 The :before and :after pseudo-elements</h2>

Das verstehe ich weniger. Warum sollte jemand Überschriften nicht im Text angeben wollen? Oder... nee du meinst das bestimmt anders?

Eine Ausnahme fällt mir aber doch ein, wo ein Dokument erst durch CSS-generierten Text brauchbar wird:

@media print
{
  a::after { content: ' (' attr(href) ')' }
  nav a::after { content: none }
}

Ok, macht auch Sinn.

*zur Info. Nicht, dass das hier falsch verstanden wird. Es geht nicht um die Nutzung für Besucher, nur für eine administrative Idee, die nur ich sehe. Daher versuche ich die Grenzen des Machbaren dieser Pseudoeklassen zu ergründen.

Gruss
Henry

[Auge]

Hallo

Aber auch Text, bspw.

:lang(en) h1::before { content: 'Chapter ' }
:lang(en) h2::before, :lang(en) h3::before { content: 'Section ' }

:lang(de) h1::before { content: 'Kapitel ' }
:lang(de) h2::before, :lang(de) h3::before { content: 'Abschnitt ' }

für

<h1>12 Generated content, automatic numbering, and lists</h1>
<h2>12.1 The :before and :after pseudo-elements</h2>

… Warum sollte jemand Überschriften nicht im Text angeben wollen?

Darum geht's hier nicht.

Oder... nee du meinst das bestimmt anders?

Ja, tut er. Die Überschrift selbst wird im HTML-Quelltext angegeben, sie ist schließlich Inhalt. Die Worte „Chapter“ oder „Kapitel“ bzw. „Section“ oder „Abschnitt“, die nicht zu den Überschriften selbst gehören, aber zusätzliche, hier auch noch sprachabhängig angegebene Zusatzinformationen liefern, werden den Überschriften per CSS vorangestellt.

Tschö, Auge

[Gunnar Bittersmann]

@@Henry

Das verstehe ich weniger. Warum sollte jemand Überschriften nicht im Text angeben wollen? Oder... nee du meinst das bestimmt anders?

Die Überschriften sind ja im Markup angegeben:

<h1>12 Generated content, automatic numbering, and lists</h1>
<h2>12.1 The :before and :after pseudo-elements</h2>

Mittels CSS wird angezeigt:

Chapter 12 Generated content, automatic numbering, and lists

Section 12.1 The :before and :after pseudo-elements

Mit Chapter bzw. Section davor.

Mir fiel gerade kein besseres Beispiel für CSS-generierten Text ein, der nicht im Markup stehen müsste.

LLAP 🖖

[JürgenB]

Hallo,

Mir fiel gerade kein besseres Beispiel für CSS-generierten Text ein, der nicht im Markup stehen müsste.

[title]:focus::after { content: attr(title); position: …; margin: …; …}

blendet das Title-Attribut bei Fokussierung ein.

Gruß
Jürgen

[Matthias Apsel]

Hallo JürgenB,

Mir fiel gerade kein besseres Beispiel für CSS-generierten Text ein, der nicht im Markup stehen müsste.

[title]:focus::after { content: attr(title); position: …; margin: …; …}

.posting-content a[href*='wiki.selfhtml.org']::after {content: " (W)";}

Bis demnächst
Matthias

[marctrix]

Hej JürgenB,

Mir fiel gerade kein besseres Beispiel für CSS-generierten Text ein, der nicht im Markup stehen müsste.

[title]:focus::after { content: attr(title); position: …; margin: …; …}

blendet das Title-Attribut bei Fokussierung ein.

In den meisten Fällen eher nicht, denn die meisten Elemente sind nicht fokussierbar. Es gibt zwar mit tabindex"0" auch dafür eine Lösung, allerdings werden sich Blinde bedanken, wenn Sie title-Attribute nun doppelt ausgegeben werden und auch noch allerhand Zeugs durchgetabbt werden muss, nur weil es ein Designer nicht verstanden hat, Erklärungen woanders als in Tooltipps unterzubringen.

Darum so was besser nicht machen.

Marc

[JürgenB]

Hallo Marc,

ich hätte vielleicht dazuschreiben sollen, dass ich an fokussierbare Elemente gedacht habe, und an den Übergang von Title nach was besserem.

Gruß
Jürgen

[marctrix]

Hej JürgenB,

ich hätte vielleicht dazuschreiben sollen, dass ich an fokussierbare Elemente gedacht habe,

Da hat man die Probleme mit redundantem Content für Blinde und Mausnutzer auch.

und an den Übergang von Title nach was besserem.

Gibt es nciht. Sagt Heydon Pickering. Ich wollte es nicht glauben und habe einen Codepen erstellt um mit abbr und title herumzuspielen

Das Ergebnis ist alles andere als befriedigend. Insbesondere Fragen wie auf das Vorhandensein von Tooltipps hingewiesen werden kann (ist auch für das title-Attribut nicht gelöst, da Browser keine Standard-Fromatierung wie z.B. für Links mitbringen und es somit keine Konvention gibt) oder auch wo der Inhalt dann ausgegeben werden soll, habe ich nciht befriedigend lösen können.

Gelöst sind dagegen Zugänglichkeit für Touch, Screenreader, Maus (:hover und :active und Tastatur — letztere dank tabindex="0" aber mit der Konsequenz, dass bei massiver Verwendung von Tooltipps die Zahl der Elemente immens steigen kann, durch die man sich kämpfen muss, wenn man auf eine Seite durchtabbt. Also alles doof 😉

Marc

[JürgenB]

Hallo Marc,

und an den Übergang von Title nach was besserem.

Gibt es nciht. Sagt Heydon Pickering.

mit „was besserem“ meine ich nicht, wie ich den Inhalt vom title besser darstellen kann, sondern wie ich auf title ganz verzichten kann. title → ::after ist eine Zeile im css, aber eben nur ein Tooltip für Tastaturbenutzer, eigentlich muss ich über Struktur und Inhalt nachdenken — für jeden Button.

Gruß
Jürgen

[marctrix]

Hej JürgenB,

und an den Übergang von Title nach was besserem.

Gibt es nciht. Sagt Heydon Pickering.

mit „was besserem“ meine ich nicht, wie ich den Inhalt vom title besser darstellen kann, sondern wie ich auf title ganz verzichten kann.

So hatte ich das auch verstanden 😉

Daher habe ich auch einen Codepen verlinkt, in dem ich auf title verzichte.

title → ::after ist eine Zeile im css, aber eben nur ein Tooltip für Tastaturbenutzer, eigentlich muss ich über Struktur und Inhalt nachdenken — für jeden Button.

Ja, das scheint man für jeden konkreten Fall lösen zu müssen.

Manchmal passt das mehr an Text auf einen (großen) Button (sieht man ja öfters, dass die Funktion (z.B. Bestellen) in großer Schrift zu sehen ist und darunter kleiner noch eine Info).

"Jetzt kostenpflichtig bestellen" ist beispielsweise auch schon relativ viel Text im Vergleich zu "Senden"…

Auf jeden Fall eine Herausforderung an die Kreativität!

Marc

[dedlfix]

Tach!

"Jetzt kostenpflichtig bestellen" ist beispielsweise [...]

... eine rechtlich relevante Information. Die sollte man auf alle Fälle zum Inhalt und nicht zur Dekoration hinzufügen.

dedlfix.

[marctrix]

Hej dedlfix,

Vollständigeres Zitat:

Manchmal passt das mehr an Text auf einen (großen) Button […] "Jetzt kostenpflichtig bestellen" ist beispielsweise […]

... eine rechtlich relevante Information. Die sollte man auf alle Fälle zum Inhalt und nicht zur Dekoration hinzufügen.

Unbedingt - darum habe ich sie auch als Beispiel für einen Text genommen, der auf einen (großen) Button passt. Ständig sichtbar und jedem zugänglich.

Umsetzungsempfehlung:

<button>Jetzt kostenpflichtig bestellen</button>

Marc

[Christian Kruse]

Hallo dedlfix,

"Jetzt kostenpflichtig bestellen" ist beispielsweise [...]

... eine rechtlich relevante Information. Die sollte man auf alle Fälle zum Inhalt und nicht zur Dekoration hinzufügen.

Und auch nicht als Playground für seine Kreativität ausnutzen. Die Formulierungen unterliegen einem sehr engen Rahmen. Gültig wären etwa folgende:

• Kostenpflichtig bestellen
• Zahlungspflichtig bestellen
• Zahlungspflichtigen Vertrag schließen
• Jetzt kaufen

Daran sollte man sich auch tunlichst halten, sonst wird es teuer. Einfach nur „Kaufen“ etwa ist bereits abmahnfähig (da gibt es bereits Urteile zu).

LG,
CK

[Tabellenkalk]

Hallo,

Also alles doof 😉

Wie zugänglich ist eigentlich ASCII-Art?

Gruß
Kalk

[Gunnar Bittersmann]

@@Tabellenkalk

Wie zugänglich ist eigentlich ASCII-Art?

Dieser Tweet von Marco Zehe solle die Frage hinreichend beantworten. 😆

LLAP 🖖

[Henry]

Hallo Gunnar,

Dieser Tweet von Marco Zehe solle die Frage hinreichend beantworten. 😆

interessanter Link, nicht wegen dem Inhalt aber wegen dem Verweis auf Marco Zehe. Sorry, das muss ich jetzt mal loswerden:

Ich finde es unfassbar und absolut beeindruckend wie sich jemand wie er(blind von Geburt an) so qualifiziert und leichtfüßig, ausgerechnet im Bereich der schriftlichen Medien, mitteilt und Fachwissen ausstrahlt. Dazu noch die perfekte Orthographie, von der sich die meisten(mich eingeschlossen) Menschen eine Scheibe abschneiden könnten. Wenn ich dann noch bedenke, dass neuerdings immer mehr Kindern bereits in der Grundschule sofort ein Notebook hingestellt wird, weil das Kind ja "angeblich" eine Lese/Schreibschwäche hat. Neee die meisten Kinder sind zu faul! Also Respekt vor Leuten wie Marco und ähnlich gelagerten Fällen(auch hier im Forum).

Gruss
Henry

[marctrix]

Hej Tabellenkalk,

Hallo,

Also alles doof 😉

Wie zugänglich ist eigentlich ASCII-Art?

Was soll ein Screenreader denn aus ASCII-Art machen? - Vielleicht so was wie "Punkt, Punkt, Komma, Strich - fertig ist das Mondgesicht"? 😉

Marc

[dedlfix]

Tach!

Wie zugänglich ist eigentlich ASCII-Art?

Was soll ein Screenreader denn aus ASCII-Art machen? - Vielleicht so was wie "Punkt, Punkt, Komma, Strich - fertig ist das Mondgesicht"? 😉

Screenreader sind für Bilder auch eher ungeeignet. Es gibt jedoch "Displays", die aus X mal Y anhebbaren Stiften bestehen. Damit kann man Formen erfühlen.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Es gibt jedoch "Displays", die aus X mal Y anhebbaren Stiften bestehen. Damit kann man Formen erfühlen.

So sieht’s aus:

Foto: Herbert Ponting, 1907 (public domain)

LLAP 🖖

[marctrix]

Hej dedlfix,

Was soll ein Screenreader denn aus ASCII-Art machen? - Vielleicht so was wie "Punkt, Punkt, Komma, Strich - fertig ist das Mondgesicht"? 😉

Screenreader sind für Bilder auch eher ungeeignet. Es gibt jedoch "Displays", die aus X mal Y anhebbaren Stiften bestehen. Damit kann man Formen erfühlen.

Stimmt. - Aber wer hat so was schon?

Marco ist sicher schon sehr gut ausgestattet, aber selbst der würde bei ASCII-Art handgreiflich 😉

Marc

[Tabellenkalk]

Hallo,

Es gibt jedoch "Displays", die aus X mal Y anhebbaren Stiften bestehen. Damit kann man Formen erfühlen.

der würde bei ASCII-Art handgreiflich 😉

Ich glaub, genau darum gehts bei diesen Stift-Displays… 📍🔨

Gruß
Kalk

[Henry]

Hallo,

Danke an alle 😉 *wollte ich eigentlich ohne zwinkern :-) machen, aber da kommt kein Smiley nur ein Rechteck 🏻)

Fazit:

Wieviel Text darf da rein?

Nicht spezifiziert, evtl. browser/Systembegrenzt, in jedem Fall aber reichlich 😉

Welcher Text, ist es erlaubt alles reinzuschreiben. Beispiel: Content: "<h1><script>irgendwas...</h1>"

Ja, außer Anführungszeichen(wie initialisiert also " bzw. ') und Zeilenumbrüche.

Nicht gestellte Frage... 😉 Soll man Text rein schreiben? In der Regel nicht, nur im seltenen Ausnahmefall oder zu dekorativen Zwecken. Inhalt gehört ins HTML!

Gruss Henry

[Gunnar Bittersmann]

@@Henry

Welcher Text, ist es erlaubt alles reinzuschreiben […] Ja, außer Anführungszeichen(wie initialisiert also " bzw. ') und Zeilenumbrüche.

Zum einen sind " und ' keine Anführungszeichen.

Zum anderen kann man diese Zeichen natürlich reinschreiben. (Aber warum sollte man?)

Das eine ganz normal im anderen: content: '"' oder andersrum content: "'".

Und immer, wenn man Zeichen in einen Kontext bringt, in welchem sie eine Sonderbedeutung haben, muss man den Kontextwechsel beachten und escapen: content: '\'' oder content: '\27 '

Mit Anführungszeichen hat man solche Probleme natürlich gar nicht erst: content: '„', content: '“', content: '”'.

LLAP 🖖

[Henry]

Hallo Gunnar,

Zum anderen kann man diese Zeichen natürlich reinschreiben. (Aber warum sollte man?)

Warum sollte man nicht? 😉

Das eine ganz normal im anderen: content: '"' oder andersrum content: "'".

Hatte ich ja so geschrieben.

Und immer, wenn man Zeichen in einen Kontext bringt, in welchem sie eine Sonderbedeutung haben, muss man den Kontextwechsel beachten und escapen: content: '\'' oder content: '\27 '

Keine gute Idee, das funktioniert nicht. Probiers aus.

Mit Anführungszeichen hat man solche Probleme natürlich gar nicht erst: content: '„', content: '“', content: '”'.

Ja, zumindest sehen die „Echten”, schöner aus 😉

Gruss
Henry

[marctrix]

Hej Henry,

Mit Anführungszeichen hat man solche Probleme natürlich gar nicht erst: content: '„', content: '“', content: '”'.

Ja, zumindest sehen die „Echten”, schöner aus 😉

Und diese Anführungszeichen lassen sich abhängig vom sprachlichen Kontext gestalten - analog zur Ausgabe von Kapitel statt Chapter aus dem Beispiel von @Gunnar Bittersmann

Marc

[Gunnar Bittersmann]

@@marctrix

Hej Henry,

Mit Anführungszeichen hat man solche Probleme natürlich gar nicht erst: content: '„', content: '“', content: '”'.

Ja, zumindest sehen die „Echten”, schöner aus 😉

Und diese Anführungszeichen lassen sich abhängig vom sprachlichen Kontext gestalten

Siehe auch Language in язык in שפראך in 語言

☞ Folien, Video (12:25 Minuten, wovon die ersten 4 Geikel sind. But mama, that’s where the fun is.)

LLAP 🖖

[Henry]

Korrektur:

.../International/questions/qa-escapes#cssescapes): content: '\'' oder content: '\27 '

Keine gute Idee, das funktioniert nicht. Probiers aus.

Funktioniert doch! Nur nicht in meiner Testumgebung, bei der der String noch einige andere Prozeduren durchläuft, warum genau dort ein Problem entsteht weiß ich noch nicht. Aber klar, hast recht Gunnar, kann man so nutzen.

[Auge]

Hallo

.../International/questions/qa-escapes#cssescapes): content: '\'' oder content: '\27 '

das funktioniert nicht.

Funktioniert doch! Nur nicht in meiner Testumgebung, bei der der String noch einige andere Prozeduren durchläuft, warum genau dort ein Problem entsteht weiß ich noch nicht.

Du solltest in deiner Testumgebung nach jedem Schritt den Zustand mit Kontrollausgaben prüfen. Vielleicht wird ja an ungeeigneter Stelle auf ungeeignete Weise der das Zeichen maskiernde Backslash entfernt. Das ist jedenfalls ein typischer und mMn der gängigste Fehler.

Tschö, Auge

[Henry]

Hallo,

Du solltest in deiner Testumgebung nach jedem Schritt den Zustand mit Kontrollausgaben prüfen. Vielleicht wird ja an ungeeigneter Stelle auf ungeeignete Weise der das Zeichen maskiernde Backslash entfernt. Das ist jedenfalls ein typischer und mMn der gängigste Fehler.

Ja in die Richtung dachte ich auch und letztendlich wars das auch. Doppelter Backslash hilft.

<script>
function addbefore()
{
var strx = '#sobj:before{content:"das ist \\" ein test ";}';
alert(strx);

document.querySelector('#s').innerHTML = strx;
}
</script>

Gruss
Henry

[Gunnar Bittersmann]

@@Henry

Ja in die Richtung dachte ich auch und letztendlich wars das auch. Doppelter Backslash hilft.

Und ich sagte noch: Kontextwechsel beachten!

\ ist im Kontext JavaScript ein Sonderzeichen und muss, wenn’s als Zeichen erhalten werden soll, escapet werden.

LLAP 🖖