Text-Input als Summary verwenden

[Camping_RIDER]

Aloha ;)

Im verlinkten Codepen-Minimalbeispiel verwende ich ein Text-Input innerhalb eines Summary. Das Problem, auf das ich dabei stoße: eine Eingabe mit Leertaste führt nicht nur zum Einfügen eines Leerzeichens im Textfeld, sondern auch zum Aufklappen des Details-Elements.

Das würde ich gerne vermeiden ohne das Markup großartig anzupassen.

Ich habe per Javascript schon einiges versucht - aber stoße da auf unüberwindbare Probleme.

Mit stopPropagation kann ich zwar das Bubbling aufhalten, aber nicht verhindern, dass das details-Element aufklappt - weil das ja eine default-Action ist und kein Event-Aufruf.

Mit preventDefault kann ich zwar das Aufklappen aufhalten, halte damit aber gleichzeitig die Eingabe auf.

Wenn ich preventDefault verwende und das Leerzeichen dann händisch ins Textfeld einfüge verliere ich Browser-Features wie Strg+Z zum Rückgängig machen der Eingabe.

Letztere Lösung habe ich mal im Codepen hinterlegt, kann man über die Checkbox aktivieren. So geht das jetzt erstmal online... als Provisorium.

Ich bin da gerade etwas ratlos. Natürlich könnte ich workarounds finden, z.B. indem ich kein details...summary verwende, sondern was per Javascript zusammenbastle. Das ist aber nicht mein Ziel.

Prinzipiell fände ich es auch denkbar das Markup zu verändern. Wichtig wäre aus meiner Sicht, dass es im zusammengeklappten Zustand möglichst schlank bleibt. Eine Situation, dass das Eingabefeld für sich alleine steht und im Summary ein Text wie "Was bedeutet das?" steht, hätte ich natürlich ziehen können, wollte ich aber eigentlich vermeiden.

Vielleicht hat ja jemand von euch noch eine sinnvolle Lösung für mein Dilemma? Ich bin auch für Fundamentalkritik an meinem Ansatz natürlich offen.

Grüße,

RIDER

[MudGuard]

Hi,

Im verlinkten Codepen-Minimalbeispiel verwende ich ein Text-Input innerhalb eines Summary. Das Problem, auf das ich dabei stoße: eine Eingabe mit Leertaste führt nicht nur zum Einfügen eines Leerzeichens im Textfeld, sondern auch zum Aufklappen des Details-Elements.

Das kann ich im Desktop-Firefox 108.0.1 unter Windows 10 Pro nicht nachvollziehen.
Ein Leerzeichen im Input ändert nix am Aufklapp-Status.

cu,
Andreas a/k/a MudGuard

[Camping_RIDER]

Aloha ;)

Im verlinkten Codepen-Minimalbeispiel verwende ich ein Text-Input innerhalb eines Summary. Das Problem, auf das ich dabei stoße: eine Eingabe mit Leertaste führt nicht nur zum Einfügen eines Leerzeichens im Textfeld, sondern auch zum Aufklappen des Details-Elements.

Das kann ich im Desktop-Firefox 108.0.1 unter Windows 10 Pro nicht nachvollziehen.
Ein Leerzeichen im Input ändert nix am Aufklapp-Status.

Ah - interessant. Jetzt, wo du's sagst: Bei mir im Linux-Firefox auch kein Problem. Im Linux-Chrome hingegen schon. Leider.

Grüße,

RIDER

[Rolf B]

Hallo Camping_RIDER,

Text-Input innerhalb eines Summary.

Lass es sein. Das ist verboten.

Es entsteht die Hierarchie details > summary > text-input

Details und text-input sind interaktiv. Interaktive Elemente dürfen nicht geschachtelt werden.

Rolf

[Camping_RIDER]

Aloha ;)

Details und text-input sind interaktiv. Interaktive Elemente dürfen nicht geschachtelt werden.

Ich sehe ein, dass das zwangsläufig Probleme ergibt, interaktive Elemente zu verschachteln - aber wo steht, dass das verboten ist?

Grüße,

RIDER

[Rolf B]

Hallo Camping_RIDER,

in der HTML Spec. Hätte ich jetzt jedenfalls gedacht. Die genaue Stelle muss ich noch finden.

Jedenfalls hat Gunnar sowas schon oft genug gesagt…

