Warum das CSS für input nicht angewendet?

[Christian Wansart]

Guten Morgen,

ich versuche gerade einen Fade-In mittels reinem HTML und CSS zu bauen, ohne JavaScript zu verwenden. Dazu möchte ich später die CSS-Eigenschaft transition verwenden.

Damit ich auf JavaScript verzichten kann, habe ich eine kleine Auswahl mit Checkboxen gebaut. Im CSS-Code sollte dann mittels :checked bei der entsprechenden Checkbox dafür gesorgt werden, dass eine andere Box angezeigt wird – das Ausblenden habe ich noch nicht und ich weiß auch noch nicht, das kommt später noch.

Die grundsätzliche Idee habe ich in einem Beitrag auf Stackoverflow gefunden. Leider mache ich irgendetwas beim Übernehmen falsch.

Meinen aktuellen HTML-/CSS-Code findet ihr auf Codepen: https://codepen.io/Ctwx/pen/JKBBvq

Wie kann ich das Problem lösen und beim Anklicken der jeweiligen Checkboxen übernehmen?

Freundliche Grüße
Christian

[Matthias Apsel]

Hallo Christian Wansart,

Dein Selektor

#select1:checked + main > …

läuft ins Leere.

Derzeit geht das mit diesem Markup mit CSS noch nicht, da du nicht „rückwärts“ selektieren kannst. Siehe zum Beispiel:

• checkbox-hack
• Forumsbeitrag

Bis demnächst
Matthias

[Christian Wansart]

Hallo Matthias,

danke für deine Antwort, dann habe ich das wohl falsch verstanden. Schade eigentlich, dann muss ich wohl JavaScript dafür verwenden, wenn ich es genau so haben möchte. Über den „Hack“ bekomme ich es nicht hin. Wenn ich das richtig verstehe, dann hängt es von der Struktur meines HTML ab.

Freundliche Grüße
Christian

[Gunnar Bittersmann]

@@Christian Wansart

Schade eigentlich, dann muss ich wohl JavaScript dafür verwenden, wenn ich es genau so haben möchte. Über den „Hack“ bekomme ich es nicht hin. Wenn ich das richtig verstehe, dann hängt es von der Struktur meines HTML ab.

Ja, das geht nur, wenn die ein- und auszublendenden Bereiche nachfolgende Geschwisterelemente (oder deren Kinder) der Radiobuttons (bzw. Checkboxen bei Akkordeons) sind.

Und das geht auch nicht auf Androids, die noch vom WebKit Adjacent/General Sibling & Pseudo Class Bug betroffen sind, gegen den es wohl keine brauchbare Lösung gibt.

Also JavaScript, ja. Dann kann es auch barriefrei werden, was man der CSS-Lösung nicht nachsagen kann.

Léonie Watson zeigt in ihrem Developer’s guide to accessibility mechanics ab Folie 22, wie man toggletip und tab panels (um letztere handelt es sich wohl bei dir) umsetzen kann.

LLAP 🖖

[Christian Wansart]

Guten Morgen Gunnar,

vielen Dank für die Erklärung und den Link.

Freundliche Grüße
Christian

[MrMurphy1]

Hallo

Wenn ich das richtig verstehe, dann hängt es von der Struktur meines HTML ab.

Auch.

wenn ich es genau so haben möchte.

Wie möchtest du es denn haben? Und was hindert dich daran den Quelltext anzupassen?

Gruss

MrMurphy

[Christian Wansart]

Guten Morgen MrMurphy,

wenn ich es genau so haben möchte.

wie Gunnar bereits schrieb, bezieht sich das Element des Selectors entsprechend auf den direkten Nachbarn. Da ich die Auswahl gerne in einem anderen Container haben möchte, kann ich das Ziel nicht so erfüllen. Abgesehen davon gibt es in Android wohl einen Bug – siehe Gunnars Beitrag – weswegen die CSS-Lösung nicht anwendbar ist. Schade eigentlich.

Freundliche Grüße
Christian

[MrMurphy1]

Hallo

Abgesehen davon gibt es in Android wohl einen Bug

Eher schade, dass du auf die unsinnige Panikmache hereinfällst. Ich lese dort

Safari (5.1) and Chrome (13)

Schau mal nach wie verbreitet die sind. Ich komme auf 0 Prozent. Ich wüßte nicht dass noch irgendein Webseitenersteller in irgendeiner Form Rücksicht auf die nimmt. Dann könnten ungefähr die Hälfte aller CSS3-Anweisungen bis heute noch nicht verwendet werden.

Da ich die Auswahl gerne in einem anderen Container haben möchte

Warum schränkst du dich selbst ein? Warum in einem anderen Container? Was willst du im Endeffekt erreichen?

Die Verwendung des nav-Elements ist meiner Kenntnis nach in deinem Beispiel falsch. Das nav-Element ist in HTML5 nur für die Hauptnavigation gedacht.

Und eine Liste kann verwendet werden. Sie ist aber sinnfrei und kann genau so gut weggelassen werden.

Gruss

MrMurphy

[Christian Wansart]

Guten Morgen MrMurphy,

Eher schade, dass du auf die unsinnige Panikmache hereinfällst.

Ich würde nicht von Panikmache reden.

Ich lese dort

Safari (5.1) and Chrome (13)

Schau mal nach wie verbreitet die sind. Ich komme auf 0 Prozent. Ich wüßte nicht dass noch irgendein Webseitenersteller in irgendeiner Form Rücksicht auf die nimmt. Dann könnten ungefähr die Hälfte aller CSS3-Anweisungen bis heute noch nicht verwendet werden.

