Camping_RIDER: Text-Input als Summary verwenden

problematische Seite

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

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

akzeptierte Antworten

  1. problematische Seite

    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

    1. problematische Seite

      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

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

    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

    --
    sumpsi - posui - obstruxi
    1. problematische Seite

      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

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

        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

        --
        sumpsi - posui - obstruxi
        1. problematische Seite

          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

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

            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

            --
            sumpsi - posui - obstruxi
          2. problematische Seite

            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

            --
            sumpsi - posui - obstruxi
            1. problematische Seite

              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

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

    @@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?

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

    --
    „Im Vergleich mit Elon Musk bei Twitter ist ein Elefant im Porzellanladen eine Ballerina.“
    — @Grantscheam auf Twitter
    1. problematische Seite

      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

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

        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

        --
        sumpsi - posui - obstruxi
        1. problematische Seite

          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

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

    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

    1. problematische Seite

      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

      --
      sumpsi - posui - obstruxi
    2. problematische Seite

      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

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

        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

        --
        Eigentlich hatte ich heute viel vor - jetzt habe ich morgen viel vor!
        1. problematische Seite

          @@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>
          

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

          --
          „Im Vergleich mit Elon Musk bei Twitter ist ein Elefant im Porzellanladen eine Ballerina.“
          — @Grantscheam auf Twitter
          1. problematische Seite

            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.

            1. problematische Seite

              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

              --
              sumpsi - posui - obstruxi
              1. problematische Seite

                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

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

                  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“.

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

                  1. problematische Seite

                    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

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

              @@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.

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

              --
              „Im Vergleich mit Elon Musk bei Twitter ist ein Elefant im Porzellanladen eine Ballerina.“
              — @Grantscheam auf Twitter
          2. problematische Seite

            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 a.k.a. Riders Flame a.k.a. Janosch Albers-Zoller
            # Twitter # Steam # YouTube # Self-Wiki # Selfcode: sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[
        2. problematische Seite

          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

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

    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. ↩︎

    1. problematische Seite

      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

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

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

      1. problematische Seite

        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

        --
        sumpsi - posui - obstruxi
        1. problematische Seite

          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

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

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

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

  6. problematische Seite

    Aloha ;)

    Danke an alle für die Antworten!

    Ich habe jetzt folgende Lösung gezogen:

    linksbündig Überschrift, daneben rechtsbündig ein Fragezeichen mit Dreieck zum Aufklappen der Beschreibung. Darunter das Eingabefeld.

    Selbe Situation, nun aber mit aufgeklapptem Hilfe-Text, der zwischen Überschrift und Eingabefeld erscheint

    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

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

      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

      --
      sumpsi - posui - obstruxi
      1. problematische Seite

        @@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.

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

        --
        „Im Vergleich mit Elon Musk bei Twitter ist ein Elefant im Porzellanladen eine Ballerina.“
        — @Grantscheam auf Twitter