Update: Ups. Beim <summary> steht als Content-Type "phrasing content intermixed with heading content" - und input ist phrasing content. Beim <details> Element steht zwar "interactive", aber interaktiver Inhalt ist nicht explizit verboten, so wie bei a oder button.

Jetzt bin ich verwirrt.

Rolf

[Camping_RIDER]

Aloha ;)

in der HTML Spec. Hätte ich jetzt jedenfalls gedacht. Die genaue Stelle muss ich noch finden.

Ich sehe hier, dass in Summary phrasing content erlaubt ist, was laut hier auch input umfasst...?

Grüße,

RIDER

[Rolf B]

Hallo Camping_RIDER,

ja. Daher mein Update. Ich bin verwirrt. Aber das Schachteln interaktiver Elemente sollte definitiv verboten sein, das führt sonst nur ins Bedienungschaos.

Rolf

[Rolf B]

Hallo Camping_RIDER,

immerhin habe ich die Frage bei StackOverflow gefunden. Ausgehend von einer jQuery-„Lösung“ gibt's noch diese Alternative zum Rumspielen mit Selections:

for (let sum of document.querySelectorAll('summary input')) {
  sum.addEventListener('keyup',  handleInputInSummary);
}

function handleInputInSummary(event) {
  if (event.key == " " && event.target.tagName == "INPUT") {
    let d = event.target.closest("details");
    d.hasAttribute("open") ? d.removeAttribute("open") : d.setAttribute("open", "");
  }
}

Im SO Artikel werden auch Bedenken zur Accessibility geäußert, denen wird aber auch widersprochen. Ich kann's nicht wirklich beurteilen.

Rolf

[Camping_RIDER]

Aloha ;)

for (let sum of document.querySelectorAll('summary input')) {
  sum.addEventListener('keyup',  handleInputInSummary);
}

function handleInputInSummary(event) {
  if (event.key == " " && event.target.tagName == "INPUT") {
    let d = event.target.closest("details");
    d.hasAttribute("open") ? d.removeAttribute("open") : d.setAttribute("open", "");
  }
}

Ja - die Idee dahinter ist, dass details-Element schnell wieder zuzuklappen nachdem es geöffnet wurde.

In dem Fall sogar auf eine problematische Weise, weil es immer geschlossen wird (was, wenn der User es geöffnet hatte?).

Ich habe das selbe auch schon versucht, mit einer toggle-Lösung statt always-closed.

Funktioniert, aber leider nicht wie gewünscht. Es folgt leider trotzdem ein auf-zu-flackern das stört.

Im SO Artikel werden auch Bedenken zur Accessibility geäußert, denen wird aber auch widersprochen.

Accessibility ist deshalb nicht negativ betroffen, weil man mit Tastatur immer noch den parentNode des Input errreicht und den ganz normal aufklappen kann.

Mir schwant, dass es für dieses technische Problem keine zufriedenstellende Lösung gibt. Hrmpf. Aktuell kommt mein Provisorium dem erwünschten Verhalten wohl noch am nächsten. Vielleicht muss ich doch zu einer "Was ist das?"-Lösung als summary greifen.

Grüße,

RIDER

[Gunnar Bittersmann]

@@Camping_RIDER

Im verlinkten Codepen-Minimalbeispiel verwende ich ein Text-Input innerhalb eines Summary. Das Problem, auf das ich dabei stoße: eine Eingabe mit Leertaste führt nicht nur zum Einfügen eines Leerzeichens im Textfeld, sondern auch zum Aufklappen des Details-Elements.

Du beschreibst nicht das Problem, sondern das, was du für eine Lösung hältst.

Was ist das eigentliche Problem, das du mit diesem kruden Markup zu lösen gedenkst?

🖖 Живіть довго і процвітайте

[Camping_RIDER]

Aloha ;)

Du beschreibst nicht das Problem, sondern das, was du für eine Lösung hältst.

Jein. Du hast insofern Recht...

Was ist das eigentliche Problem, das du mit diesem kruden Markup zu lösen gedenkst?

...dass ich ein anderes Markup verwenden könnte um mein primäres Problem zu lösen. Richtig. Schrieb ich ja auch.