Ist in Chrome 13 auch der integrierte Android-Browser von Android 4.2, 4.3 und 4.4 auch gemeint? Diese haben nach wie vor eine hohe Verbreitung. Ich habe noch nicht die Zeit gehabt zu schauen, ob diese Browser darunter fallen. Wenn ja, wäre es unvorteilhaft darauf zu verzichten.

Da ich die Auswahl gerne in einem anderen Container haben möchte

Warum schränkst du dich selbst ein? Warum in einem anderen Container? Was willst du im Endeffekt erreichen?

Ich schränke mich nicht ein. Ich schränke mich ein, wenn ich die Auswahl auf den main-Container beschränke. Meine Absicht ist, die Auswahl flexibel vom Rest zu lassen. Ich hatte + und ~ bisher einfach falsch verstanden.

Die Verwendung des nav-Elements ist meiner Kenntnis nach in deinem Beispiel falsch. Das nav-Element ist in HTML5 nur für die Hauptnavigation gedacht.

Grundsätzlich nicht falsch, wenn ich beabsichtige eine Navigation daraus zu machen. Das ist nur als Spielwiese gedacht. Die Auswahl habe ich beabsichtigt in die nav geschrieben, weil ich die Auswahl wie schon geschrieben an einer anderen Stelle haben möchte.

Möglicherweise wäre es für ein konkreten Anwendungsfall so sinnvoll, aber den habe ich derzeit nicht.

Freundliche Grüße
Christian

[MrMurphy1]

Hallo

weil ich die Auswahl wie schon geschrieben an einer anderen Stelle haben möchte.

Das habe ich leider nicht verstanden. An welcher Stelle? In deinem Beispiel befinden sich label und input direkt über dem Text.

Gruss

MrMurphy

[Christian Wansart]

Guten Morgen MrMurphy,

Das habe ich leider nicht verstanden. An welcher Stelle? In deinem Beispiel befinden sich label und input direkt über dem Text.

ach die meinst du. Die input könnte ich theoretisch auch von den label trennen, aber müssen diese nicht auf der gleichen Ebene sein, um aufeinander zu verweisen? Ich bin mir da gerade nicht sicher, hatte da noch einiges ausprobiert was nicht so lief.

Ich meinte damit, dass die input/label von den jeweiligen section getrennt sind.

Freundliche Grüße
Christian

[Der Martin]

Hallo,

Das habe ich leider nicht verstanden. An welcher Stelle? In deinem Beispiel befinden sich label und input direkt über dem Text.

ach die meinst du. Die input könnte ich theoretisch auch von den label trennen, aber müssen diese nicht auf der gleichen Ebene sein, um aufeinander zu verweisen?

nein, müssen sie nicht. Sie sind ja durch die ID des input-Elements, die im for-Attribut vom label referenziert wird, eindeutig verknüpft. Das label kann daher an jeder beliebigen Stelle im Dokument stehen, nur das input muss bei dem Element stehen, das damit ein- oder ausgeblendet werden soll.

Theoretisch kannst du sogar mehrere label-Elemente an verschiedenen Stellen im Dokument haben, die auf dasselbe input verweisen (auch wenn mir gerade kein Beispiel einfällt, wo das ssinnvoll wäre).

Ich meinte damit, dass die input/label von den jeweiligen section getrennt sind.

Andersrum: label getrennt von input und section. Letztere bleiben beisammen - was aber unerheblich ist, wenn man das input (Checkbox?) sowieso unsichtbar macht.

So long,
 Martin

[MrMurphy1]

Hallo

Ich habe noch nicht die Zeit gehabt zu schauen, ob diese Browser darunter fallen. Wenn ja, wäre es unvorteilhaft darauf zu verzichten.

Vergiss den IE6 nicht. Chrome ist inzwischen bei der Version 51 oder 52 angelangt.

Ich meinte damit, dass die input/label von den jeweiligen section getrennt sind.

Du beschreibst leider nicht, was du überhaupt erreichen willst.

Gruss

MrMurphy

[Der Martin]

Hi,

Ich habe noch nicht die Zeit gehabt zu schauen, ob diese Browser darunter fallen. Wenn ja, wäre es unvorteilhaft darauf zu verzichten.

Vergiss den IE6 nicht.

und Netscape 4! ;-)

*scnr*,
 Martin

[Christian Wansart]

Hallo,

Vergiss den IE6 nicht. Chrome ist inzwischen bei der Version 51 oder 52 angelangt.

ich habe vor Ewigkeiten schon aufgehört, den IE6 extra zu testen. Windows XP bekam noch eine neuere Version, von der man ausgehen kann. Bei Android sieht es anders aus, da Google häufig selbst gar keine Updates rausschieben kann, sondern die Hersteller selbst. Android ist in der Hinsicht eine absolute Krücke, da selbst teurere „Top-Smartphones“ fast gar nicht mit Updates versehen werden. Hmm...

Du beschreibst leider nicht, was du überhaupt erreichen willst.

Ich will lediglich dieses Konzept testen. Man hat 3 Schaltflächen und kann damit die drei verschiedenen Sektionen Ein- und Ausblenden, so dass immer nur eine einzige sichtbar ist.

Freundliche Grüße
Christian

[MrMurphy1]

Hallo

Ich will lediglich dieses Konzept testen. Man hat 3 Schaltflächen und kann damit die drei verschiedenen Sektionen Ein- und Ausblenden, so dass immer nur eine einzige sichtbar ist.

Also doch ohne das ganze drumherum. No Problemo:

<!DOCTYPE html>
<html lang="de">
<head>
   <meta charset="utf-8">
   <title>Checkbox Hack</title>
   <meta name="description" content="HTML5, CSS3">
   <meta name="viewport" content="width=device-width, initial-scale=1.0">
   <style>
      section {
         display: none;
      }
      #checkbox-hack1:checked ~ section:nth-child(7),
      #checkbox-hack2:checked ~ section:nth-child(8),
      #checkbox-hack3:checked ~ section:nth-child(9) {
         display: block;
      }
   </style>