Ich habe aber neben der konkreten Anwendung, die mein primäres Problem ist (was, wie du korrekt schreibst, anders einfach lösbar wäre), noch ein sekundäres gefunden (und das ist das, auf was ich mich hier beziehe):

Wenn es sich bei diesem Beispiel um valides Markup handelt (und mir scheint das so, ob man das jetzt anders lösen kann oder nicht) - kann ich es dann irgendwie dazu bringen, sich erwartungsgemäß (wie im Firefox, eine Texteingabe triggert kein weiteres Verhalten) zu verhalten oder muss ich mit dem leben, was Chrome/Webkit da kruderweise draus macht?

Grüße,

RIDER

[Rolf B]

Hallo Janosch,

das verrückteste ist: Das keyup-Event blubbert im Firefox ganz normal nach oben, zum Summary Element. Aber wenn es in einem input-Element generiert wurde, dann löst es im Summary nichts aus. Macht der Fuchs da etwa eine Abfrage auf target == currentTarget?

Gleich mal getestet, ob das auch die Chromia mittun:

for (let inp_in_sum of document.querySelectorAll("summary input")) {
  inp_in_sum.closest("summary")
            .addEventListener("keyup", function(event) {
    if (event.target != event.currentTarget) {
      event.preventDefault();
    }
  });
}

Im Firefox keine Veränderung, und Chrome ist jetzt brav. Diese Lösung finde ich akzeptabel, es gibt kein Fummeln am open-Attribut und kein Nachschieben von Spaces über das Selection Objekt. Ohne JavaScript tanzt der Bildschirm halt ein bisschen. Das könntest Du in deiner geschlossenen Benutzergruppe aber ggf. regeln.

Das closest könnte man sich mit dem Selektor "summary:has(input)" ersparen. Aber :has ist in Chromia gerade mal ein Vierteljahr alt und im Firefox noch experimentell.

Rolf

[Camping_RIDER]

Aloha ;)

das verrückteste ist: Das keyup-Event blubbert im Firefox ganz normal nach oben, zum Summary Element. Aber wenn es in einem input-Element generiert wurde, dann löst es im Summary nichts aus. Macht der Fuchs da etwa eine Abfrage auf target == currentTarget?

Ah - coole Analyse! Ich hab gar nicht gepeilt, dass das aufklappen bei keyup passiert; ich war im Wesentlichen immer bei keydown, außerdem hatte ich currentTarget gar nicht auf dem Schirm.

Gleich mal getestet, ob das auch die Chromia mittun:

for (let inp_in_sum of document.querySelectorAll("summary input")) {
  inp_in_sum.closest("summary")
            .addEventListener("keyup", function(event) {
    if (event.target != event.currentTarget) {
      event.preventDefault();
    }
  });
}

Im Firefox keine Veränderung, und Chrome ist jetzt brav. Diese Lösung finde ich akzeptabel, es gibt kein Fummeln am open-Attribut und kein Nachschieben von Spaces über das Selection Objekt. Ohne JavaScript tanzt der Bildschirm halt ein bisschen. Das könntest Du in deiner geschlossenen Benutzergruppe aber ggf. regeln.

Mega - genau diese Lösung habe ich gesucht. Vielen Dank fürs Dranbleiben und ausprobieren. Ich habe das Pen eben entsprechend mit der Lösung geupdatet.

Das closest könnte man sich mit dem Selektor "summary:has(input)" ersparen. Aber :has ist in Chromia gerade mal ein Vierteljahr alt und im Firefox noch experimentell.

Tatsächlich ist closest gar nicht zwingend notwendig. Da das preventDefault ausschließlich im Input nicht feuern darf, danach aber jederzeit, ist es sogar völlig egal, ob das preventDefault schon im parentNode von input passiert. Das ist unschädlich, siehe pen.

Grüße,

RIDER

[Felix Riesterer]

Lieber Camping_RIDER,

Du willst also ein Textinput nur auf Verlangen verfügbar machen? Dazu verwendet man doch üblicherweise eine Checkbox, deren Status die Sichtbarkeit von Siblings regelt. Dass das mit details/summary scheinbar auch möglich ist, bedeutet nicht, dass man dafür details/summary nutzen muss.

Liebe Grüße

Felix Riesterer

[Rolf B]

Hallo Felix,

was im summary steht, ist immer sichtbar.

Problem ist hier die sich beißende Interaktivität von details/summary und input Element

Rolf

[Camping_RIDER]

Aloha ;)

Du willst also ein Textinput nur auf Verlangen verfügbar machen?

Du hattest also vor deiner Antwort das verlinkte Minimalbeispiel gar nicht angeschaut? 😉

Grüße,

RIDER

[Matthias Scharwies]

Servus! Warum nicht so?

 <input id="eingabe" value="Hier kann man was eingeben">
<label for="eingabe">
<details>
  <summary>Eingabefeld:  </summary>
  Hier steht eine langatmige Erklärung dazu, was das Eingabefeld bewirkt. Sie muss normalerweise unsichtbar sein, weil sie schlicht und ergreifend zu lang wäre. Das Problem: Gibt man einen Text ins Eingabefeld ein, so klappt dieser Text bei jedem Leerzeichen auf und zu.
</details>
</label>

Herzliche Grüße

Matthias Scharwies

[Gunnar Bittersmann]

@@Matthias Scharwies

Warum nicht so?

 <input id="eingabe" value="Hier kann man was eingeben">
<label for="eingabe">
<details>
  <summary>Eingabefeld:  </summary>
  Hier steht eine langatmige Erklärung dazu, was das Eingabefeld bewirkt. Sie muss normalerweise unsichtbar sein, weil sie schlicht und ergreifend zu lang wäre. Das Problem: Gibt man einen Text ins Eingabefeld ein, so klappt dieser Text bei jedem Leerzeichen auf und zu.
</details>
</label>

Die Beschriftung hinter dem Eingabefeld?

Warum nicht so?

<label for="eingabe">Eingabefeld</label>
<input id="eingabe" value="Hier kann man was eingeben">
<details>
  <summary>Erklärung</summary>
  <p>Hier steht eine langatmige Erklärung dazu, was das Eingabefeld bewirkt. Sie muss normalerweise unsichtbar sein, weil sie schlicht und ergreifend zu lang wäre.</p>
<details>

🖖 Живіть довго і процвітайте

[Raketenwilli]

Warum nicht so?

<label for=…
<input id=…

So wie ich das sehe, liegst Du goldrichtig: „Semantik“ vers. „technisch möglich“. In einem Textbrowser würde das Problem offenbar.

Merkwürdig ist, dass zwar Typos und etwas wie „PDF-Format“ straffrei angemeckert wird, aber fachlich vertretbare Fachkritik zu Abwertungen führt.

[Rolf B]

Hallo Raketenwilli,

E war nicht mein Minus, aber ich finde trotzdem, dass Gunnar als unser UI Papst eins verdient hat.

Die Idee von Matthias war ja, input und details über das label zu verheiraten, und statt einfach das Standardpattern rauszuhauen wäre ein Kommentar nützlich gewesen, ob dieses Konstrukt zulässig und zugänglich ist.

Denn auch hierbei generiert man einen Interaktionskonflikt: ein Klick auf das Label fokussiert normalerweise das gelabelte-Element.

Rolf

[Camping_RIDER]

Aloha ;)

Die Idee von Matthias war ja, input und details über das label zu verheiraten, und statt einfach das Standardpattern rauszuhauen wäre ein Kommentar nützlich gewesen, ob dieses Konstrukt zulässig und zugänglich ist.

Ja. Deshalb schrieb ich ja schon die ganze Zeit und immer, dass ein geändertes Markup nicht das ist, was ich suche.

Mir ging es tatsächlich darum:

Denn auch hierbei generiert man einen Interaktionskonflikt: ein Klick auf das Label fokussiert normalerweise das gelabelte-Element.

Ob es möglich ist, diesen Interaktionskonflikt aufzuheben - egal ob jetzt in meiner Version oder in Matthias' Version.

Natürlich kann man mit anderem Markup das Problem prinzipiell auch umgehen - und es ist vielleicht nicht unklug, das zu tun, weil man nur so auch in exotischen Browsern ziemlich sicher sein kann, dass alles funktioniert. Daher hat Gunnar von mir - obwohl er mein formuliertes Problem nicht gelöst, sondern nur umgangen hat - von mir ein Plus gekriegt...

Grüße,

RIDER

[Raketenwilli]