</head>
<body>
   <header>
   </header>
   <nav>
   </nav>
   <main>
      <article>
         <label for="checkbox-hack1">1. Absatz</label>
         <input id="checkbox-hack1" type="radio" name="checkbox-hack" checked>
         <label for="checkbox-hack2">2. Absatz</label>
         <input id="checkbox-hack2" type="radio" name="checkbox-hack">
         <label for="checkbox-hack3">3. Absatz</label>
         <input id="checkbox-hack3" type="radio" name="checkbox-hack">
         <section>
            <h1>1. Absatz</h1>
            <p>Eine Flagge ist eine abstrakte zweidimensionale Anordnung von Farben, Flächen und Zeichen in meist rechteckiger Form. Sie besteht in der Regel aus einem Tuch, aber auch andere Materialien, wie Papier, Plastik oder Metall, finden Verwendung. Deren gemaltes Bild erfüllt oft dieselben Zwecke wie die eigentliche Flagge.</p>
         </section>
         <section>
            <h1>2. Absatz</h1>
            <p>Flaggen dienen zur visuellen Übertragung von Informationen, ursprünglich über eine größere Distanz, wie von Schiff zu Schiff. Oft ist dies die Markierung der Zugehörigkeit beziehungsweise der Vertretung von Gemeinschaften und Körperschaften. Die Lehre vom Fahnen- und Flaggenwesen heißt Vexillologie (Flaggenkunde).</p>
         </section>
         <section>
            <h1>3. Absatz</h1>
            <p>Das Wort Flagge hat einen nordischen, vermutlich im 17. Jahrhundert in England aufgekommenen Ursprung, der vom altnordischen Wort flogra stammt, was flattern bedeutet. Um 1600, im Zuge der Entstehung von Nationalflaggen, hielt es in abgewandelter Form schließlich Einzug in den niederländischen und niederdeutschen bzw. neuniederländischen Sprachgebrauch und wurde so zur vlag (niederländisch: „Schiffsfahne“). Später wurde daraus im deutschen Sprachgebrauch dann Flagge.</p>
         </section>
      </article>
   </main>
   <footer>
   </footer>
</body>
</html>

Gruss

MrMurphy

[Gunnar Bittersmann]

@@MrMurphy1

No Problemo

Doch Problemo: Dass dir die Selektion per :nth-child() bei der nächstbesten Gelegenheit um die Ohren fliegt, solltest du inzwischen wissen.

LLAP 🖖

[MrMurphy1]

Hallo

Dass dir ...

Nö, mir nicht.

Du kannst ja gerne id und class verwenden. Zudem gibt es noch andere Selektoren.

Wo ist das Problem?

Gruss

MrMurphy

[marctrix]

Hej MrMurphy1,

Dass dir ...

Nö, mir nicht.

Na gut, sie fliegt dir nicht von selbst um die Ohren, sie wird dir um die Ohren gehauen. Fühlt sich auch nicht besser an. ;-)

Du kannst ja gerne id und class verwenden. Zudem gibt es noch andere Selektoren.

Du wolltest doch Christian helfen. Verbessere den Code doch entsprechend. Ich halte es auch für sehr viel sinnvoller, hier eine sprechende Verknüpfung zu finden durch geeignete Klassen.

Z. B. toggleFoo für den Button, der den Inhalt des Artikels mit der Klasse foo ein- und ausblendet.

Dann weiß jeder, der den Code liest, welches Element welche Funktion hat. Prima zu warten!

Die von @Gunnar Bittersmann verlinkten Folien hast du in deinem Code auch nicht berücksichtigt. Wenn man Kopiervorlagen ohne Erläuterung bereit stellt, fände ich es immer gut, wenn die als best-practise durchgehen. Sonst findet man demnächst viele Seiten im web, die sich nicht ordentlich bedienen lassen, obwohl der ursprüngliche Code von jemandem stammt, der es eigentlich besser kann.

Schade um die vertane Chance das Web ein bisschen besser zu machen...

Marc

[Gunnar Bittersmann]

@@MrMurphy1

Dass dir ...

Nö, mir nicht.

Du willst also bei Änderungen des Inhalts auch das Stylesheet ändern? Separation of concerns geht anders. Dann kannst du auch gleich Inline-Styles verwenden.

Du kannst ja gerne id und class verwenden. Zudem gibt es noch andere Selektoren.

Wo ist das Problem?

Dass :nth-child(42) nicht geeignet ist, ein bestimmtes Element zu selektieren, dass zum gegenwärtigen Zeitpunkt gerade zufällig das 42. ist.

LLAP 🖖

[Gunnar Bittersmann]

@@MrMurphy1

Abgesehen davon gibt es in Android wohl einen Bug

Eher schade, dass du auf die unsinnige Panikmache hereinfällst. Ich lese dort

Safari (5.1) and Chrome (13)

Ich lese dort oben „Android[-Browser]“. Der ist bis in die 4er Version hinein betroffen.

Dann könnten ungefähr die Hälfte aller CSS3-Anweisungen bis heute noch nicht verwendet werden.

Die Hälfte aller CSS3-Anweisungen sind genauso viele wie alle CSS3-Anweisungen.

Da ich die Auswahl gerne in einem anderen Container haben möchte

Warum schränkst du dich selbst ein? Warum in einem anderen Container?

Weil sich das Markup nach dem Inhalt, nicht nach der gewünschten Darstellung richten sollte‽

Die Verwendung des nav-Elements ist meiner Kenntnis nach in deinem Beispiel falsch.

Ja. Tabs (Reiter) – um sowas handelt es sich hier wohl, auch wenn’s (noch) nicht so gestylt ist – würde ich auch nicht mit nav auszeichnen.

LLAP 🖖

[Gunnar Bittersmann]

@@MrMurphy1

Und eine Liste kann [innerhalb des nav-Elements] verwendet werden. Sie ist aber sinnfrei und kann genau so gut weggelassen werden.

Das hatten wir irgendwann schon mal. Sinnfrei ist sie gewiss nicht.

Kann sie weggelassen werden? Da hab ich mal nachgefragt.

Heydon Pickering sagt’s und Léonie Watson bekräftigt’s noch mal: Mit Liste ist besser für Nutzer von Screenreadern.

Außerdem eröffnen mehr Elemente – wie ich damals schon sagte und Chris Heilmann beipflichtet – mehr Möglichkeiten zum Styling.

Im Übrigen sollte – wie Fabian Tempel und Lars Moelleken erwähnten – in nav-Elementen (wie auch in anderen Landmark-Elementen wie section) eine Überschrift vorhanden sein.

LLAP 🖖

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Heydon Pickering sagt’s und Léonie Watson bekräftigt’s noch mal: Mit Liste ist besser für Nutzer von Screenreadern.

+1 von Marco Zehe

Web 3 MrMurphy1 0

LLAP 🖖

[marctrix]

Hej Gunnar,

Heydon Pickering sagt’s und Léonie Watson bekräftigt’s noch mal: Mit Liste ist besser für Nutzer von Screenreadern.

+1 von Marco Zehe

Web 3 MrMurphy1 0

Ich sage auch: Listen sind besser. Eindeutig!

Aus welchem Grund sollte man denn drauf verzichten, MrMurphy1?

Marc

[Der Martin]

Hallo,

Heydon Pickering sagt’s und Léonie Watson bekräftigt’s noch mal: Mit Liste ist besser für Nutzer von Screenreadern.

+1 von Marco Zehe

Web 3 MrMurphy1 0

Ich sage auch: Listen sind besser. Eindeutig!

ob besser, will ich gar nicht beurteilen; ich finde aber, sie sind semantisch angebracht. Denn eine Navigation ist genau das: Eine Liste möglicher Sprungziele (Links).
Man könnte höchstens darüber diskutieren, ob die Reihenfolge relevant ist (ol) oder nicht (ul). Zwar sind die Navigationspunkte meist nach irgendeinem Gesichtspunkt angeordnet, aber es würde IMO in der Usability auch kein Nachteil entstehen, wenn sich die Reihenfolge ändert. Daher tendiere ich eher zur unsortierten Liste (ul).

Aus welchem Grund sollte man denn drauf verzichten, MrMurphy1?

Gute Frage! Nächste Frage? ;-)

So long,
 Martin

[marctrix]

Hej Der Martin,

Ich sage auch: Listen sind besser. Eindeutig!

ob besser, will ich gar nicht beurteilen;

Eine Liste können Screenreader-Nutzer mit einem Klick überspringen - versuch das mal mit drei Dutzend Links in einem durchschnittlichen Aufklapp-Menü (die man als Sehender natürlich gar nicht alle angezeigt bekommt) - wenn man von link zu Link hüpfen muss, kann das eine Weile dauern. Allein schon deshalb sind Listen besser... ;-)

Marc

[Camping_RIDER]

Aloha ;)

Offtopic - in der Sache bin ich nämlich völlig bei dir.

Web 3 MrMurphy1 0

"Formuliere höflich und wertschätzend."

*räusper* das hört sich doch nach Spott an, der weder notwendig war noch irgendeinen Mehrwert bietet.

Grüße,

RIDER

[Mistfinder]

Da hab ich mal nachgefragt.

Wozu das denn? Man befrage einfach einfach einen klassischen, gewiss nicht css-fähigen Textbrowser wie lynx oder w3m und frage sich, ob man das so präsentiert haben will. Das ist, war und bleibt die für normalsichtige effektivste Methode um zu sehen wie jeder blinde Benutzer(*) mit der Seite klarkommen wird.

Da muss man nicht "das halbe Internet" mit (vorliegend: merkwürdigen) Fragen belästigen um sich auf eine derartige Liste gleich meinender Dritter (ob die jetzt "prominent" oder "Meinungsführer" sind weiß ich nicht) stützen zu können.

*) Für die zahlreichen "SEO-Experten" da draußen: Auch Suchmaschinen sind in genau dieser Weise "blind" und das sind sehr wichtige Benutzer.

[Christian Kruse]

Hallo Mistfinder,

Da hab ich mal nachgefragt.

Wozu das denn?

Weil es immer jemanden gibt der klüger ist und/oder mehr weiß als man selbst.

LG,
CK

[marctrix]

Hej Mistfinder,

Da hab ich mal nachgefragt.

Wozu das denn? Man befrage einfach einfach einen klassischen, gewiss nicht css-fähigen Textbrowser wie lynx oder w3m und frage sich, ob man das so präsentiert haben will. Das ist, war und bleibt die für normalsichtige effektivste Methode um zu sehen wie jeder blinde Benutzer(*) mit der Seite klarkommen wird.

Blinde benutzen aber nicht lynx, sondern Jaws, NVDA oder manchmal auch ins Betriebssystem eingebaute Funktionen wie Sprachausgabe von iOS. - Die Experten, die @Gunnar Bittersmann zu recht befragt, sind nicht nur selber täglich auf dieses Hilfsmittel angewiesen und können darum auch subtilere Verbesserungen wahrnehmen. Sie sind auch noch alle im Gebiet "Entwicklung barrierefreier Webseiten" bewandert und haben neben der Praxis auch ein umfangreiches theoretisches Wissen über Standards und Softwarefähigkeiten - auch ein paar Generationen zurück.