Naja ... die von mir angesprochenen Textbrowser (lyncs, links, w3m (¹)) sind auf Systemen ohne GUI manchmal weniger exotisch als nützlich. Ich „mache“ zur Zeit viel mit schlanken virtuellen Linux-Maschinen „herum“ und da ist die Nutzung eines Textbrowsers durchaus eine schöne Möglichkeit, die Erfordernisse eines grafischen Systems sowie die Trägheit eines Remote-Desktops oder dergleichen zu vermeiden. Nichts für den Alltag, aber einfacher als Daten am Desktop herunterladen und dann mit scp zu “verschubsen“.

• Zudem ist die Erfindung des Herrn Braille offenbar immer noch in Gebrauch.

¹) Ich selbst nehme diese übrigens deshalb auch für die Kontrolle meiner Ergebnisse.

[Camping_RIDER]

Aloha ;)

Naja ... die von mir angesprochenen Textbrowser (lyncs, links, w3m (¹)) sind auf Systemen ohne GUI manchmal weniger exotisch als nützlich.

Das war jetzt ein Missverständnis. Mit exotische Browser meinte ich explizit nicht die von dir angesprochenen Textbrowser (die sind für mich nicht exotisch, sondern funktionieren einfach völlig anders - aber da ist ein auf/zugeklapptes details-Element eh kein Problem), sondern mein Gedanke ging eher an normale grafische Browser, die sich nochmal anders verhalten als Chrome und Firefox.

Grüße,

RIDER

[Gunnar Bittersmann]

@@Raketenwilli

Merkwürdig ist, dass zwar Typos und etwas wie „PDF-Format“ straffrei angemeckert wird, aber fachlich vertretbare Fachkritik zu Abwertungen führt.

Die Bewertungsfunktion war hier schon immer ein Glücksspiel. Manche können mit ihr umgehen, manche nicht.

🖖 Живіть довго і процвітайте

[Camping_RIDER]

Aloha ;)

Warum nicht so?

<label for="eingabe">Eingabefeld</label>
<input id="eingabe" value="Hier kann man was eingeben">
<details>
  <summary>Erklärung</summary>
  <p>Hier steht eine langatmige Erklärung dazu, was das Eingabefeld bewirkt. Sie muss normalerweise unsichtbar sein, weil sie schlicht und ergreifend zu lang wäre.</p>
<details>

Das scheint mir letztlich tatsächlich die einzige Lösung zu sein, die so richtig funktioniert - was die ursprüngliche Frage nicht beantwortet, mir aber letztlich in der Primärproblematik natürlich trotzdem weiterhilft.

Grüße,

RIDER

[Camping_RIDER]

Aloha ;)

Warum nicht so?

 <input id="eingabe" value="Hier kann man was eingeben">
<label for="eingabe">
<details>
  <summary>Eingabefeld:  </summary>
  Hier steht eine langatmige Erklärung dazu, was das Eingabefeld bewirkt. Sie muss normalerweise unsichtbar sein, weil sie schlicht und ergreifend zu lang wäre. Das Problem: Gibt man einen Text ins Eingabefeld ein, so klappt dieser Text bei jedem Leerzeichen auf und zu.
</details>
</label>

Ja, wäre eine Möglichkeit (fürs Primärproblem, um das es mir hier gar nicht so sehr ging). Hat aber auch seine Tücken: So verliert das label seinen Sinn - zumindest im Chrome wird jetzt beim anklicken des Labels nur noch aufgeklappt, nicht mehr das Textfeld markiert.

Grüße,

RIDER

[JürgenB]

Hallo Janosch,

du musst dir drei Fragen beantworten:

• Wo soll man hinklicken^[1], um das Inputfeld zu fokussieren?
• Wo soll man hinklicken, um die weiteren Infos zu öffnen?
• Kommen die Seitenbesucher damit zurecht?

Danach kannst du entscheiden, welches Markup geeignet ist, und ob da mit Javascript noch etwas nachgeholfen werden muss.

Die Codepenversion „funktioniert“ in meinem FF, aber es ist nicht intuitiv, wenn der Klick auf das Dreieck die Info öffnet, der Klick auf den Text dahinter aber den Input fokussiert.

Gruß
Jürgen

---

1. Hiermit ist auch Touch oder Anfahren mit der Tastatur gemeint. ↩︎

[Camping_RIDER]

Aloha ;)

du musst dir drei Fragen beantworten:

• Wo soll man hinklicken^[1], um das Inputfeld zu fokussieren?
• Wo soll man hinklicken, um die weiteren Infos zu öffnen?
• Kommen die Seitenbesucher damit zurecht?

Danach kannst du entscheiden, welches Markup geeignet ist, und ob da mit Javascript noch etwas nachgeholfen werden muss.

Ja, völlig richtig. Mein Gedanke war tatsächlich, dass nur der Klick auf das Dreieck die Info öffnet. In meiner ursprünglichen Anwendung war bzw. ist nicht einmal ein label dabei, das habe ich hier nur der Vollständigkeit hinzugefügt.

Ich sehe aber ein, dass es vielleicht eine unzulässige Annahme war, dass das für Seitenbesucher (sind allerdings in dem Fall konkret nur sehr wenige Personen - das Ding ist nichtöffentlich!) so funktioniert.

Die Codepenversion „funktioniert“ in meinem FF, aber es ist nicht intuitiv, wenn der Klick auf das Dreieck die Info öffnet, der Klick auf den Text dahinter aber den Input fokussiert

Danke für das Feedback!

(Aus prinzipiell-technischen Gründen würde mich trotzdem interessieren, ob es eine Lösung gibt, mit der ich das, was im Firefox geht, auch im Chrome hinbekommen kann.)

Grüße,

RIDER

---

1. Hiermit ist auch Touch oder Anfahren mit der Tastatur gemeint. ↩︎

[Rolf B]

Hallo Camping_RIDER,

das Ding ist nichtöffentlich!

dein Projekt mit Felix? Gerade da solltest Du auf intuitive Bedienbarkeit achten, das sind keine technikaffinen Menschen, für die Du da programmierst.

Rolf

[Camping_RIDER]

Aloha ;)

das Ding ist nichtöffentlich!

dein Projekt mit Felix?

Ja 😉 Zu viel mehr komme ich ja auch nicht mehr.

Gerade da solltest Du auf intuitive Bedienbarkeit achten, das sind keine technikaffinen Menschen, für die Du da programmierst.

Jein - Ja, weil das immer gilt, Nein, weils in diesem konkreten Fall nur die Stundenplanverwalter trifft. Die sind ausreichend technikaffin^[1], also kein Thema.

Grüße,

RIDER

---

1. Die bedienen Untis^[2]... ↩︎

2. das ist UX-technisch auf kotzwürg-Level. ↩︎

[Camping_RIDER]

Aloha ;)

Danke an alle für die Antworten!

Ich habe jetzt folgende Lösung gezogen:

Das Markup dazu:

<h4>
  <label for="lesson_2302_notice">Bemerkung zur Unterrichtsstunde</label>
</h4>
<details>
  <summary>?</summary>
  Dieser Hinweis wird im Stundenplan angezeigt. Hier sollten [...]
</details>
<input type="text" id="lesson_2302_notice" name="lesson_2302_notice" value="FD Schiene 1" class="lesson_notice">

Das label im h4 könnte natürlich auch nur einfach ein label sein; das ist in ein h4 eingeschlossen, weil es zum umliegenden Markup so besser passt.

Styling-technisch wird die h4 mit float: left; behandelt und summary bekommt text-align: right;.

So erreiche ich wie gewünscht eine schlanke, unauffällige Klickfläche zum Öffnen des Erklärtexts und eine große Klickfläche als label, außerdem ist die Lösung (im Vergleich zum Summary-Text in einer eigenen Zeile) im zusammengeklappten Zustand auch vertikal sehr schlank, was für mich wichtig war.

Grüße,

RIDER

[Rolf B]

Hallo Camping_RIDER,

okay, so kann man es machen.

Eventuell müsste man das Fragezeichen größer und deutlicher machen. Ggf. das Summary-Element wie einen Button stylen.

Rolf

[Gunnar Bittersmann]

@@Rolf B

Eventuell müsste man das Fragezeichen größer und deutlicher machen.

Deutlicher auch im Sinne von Alternativtext:

<summary>
  <span aria-hidden="true">?</span>
  <span class="visually-hidden">Erklärung</span>
</summary>

mit dem bekannten CSS für .visually-hidden

Auch wenn in der Zielgruppe momentan keine Screenreadernutzer sind.

🖖 Живіть довго і процвітайте