Sie geben auch - wie in den Folien von Leonie Watson, die ebenfalls Gunnar hier verlinkt hat - auch noch Hinweise, wie man die Theorie in der Praxis anwendet.

Vor allem aber: lynx wertet vieles schlicht nicht aus, was Screenreader-Nutzern eine Website erst komfortabel macht (WAI-Aria-Attribute, Rollen, usw)

Es sind die vielen Kleinigkeiten in den Unterschieden. So wird eine Navigationsliste von lynx anders dargestellt als in einem Screenreader und in lynx ist eine Navigation ohne Liste viel weniger problematisch, als in einem Screenreader, denn lynx wird von einem Sehenden bedient, der nicht darauf angewiesen ist, diese liste überspringen zu können (auch wenn es nicht schön ist, die links einfach in einer Reihe stehen zu haben).

Mittels display: none versteckte Inhalte in einem aufklappbaren Navigationsmenü wie auf www.bildungsserveragrar.de werden von Lynx komplett angezeigt - von Screenreadern nicht, lynx unterstützt kein https und kann solche Seiten überhaupt nciht anzeigen usw...

Marc

[Gunnar Bittersmann]

@@marctrix

Mittels 
~~~css
display: none
~~~
 versteckte 

So geht das nicht. Um einen Codeblock zu erzeugen, hättest du eine Leerzeile davor und danach setzen müssen:

Mittels 

~~~
display: none
~~~

 versteckte 

Ich hab jetzt mal Inline-Code daraus gemacht:

Mittels 
`display: none`
versteckte 

Auf die Kennzeichnung als CSS-Code hab ich bewusst verzichtet, da der Syntaxhighlighter sowieso nur was mit kompletten Regeln Selektor { Eigenschaft: Wert } anfangen kann, aber nichts nur mit Deklarationen Eigenschaft: Wert.

LLAP 🖖

[Der Martin]

Moin,

Mittels 
~~~css
display: none
~~~
 versteckte 

So geht das nicht. Um einen Codeblock zu erzeugen, hättest du eine Leerzeile davor und danach setzen müssen:

ja, aber sogar die Forensoftware selbst macht das falsch, wenn man einen Block im Posting-Text markiert und mit dem Button oberhalb als Code auszeichnen will. Der fügt nämlich vor dem markierten Block noch eine weitere Leerzeile ein, auch wenn schon eine da ist, und die Leerzeile nach dem markierten Block fügt er vor dem abschließenden ~~~ ein, anstatt danach. Man muss also jedesmal wieder von Hand korrigieren. :-(

So long,
 Martin

[Auge]

Hallo

ja, aber sogar die Forensoftware selbst macht das falsch, wenn man einen Block im Posting-Text markiert und mit dem Button oberhalb als Code auszeichnen will. Der fügt nämlich vor dem markierten Block noch eine weitere Leerzeile ein, auch wenn schon eine da ist …

Das ist mir auch schon oft aufgefallen. Ich hab' dann mal ein Issue (#641) angelegt.

… und die Leerzeile nach dem markierten Block fügt er vor dem abschließenden ~~~ ein, anstatt danach.

Das ist mir noch nicht aufgefallen. Kommt es an dieser Stelle vielleicht auch darauf an, welche Zeilen man markiert, um sie mit den Kramdown-Tags auszuzeichnen?

Tschö, Auge

[Der Martin]

Hi,

ja, aber sogar die Forensoftware selbst macht das falsch, wenn man einen Block im Posting-Text markiert und mit dem Button oberhalb als Code auszeichnen will. Der fügt nämlich vor dem markierten Block noch eine weitere Leerzeile ein, auch wenn schon eine da ist …

Das ist mir auch schon oft aufgefallen. Ich hab' dann mal ein Issue (#641) angelegt.

so wichtig fand ich's nicht, dass ich es offiziell als Bug eintakten wollte, aber okay.

… und die Leerzeile nach dem markierten Block fügt er vor dem abschließenden ~~~ ein, anstatt danach.

Das ist mir noch nicht aufgefallen. Kommt es an dieser Stelle vielleicht auch darauf an, welche Zeilen man markiert, um sie mit den Kramdown-Tags auszuzeichnen?

Kann sein, aber ich markiere eigentlich immer genau von der ersten bis zur letzten Code-Zeile, nicht darüber hinaus. Wenn ich die schon vorhandene folgende Leerzeile mitmarkieren würde, wäre das Verhalten logisch und schlüssig.

Aber ich hab's gerade nochmal ein bisschen rumprobiert (nicht: Rum probiert): Wenn ich die letzte Zeile des gewünschten Code-Blocks nicht vollständig markiere, dann unterbleibt das Einfügen der Leerzeile vor den Tilden am Ende. Aber das ist IMO nicht üblich. Der Normalfall ist meines Erachtens eher, dass man den Cursor (oder Mauszeiger) an den Anfang der ersten gewünschten Code-Zeile setzt und dann einfach nach unten zieht. Dann ist auch die letzte Zeile vollständig (also einschließlich ihres Zeilenumbruchs) markiert, und es kommt zu der beschriebenen zusätzlichen Leerzeile.

So long,
 Martin

[Auge]

Hallo

… wenn man einen Block im Posting-Text markiert und mit dem Button oberhalb als Code auszeichnen will. Der fügt nämlich vor dem markierten Block noch eine weitere Leerzeile ein, auch wenn schon eine da ist …

Das ist mir auch schon oft aufgefallen. Ich hab' dann mal ein Issue (#641) angelegt.

so wichtig fand ich's nicht, dass ich es offiziell als Bug eintakten wollte, aber okay.

Ich glaube nicht, dass sich irgendwer darüber ärgern wird, wenn der Fehler weg sein wird, auch wenn er noch so klein ist.

… und die Leerzeile nach dem markierten Block fügt er vor dem abschließenden ~~~ ein, anstatt danach.

Kommt es an dieser Stelle vielleicht auch darauf an, welche Zeilen man markiert, um sie mit den Kramdown-Tags auszuzeichnen?

Der Normalfall ist meines Erachtens eher, dass man den Cursor (oder Mauszeiger) an den Anfang der ersten gewünschten Code-Zeile setzt und dann einfach nach unten zieht. Dann ist auch die letzte Zeile vollständig (also einschließlich ihres Zeilenumbruchs) markiert, und es kommt zu der beschriebenen zusätzlichen Leerzeile.

Aha! Es gibt also einen Unterschied in der Art, wie wir Text markieren. Ich nehme den Umbruch der letzten Zeile nicht mir in die Markierung. Da die Tags vor und hinter die Markierung in jeweils eine eigene Zeile gesetzt werden, steht das Endtag in der Zeile hinter der Markierung, die bei dir eine Zeile weiter reicht, völlig richtig.

Bleiben (in meiner Interpretation) die zusätzlichen Zeilen vor und nach dem Block (inklusive der Tags), die trotz schon vorhandener Leerzeilen erzeugt werden.

Tschö, Auge

[Der Martin]

Hi,

Der Normalfall ist meines Erachtens eher, dass man den Cursor (oder Mauszeiger) an den Anfang der ersten gewünschten Code-Zeile setzt und dann einfach nach unten zieht. Dann ist auch die letzte Zeile vollständig (also einschließlich ihres Zeilenumbruchs) markiert, und es kommt zu der beschriebenen zusätzlichen Leerzeile.

Aha! Es gibt also einen Unterschied in der Art, wie wir Text markieren.

ja, scheint so.

Ich nehme den Umbruch der letzten Zeile nicht mir in die Markierung.

Also genau das, was ich für "untypisch" gehalten habe (und umständlicher, finde ich), weil in meiner Betrachtungsweise der abschließende Zeilenumbruch zur Zeile dazugehört. Ebenso wie ich in Word oder Writer die Absatzmarke als Bestandteil des Absatzes mitmarkiere, wenn ich eine Absatzformatierung anwenden möchte.

Da die Tags vor und hinter die Markierung in jeweils eine eigene Zeile gesetzt werden, steht das Endtag in der Zeile hinter der Markierung, die bei dir eine Zeile weiter reicht, völlig richtig.

Ja. Mit der JS-Zeile, die Christian rausgesucht hat, kann ich das auch theoretisch nachvollziehen.

Bleiben (in meiner Interpretation) die zusätzlichen Zeilen vor und nach dem Block (inklusive der Tags), die trotz schon vorhandener Leerzeilen erzeugt werden.

Da hat Christian wohl den "Fehler" im Auge gehabt, dass jemand auch Code im Fließtext markieren könnte (ohne Zeilenumbruch davor oder danach). Daraus wird dann ein Block mit Umbrüchen am Anfang und am Ende. Richtig gerendert wird er aber dennoch nicht, weil die Leerzeilen vor bzw. nach den Tilden fehlen. Um alle Fälle "korrekt" zu bedienen, müsste man also tatsächlich untersuchen, ob vor und/oder nach dem markierten Text Zeilenumbrüche vorhanden sind, und falls nicht, jeweils einen weiteren Zeilenumbruch einfügen.
Viel Aufwand für wenig Nutzen, oder?

Ciao,
 Martin

[Auge]

Hallo

Ich nehme den Umbruch der letzten Zeile nicht mir in die Markierung.

Also genau das, was ich für "untypisch" gehalten habe (und umständlicher, finde ich), weil in meiner Betrachtungsweise der abschließende Zeilenumbruch zur Zeile dazugehört.

Logisch gehört der Umbruch der letzten Zeile eines Blockes natürlich zum Block. Wenn ich aber etwas markiere, versuche ich nur den notwendigen Bereich zu markieren. Das gerade dann, wenn ich das Verhalten der Funktion, die ich nutzen möchte, kenne. Schließlich versuche ich ja, ein erwartbares Ergebnis zu erzielen. Wenn ich also weiß, dass ich mit der Markierung des abschließenden Umbruchs eine Zeile erhalte, die ich wieder entfernen „muss“, suche ich sie mit vertretbarem Aufwand zu vermeiden. Das Weglassen des Umbruchs aus der Markierung gehört mMn dazu.

Bleiben (in meiner Interpretation) die zusätzlichen Zeilen vor und nach dem Block (inklusive der Tags), die trotz schon vorhandener Leerzeilen erzeugt werden.

Da hat Christian wohl den "Fehler" im Auge gehabt, dass jemand auch Code im Fließtext markieren könnte (ohne Zeilenumbruch davor oder danach). Daraus wird dann ein Block mit Umbrüchen am Anfang und am Ende. Richtig gerendert wird er aber dennoch nicht, weil die Leerzeilen vor bzw. nach den Tilden fehlen. Um alle Fälle "korrekt" zu bedienen, müsste man also tatsächlich untersuchen, ob vor und/oder nach dem markierten Text Zeilenumbrüche vorhanden sind, und falls nicht, jeweils einen weiteren Zeilenumbruch einfügen.
Viel Aufwand für wenig Nutzen, oder?

In Bezug auf unsere Quelltextpedanterie wohl schon. Um Fehldarstellungen zu vermeiden, mMn nicht. Also ja, wenn es „goldrichtig“ gemacht werden soll, müssten wohl zwei Zeilen um die Markierung herum auf Zeilenumbrüche geprüft und diese im Zweifelsfall auf die „richtige Art“™ ergänzt werden.

Tschö, Auge

[Christian Kruse]

Hallo Martin,

ja, aber sogar die Forensoftware selbst macht das falsch, wenn man einen Block im Posting-Text markiert und mit dem Button oberhalb als Code auszeichnen will.

Nö, die macht das eigentlich schon ganz ok.

Der fügt nämlich vor dem markierten Block noch eine weitere Leerzeile ein, auch wenn schon eine da ist, […]

Das macht ja nichts, die stört höchstens dein ästhetisches Empfinden. Für das Rendering ist sie allerdings irrelevant.

und die Leerzeile nach dem markierten Block fügt er vor dem abschließenden ~~~ ein, anstatt danach.

Nein, sie fügt eine Leerzeile sowohl vor als auch nach dem ~~~ ein:

e.replaceSelection('\n~~~' + (lang || "") + '\n' + chunk + '\n~~~\n');

LG,
CK

[Matthias Apsel]

Hallo Der Martin,

ja, aber sogar die Forensoftware selbst macht das falsch, wenn man einen Block im Posting-Text markiert und mit dem Button oberhalb als Code auszeichnen will. Der fügt nämlich vor dem markierten Block noch eine weitere Leerzeile ein, auch wenn schon eine da ist,

was aber nicht schlimm ist, da mehrere Leerzeilen

zusammenfallen.

Bis demnächst
Matthias

[Auge]

Hallo

ja, aber sogar die Forensoftware selbst macht das falsch, wenn man einen Block im Posting-Text markiert und mit dem Button oberhalb als Code auszeichnen will. Der fügt nämlich vor dem markierten Block noch eine weitere Leerzeile ein, auch wenn schon eine da ist,

was aber nicht schlimm ist, da mehrere Leerzeilen

zusammenfallen.

Technisch ist das kein Fehler, wie du mit deinem Posting beweist. Komisch sieht's beim erstellen bzw. bearbeiten des Postings trotzdem aus. Was bleibt, ist die verbesserungswürdige Prüfung, ob beim einfügen genügend Umbrüche erzeugt werden (Inline markierter Code wird als Codeblock ausgezeichnet, um nachher als Codeblock gerendert zu werden, fehlen aber Umbrüche).

Tschö, Auge

[Der Martin]

Moin,

was aber nicht schlimm ist, da mehrere Leerzeilen

zusammenfallen.

Technisch ist das kein Fehler, wie du mit deinem Posting beweist. Komisch sieht's beim erstellen bzw. bearbeiten des Postings trotzdem aus.

ACK.

Was bleibt, ist die verbesserungswürdige Prüfung, ob beim einfügen genügend Umbrüche erzeugt werden (Inline markierter Code wird als Codeblock ausgezeichnet, um nachher als Codeblock gerendert zu werden, fehlen aber Umbrüche).

Die Königslösung wäre natürlich, wenn ein Abschnitt, der inline markiert ist (also ohne Zeilenumbruch am Blockanfang bzw. -ende), dann auch nur als inline-Code ausgezeichnet würde.

So long,
 Martin

[Auge]

Hallo

Was bleibt, ist die verbesserungswürdige Prüfung, ob beim einfügen genügend Umbrüche erzeugt werden (Inline markierter Code wird als Codeblock ausgezeichnet, um nachher als Codeblock gerendert zu werden, fehlen aber Umbrüche).

Die Königslösung wäre natürlich, wenn ein Abschnitt, der inline markiert ist (also ohne Zeilenumbruch am Blockanfang bzw. -ende), dann auch nur als inline-Code ausgezeichnet würde.

Das heißt, es gibt drei Wege.

1. Suche um den markierten Bereich herum nach Zeilenumbrüchen, ergänze diese bei Bedarf und erzeuge immer ein (dann sauber eingefassten) Codeblock.
2. Ermittle, ob direkt vor und hinter dem markierten Bereich Zeilenumbrüche vorhanden sind und verwende, wenn das nicht der Fall ist, die Markierungen für Inlinecode statt der Codeblockmarkierung. Frage: Wie groß soll das zu prüfende Umfeld sein? Wie sollen neben vorhandenen Umbrüchen und Leerzeichen andere Zeichen gewertet werden?
3. Belasse alles beim alten (zu viel Aufwand) und vertraue (zumindest bei den Regulars) darauf, dass sie die Korrekturen händisch vornehmen.

Tschö, Auge

[Der Martin]

Hi,

Die Königslösung wäre natürlich, wenn ein Abschnitt, der inline markiert ist (also ohne Zeilenumbruch am Blockanfang bzw. -ende), dann auch nur als inline-Code ausgezeichnet würde.

Das heißt, es gibt drei Wege.

1. Suche um den markierten Bereich herum nach Zeilenumbrüchen, ergänze diese bei Bedarf und erzeuge immer ein (dann sauber eingefassten) Codeblock.

Das wäre - aus unserer beider Sicht - die Korrektur des jetzigen Mechanismus.

2. Ermittle, ob direkt vor und hinter dem markierten Bereich Zeilenumbrüche vorhanden sind und verwende, wenn das nicht der Fall ist, die Markierungen für Inlinecode statt der Codeblockmarkierung.

Das wäre eine Erweiterung der bisherigen Funktionalität.

Wie groß soll das zu prüfende Umfeld sein?

Äh, die Frage ist mir nicht ganz klar. Welches Umfeld? Zu untersuchen sind IMO nur das letzte Zeichen vor und das erste Zeichen nach der Markierung. Nur wenn beides Zeilenumbrüche sind, erzeuge einen Block, andernfalls eine Inline-Auszeichnung (der markierte Code könnte ja am Anfang oder am Ende eines Absatzes stehen).

Wie sollen neben vorhandenen Umbrüchen und Leerzeichen andere Zeichen gewertet werden?

Was für andere Zeichen? Und wieso willst du Leerzeichen mit betrachten? Die tun doch nichts, die wollen nur spielen. ;-)

3. Belasse alles beim alten (zu viel Aufwand) und vertraue (zumindest bei den Regulars) darauf, dass sie die Korrekturen händisch vornehmen.

Angesichts des Aufwand/Nutzen-Verhältnisses wäre das meine Empfehlung. Sagte ich ja schon.

So long,
 Martin

[Auge]

Hallo

2. Ermittle, ob direkt vor und hinter dem markierten Bereich Zeilenumbrüche vorhanden sind und verwende, wenn das nicht der Fall ist, die Markierungen für Inlinecode statt der Codeblockmarkierung.

Das wäre eine Erweiterung der bisherigen Funktionalität.

Wie groß soll das zu prüfende Umfeld sein?

Äh, die Frage ist mir nicht ganz klar. Welches Umfeld? Zu untersuchen sind IMO nur das letzte Zeichen vor und das erste Zeichen nach der Markierung. Nur wenn beides Zeilenumbrüche sind, erzeuge einen Block, andernfalls eine Inline-Auszeichnung (der markierte Code könnte ja am Anfang oder am Ende eines Absatzes stehen).

Wie sollen neben vorhandenen Umbrüchen und Leerzeichen andere Zeichen gewertet werden?

Was für andere Zeichen? Und wieso willst du Leerzeichen mit betrachten?

Wie oft wird hier Code per copy'n'paste reingeworfen, bei dem weder die Bedingung das letzte Zeichen vor und das erste Zeichen nach dem markierten Bereich sind Umbrüche (für Codeblock) oder jeweils Leerzeichen (für Inlinecode) zutrifft? Wie oft wird (wie von dir) „falsch“™ markiert? Nicht, dass ich glaubte, man könne alle diese Fälle abfangen. Ich fände es aber schön, die gängigsten ^[1] bei technischer Machbarkeit zu entschärfen.

1. Belasse alles beim alten (zu viel Aufwand) und vertraue (zumindest bei den Regulars) darauf, dass sie die Korrekturen händisch vornehmen.

Angesichts des Aufwand/Nutzen-Verhältnisses wäre das meine Empfehlung. Sagte ich ja schon.

Dann bleiben aber leider die viel häufiger vorkommenden Fehlformatierungen durch „Nichtregulars“ übrig. Schön ist anders.

Tschö, Auge

---

1. Nicht, dass ich definieren könnte, welche das sein werden. ↩︎

[Der Martin]

Hi,

Wie sollen neben vorhandenen Umbrüchen und Leerzeichen andere Zeichen gewertet werden?

Was für andere Zeichen? Und wieso willst du Leerzeichen mit betrachten?

Wie oft wird hier Code per copy'n'paste reingeworfen, bei dem weder die Bedingung das letzte Zeichen vor und das erste Zeichen nach dem markierten Bereich sind Umbrüche (für Codeblock) oder jeweils Leerzeichen (für Inlinecode) zutrifft?

gegen schlampiges Einfügen ist wohl kein Kraut gewachsen. Aber ich bin bisher gar nicht auf die Idee gekommen, dass inline-Code von Leerzeichen begrenzt sein müsste (aber zumindest habe ich jetzt verstanden, worauf du mit den Leerzeichen hinaus wolltest). Davor und danach kann doch eigentlich jedes beliebige Zeichen stehen. Andernfalls müsste man ja tatsächlich eine Whitelist sinnvoller Zeichen haben (Blank, Komma, Punkt, Fragezeichen, Bindestrich, Klammern uvm).

Wie oft wird (wie von dir) „falsch“™ markiert?

Von mir nicht! Ich markiere immer komplette Zeilen! ;-)

1. Belasse alles beim alten (zu viel Aufwand) und vertraue (zumindest bei den Regulars) darauf, dass sie die Korrekturen händisch vornehmen.

Angesichts des Aufwand/Nutzen-Verhältnisses wäre das meine Empfehlung. Sagte ich ja schon.

Dann bleiben aber leider die viel häufiger vorkommenden Fehlformatierungen durch „Nichtregulars“ übrig. Schön ist anders.

Das stimmt, aber meist findet sich innerhalb weniger Minuten jemand mit Edit-Berechtigung, der das mal schnell in Ordnung bringt.

So long,
 Martin

[Gunnar Bittersmann]

@@Mistfinder

Da hab ich mal nachgefragt.

Wozu das denn?

Weil ich nicht alles weiß, aber genügend Leute kenne, die mehr wissen als ich.

Man befrage einfach einfach einen klassischen, gewiss nicht css-fähigen Textbrowser wie lynx oder w3m und frage sich, ob man das so präsentiert haben will. Das ist, war und bleibt die für normalsichtige effektivste Methode um zu sehen wie jeder blinde Benutzer(*) mit der Seite klarkommen wird.

Nein, ein Textbrowser sagt dir nicht, wie ein Screenreader eine Liste vorliest: „foo, bar, baz“ oder „Listenpunkt: foo, Listenpunkt: bar, Listenpunkt: baz“.

Da muss man nicht "das halbe Internet"

So viele Follower hab ich nun auch wieder nicht.

mit (vorliegend: merkwürdigen) Fragen belästigen

140 Zeichen setzen da eine Grenze.

um sich auf eine derartige Liste gleich meinender Dritter (ob die jetzt "prominent" oder "Meinungsführer" sind weiß ich nicht) stützen zu können.

Zwei derer, die geantwortet haben, sind selbst blind. Wissen also nicht nur, wovon sie sprechen, sondern tun das auch noch aus eigener Erfahrung. Prominente Meinungsführer.

LLAP 🖖