Rolf B: [Deprecation]The 'textprediction' attribute will be removed in the future. Use the 'writingsuggestions' attribute instead.

2 45

[Deprecation]The 'textprediction' attribute will be removed in the future. Use the 'writingsuggestions' attribute instead.

Rolf B
  • datenschutz
  • html
  • ki
  1. 1
    Robert B.
    1. 0
      Rolf B
      1. 0
        Robert B.
    2. 0
      Gunnar Bittersmann
      • browser
      • datenschutz
      • html
      1. 0
        Rolf B
        1. 0
          Robert B.
        2. 0
          Gunnar Bittersmann
          1. 0
            Gunnar Bittersmann
            • browser
            • windows
            1. 0
              Robert B.
      2. 0
        Robert B.
        1. 0
          Gunnar Bittersmann
          • css
          • datenschutz
          • html
          1. 0
            Rolf B
            1. 0
              Gunnar Bittersmann
              1. 0
                Rolf B
                1. 0
                  Gunnar Bittersmann
                  1. 0
                    Camping_RIDER
                    1. 0
                      Gunnar Bittersmann
                      1. 0
                        Camping_RIDER
                        1. 0
                          Gunnar Bittersmann
                          1. 0
                            Rolf B
                            1. 1
                              Gunnar Bittersmann
                        2. 0
                          Robert B.
                          • formulare
                          • html
                          1. 0
                            Camping_RIDER
                  2. 0
                    Robert B.
                    • datenschutz
                    • html
          2. 0
            Robert B.
      3. 0
        Gunnar Bittersmann
        1. 1
          nicht leer
          1. 0
            Gunnar Bittersmann
            • browser
            • design
            • ux
            1. 0
              Robert B.
  2. 0
    Matthias Scharwies
    • datenschutz
    • ki
    1. 0

      Eingabehilfen mit 'writingsuggestions'

      Matthias Scharwies
      • datenschutz
      • formulare
      • ki
      1. 0
        Robert B.
        • sprache
        1. 0
          Matthias Scharwies
      2. 0
        Robert B.
        1. 0
          Matthias Scharwies
      3. 0
        Robert B.
        1. 0
          Matthias Scharwies
    2. 0

      type = "password" - autocomplete="off" wird durch Passwortmanager ausgehebelt

      Matthias Scharwies
      • datenschutz
      • ki
      • sicherheit
      1. 0
        Camping_RIDER
        1. 0
          Matthias Scharwies
      2. 0
        Rolf B
        1. 0
          Matthias Scharwies
          1. 0
            Jonathan Harker
    3. 0

      writingsuggestions="false"

      Matthias Scharwies

Hallo alle,

diese Meldung bringt mir Edge gerade in den Developer Tools, in der Quelltextansicht, für irgendeinen blöden if. Offenbar wird diese Quelltextansicht per HTML erzeugt und offenbar möchte Edge nicht, dass der Copilot da mitquatscht.

Aber...

textprediction? writingsuggestions? Schon mal gehört?

Das ist offenbar ein neues HTML Attribut in Chromia 124+, mit denen sich ein eventuell vorhandener KI-Copilot auf dem Gerät des Benutzers deaktivieren lässt. Als 'writingsuggestions' hat es sogar seinen Weg in die Spec geschafft.

<label>Ungeholfene Eingabe:
<input type="text" writingsuggestions="false"></label>

Das Böse daran ist, dass der Defaultwert dieses Attributs true ist. Ich habe keine Ahnung von diesen KI Copiloten und weiß darum nicht, ob die rein lokal agieren oder ihre Dünntelligenz von einem Server bekommen. Woraus folgt: Privatsphärenalarm!

Weiß jemand mehr darüber?

Rolf

--
sumpsi - posui - obstruxi
  1. Moin Rolf,

    diese Meldung bringt mir Edge gerade in den Developer Tools, in der Quelltextansicht, für irgendeinen blöden if. Offenbar wird diese Quelltextansicht per HTML erzeugt und offenbar möchte Edge nicht, dass der Copilot da mitquatscht.

    bedeutet es, dass die dort keinen Quellcode für irgendeinen „Copiloten“ sammeln? Aber da die Fehlermeldung ja vom Browser kommt, sieht man wieder einmal eindrucksvoll, wie gut™ Softwaretests funktionieren 😝

    textprediction? writingsuggestions? Schon mal gehört?

    Liest sich erst einmal wie fast ein Duplikat von autocomplete.

    Das ist offenbar ein neues HTML Attribut in Chromia 124+, mit denen sich ein eventuell vorhandener KI-Copilot auf dem Gerät des Benutzers deaktivieren lässt. Als 'writingsuggestions' hat es sogar seinen Weg in die Spec geschafft.

    Das Böse daran ist, dass der Defaultwert dieses Attributs true ist. Ich habe keine Ahnung von diesen KI Copiloten und weiß darum nicht, ob die rein lokal agieren oder ihre Dünntelligenz von einem Server bekommen. Woraus folgt: Privatsphärenalarm!

    Für Passwort-Felder, deren type man zum Anzeigen des Passworts umschalten kann, ist der „Schreibvorschlag“ damit ein weiteres Attribut, das man zwingend als Nicht-Default angeben muss 😕

    <input type="password" name="bleibtLokal"
        spellcheck="false" autocomplete="off" writingsuggestions="false">
    

    Wer denkt sich so etwas aus?!

    Vielen Dank fürs Finden und viele Grüße
    Robert

    1. Hallo Robert B.,

      password

      Die Spec sagt, true - unter anderem - wenn:

      element is an input element whose type attribute is in either the Text, Search, Telephone, URL, or Email state and is mutable;

      Rolf

      --
      sumpsi - posui - obstruxi
      1. Moin Rolf,

        password

        Die Spec sagt, true - unter anderem - wenn:

        element is an input element whose type attribute is in either the Text, Search, Telephone, URL, or Email state and is mutable;

        wenn ich das Passwort anzeigen lassen möchte, wird aus type="password"type="text" und damit würden die ganzen Späße auf einmal aktiv, sofern man sie nicht schon für das Passwort-Feld abschaltet.

        Viele Grüße
        Robert

    2. @@Robert B.

      Das ist offenbar ein neues HTML Attribut in Chromia 124+, […] Das Böse daran ist, dass der Defaultwert dieses Attributs true ist.

      Ach du Scheiße! Google ist mal wieder das Web und seine Nutzer scheißegal.

      Für Passwort-Felder, deren type man zum Anzeigen des Passworts umschalten kann, ist der „Schreibvorschlag“ damit ein weiteres Attribut, das man zwingend als Nicht-Default angeben muss 😕

      Ach du Scheiße! Und solange sich das nicht herumgesprochen hat?

      Es wird Zeit, dass die Passwort-anzeigen-Funktion endlich dort implementiert wird, wo sie hingehört: in den Browsern! Das Password muss im Klartext angezeigt werden können, ohne dass der Typ des Eingabefeldes von password auf text geändert wird.

      Edge hatte das mal als einziger Browser so implementiert – bevor sie auf Chromium umschwenkten. Es ist ein Jammer, dass sie diese Funktion nicht hinübergerettet haben und damit auch anderen Chromium-Browsern zur Verfügung gestellt haben.

      Kwakoni Yiquan

      --
      Ad astra per aspera
      1. Hallo Gunnar,

        Edge (126) kann das: .
        Das Auge im Inputfeld zeigt das PW an (aber nur, solange man das Feld nicht verlässt) und der Anzeigen-Button daneben ist von der Webseite und schaltet auf type="text" um.

        Chrome tut's nicht. Es gibt wohl einen Unterschied zwischen der Rendering-Engine und der Darstellung des gerenderten Ergebnisses. Very Strange. Oder es liegt dran, dass ich auf diesem gemanagten Gerät hier seit ein paar Monaten keine Chrome-Updates mehr hinkriege 😟

        Diese freundliche KI-Unterstützung durch einen „Copiloten“ scheint aber eher Microsoft anzulasten zu sein, von denen ist die alte Attributversion wohl gekommen, die jetzt unter anderem Namen standardisiert wurde. Zumindest hatte ich beim Suchen nach den Attributnamen diesen Eindruck.

        Rolf

        --
        sumpsi - posui - obstruxi
        1. Moin Rolf,

          Edge (126) kann das: .
          Das Auge im Inputfeld zeigt das PW an (aber nur, solange man das Feld nicht verlässt) und der Anzeigen-Button daneben ist von der Webseite und schaltet auf type="text" um.

          Chrome tut's nicht. Es gibt wohl einen Unterschied zwischen der Rendering-Engine und der Darstellung des gerenderten Ergebnisses. Very Strange. Oder es liegt dran, dass ich auf diesem gemanagten Gerät hier seit ein paar Monaten keine Chrome-Updates mehr hinkriege 😟

          das Symbol im Passwort-Feld scheint von einer UI-Bibliothek von Microsoft zu kommen, denn das gibt es auch an anderen Stellen in Windows bei Passwort-Eingaben. Leider nutzen das die anderen Browser nicht.

          Viele Grüße
          Robert

        2. @@Rolf B

          Edge (126) kann das: .

          Nö, im Edge 128 auf macOS ist nichts dergleichen.

          Microsoft denkt wohl, alle Edge-Nutzer sind auf Windows, und Edge für macOS ist nur ein Abfallprodukt? Vermutlich haben sie damit recht.

          Kwakoni Yiquan

          --
          Ad astra per aspera
          1. @@Gunnar Bittersmann

            Edge (126) kann das: .

            Nö, im Edge 128 auf macOS ist nichts dergleichen.

            Microsoft denkt wohl, alle Edge-Nutzer sind auf Windows, und Edge für macOS ist nur ein Abfallprodukt? Vermutlich haben sie damit recht.

            Vielleicht nutzt der Edge unter Windows auch eine Betriebssystem-Funktion, die Windows dafür zur Verfügung stellt, andere OS aber nicht? 🤔

            Kwakoni Yiquan

            --
            Ad astra per aspera
            1. Moin Gunnar,

              Vielleicht nutzt der Edge unter Windows auch eine Betriebssystem-Funktion, die Windows dafür zur Verfügung stellt, andere OS aber nicht? 🤔

              anscheinend ist das so.

              Viele Grüße
              Robert

      2. Moin Gunnar,

        Ach du Scheiße! Google ist mal wieder das Web und seine Nutzer scheißegal.

        hat Google jemals gesagt, für wen »don’t be evil« gelten soll?

        Für Passwort-Felder, deren type man zum Anzeigen des Passworts umschalten kann, ist der „Schreibvorschlag“ damit ein weiteres Attribut, das man zwingend als Nicht-Default angeben muss 😕

        Ach du Scheiße! Und solange sich das nicht herumgesprochen hat?

        Bewusstsein schaffen, solange sich das nicht herumgesprochen hat oder es effektive Lösungen gibt wie:

        Es wird Zeit, dass die Passwort-anzeigen-Funktion endlich dort implementiert wird, wo sie hingehört: in den Browsern! Das Password muss im Klartext angezeigt werden können, ohne dass der Typ des Eingabefeldes von password auf text geändert wird.

        Alternativ kann man ein output anzeigen und das Passwortfeld verstecken, wie ich gerade ausprobiert habe.

        Viele Grüße
        Robert

        1. @@Robert B.

          Es wird Zeit, dass die Passwort-anzeigen-Funktion endlich dort implementiert wird, wo sie hingehört: in den Browsern! Das Password muss im Klartext angezeigt werden können, ohne dass der Typ des Eingabefeldes von password auf text geändert wird.

          Alternativ kann man ein output anzeigen und das Passwortfeld verstecken, wie ich gerade ausprobiert habe.

          Die Idee mit zwei getrennten Feldern gefällt mir. Allerdings sollte man das Passwort nicht nur im Klartext angezeigt bekommen, sondern es auch im Klartext eingeben können.

          Ich habe deshalb statt output ein zweites input verwendet; die Eingaben werden zwischen beiden Eingabefeldern synchronisiert.

          reveal password, 2 inputs

          Kwakoni Yiquan

          --
          Ad astra per aspera
          1. Hallo Gunnar,

            äh, warum die Mühe? Wenn Du es jetzt neu machst, dann kannst Du writingsuggestions auf false setzen und bei Bedarf den type zwischen text und password umschalten.

            Frage ist, ob man die browserseitige Existenz des Password-Buttons durch eine Feature Query erkennen kann…

            Rolf

            --
            sumpsi - posui - obstruxi
            1. @@Rolf B

              äh, warum die Mühe? Wenn Du es jetzt neu machst, dann kannst Du writingsuggestions auf false setzen und bei Bedarf den type zwischen text und password umschalten.

              Und wenn Google oder Microsoft die nächste Sau durchs Dorf treibt, muss man wieder ein neues Attribut an seine Passworteingabfelder hängen‽

              Ah, wait! Die Attribute müsste man ja auch an das Reveal-Passwort-Eingabefeld hängen?

              Aber zumindest ist das nicht the real thing (dessen Wert irgendwie weitergegeben wird). The real thing behält type="password".

              Macht es das irgendwie besser?

              Frage ist, ob man die browserseitige Existenz des Password-Buttons durch eine Feature Query erkennen kann…

              Du meinst, sobald ein Browser das Passwort-Anzeigen implementiert hat, sollte die eigene Implementierung nicht mehr angewandt werden? Ja, schön wär’s.

              Kwakoni Yiquan

              --
              Ad astra per aspera
              1. Hallo Gunnar,

                Ah, wait! Die Attribute müsste man ja auch an das Reveal-Passwort-Eingabefeld hängen

                Plick...

                Siehe unten, ein Groschen 😉

                Die einzige Chance, sich sicher vom kreativen Wahn der Browserbauer(n) zu distanzieren, ist ein div, das ein input Element imitiert. Würde ich aber nicht wirklich als best practice klassifizieren…

                Rolf

                --
                sumpsi - posui - obstruxi
                1. @@Rolf B

                  Die einzige Chance, sich sicher vom kreativen Wahn der Browserbauer(n) zu distanzieren, ist ein div

                  Wieso ein div? output, wie von @Robert B. vorgeschlagen, trifft’s besser.

                  das ein input Element imitiert.

                  contenteditable="true".

                  In der Tat war <output contenteditable="true"> mein erster Gedanke gewesen. Ich hätte mal dabei bleiben sollen.

                  Muss man halt nur das output-Element wie das input-Element stylen.
                  (Warum tut es output { appearance: textfield } nicht?)

                  reveal password, input & output

                  Kwakoni Yiquan

                  --
                  Ad astra per aspera
                  1. Aloha ;)

                    reveal password, input & output

                    Ein kleiner Bug ist noch drin: wenn man den Button klickt bevor man im password-Feld was eingegeben hat (also bei Leerstring) kann man ins output nichts eingeben. Zumindest gelingts mir nicht (Chrome 128 @ Linux).

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

                      reveal password, input & output

                      Ein kleiner Bug ist noch drin: wenn man den Button klickt bevor man im password-Feld was eingegeben hat (also bei Leerstring) kann man ins output nichts eingeben. Zumindest gelingts mir nicht (Chrome 128 @ Linux).

                      Danke für die Meldung. Kann ich auf macOS nachvollziehen. Im Safari auch.

                      Was ist denn das wieder für ein blöder Webkit-/Chromium-Bug? In Firefox läuft’s wie’s soll.

                      Kwakoni Yiquan

                      --
                      Ad astra per aspera
                      1. Aloha ;)

                        Was ist denn das wieder für ein blöder Webkit-/Chromium-Bug? In Firefox läuft’s wie’s soll.

                        Ich hab keinen blassen Schimmer! Ich hab eben auch ein bissl rumgespielt und mal verschiedene Code-Teile auskommentiert (JS) oder weggelassen / durch Alternativen ersetzt (HTML, z.B. ARIA-Attribute), aber ich schaffe es nicht, das output mit Text zu befüllen wenn es zuvor leer ist - in einem Blanko-Pen mit einem einfachen output geht das allerdings. Da muss sich irgendeine Konstellation ganz doof beißen.

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

                          Was ist denn das wieder für ein blöder Webkit-/Chromium-Bug? In Firefox läuft’s wie’s soll.

                          Da muss sich irgendeine Konstellation ganz doof beißen.

                          WTF!! @Rolf B hatte vollkommen recht: Nimm div, nicht output – dann geht’s! 😵‍💫

                          reveal password, input & div

                          Und da dann natürlich textContent statt value. Nett, dass du fragst: mit output und textValue geht’s auch nicht.

                          Welche Konstellation sich da nun beißt, hab ich auch noch nicht rausgefunden. Wie du auch schon festgestellt hast , funktioniert ein etwas abgespecktes Beispiel (auch mit hidden, das per JS entfernt wird) ja.

                          Kwakoni Yiquan

                          --
                          Ad astra per aspera
                          1. Hallo Gunnar Bittersmann,

                            hat Dir eigentlich schon jemand verraten, dass contenteditable="true" die AI-Bestie ebenfalls weckt? Zumindest steht das so in der Spec.

                            § 6.8.6 Writing suggestions
                            User agents offer writing suggestions as users type into editable regions, either in form controls (e.g., the textarea element) or in elements in an editing host.

                            contenteditable="true" erzeugt einen editing host.

                            Es gab eine guten Grund, weshalb ich davon sprach, dass man die Eingabe komplett emulieren müsste. Wenn der Browser spürt, dass das ein Eingabeelement ist, packt er den Copiloten aus. Es sei denn, du meldest Dich von den writingsuggestions ab.

                            Rolf

                            --
                            sumpsi - posui - obstruxi
                            1. @@Rolf B

                              hat Dir eigentlich schon jemand verraten, dass contenteditable="true" die AI-Bestie ebenfalls weckt?

                              Och Menno, Spielverderber!

                              Das heißt, wir bleiben dabei, input type zu ändern und dreiundzwölfzig Attribute anzuhängen. Wobei man immer auf der Hut sein muss, was man alles so anhängen muss. Und wenn man was Neues erfährt, ist es eigentlich schon zu spät, weil man’s bereits angehangen haben musste.

                              Die gute Nachricht ist: Man muss sich um diesen Webkit-/Chromium-Bug nicht weiter kümmern.

                              Kwakoni Yiquan

                              --
                              Ad astra per aspera
                        2. Moin,

                          Was ist denn das wieder für ein blöder Webkit-/Chromium-Bug? In Firefox läuft’s wie’s soll.

                          Ich hab keinen blassen Schimmer! Ich hab eben auch ein bissl rumgespielt und mal verschiedene Code-Teile auskommentiert (JS) oder weggelassen / durch Alternativen ersetzt (HTML, z.B. ARIA-Attribute), aber ich schaffe es nicht, das output mit Text zu befüllen wenn es zuvor leer ist - in einem Blanko-Pen mit einem einfachen output geht das allerdings. Da muss sich irgendeine Konstellation ganz doof beißen.

                          meiner Erfahrung nach kann es helfen, das output initial mit einem geschützten Leerzeichen zu füllen.

                          Viele Grüße
                          Robert

                          1. Aloha ;)

                            Das ist in diesem Fall imho nicht zielführend - auch ein geschütztes Leerzeichen ist ein Zeichen, das vom Feld mit type password übernommen würde, was hier unerwünscht ist.

                            Man müsste da böse Winkelzüge fahren - z.B. beim Synchronisieren immer nur einen Substring übertragen und in die andere Richtung das Platzhalterzeichen forcieren. Denkbar, aber maximal unhübsch, und potenziell dann problematisch, wenn eins der beiden Felder mit Strg+A markiert und dann für Copy oder Paste verwendet wird, weil das leere Output nur leer aussieht, aber nicht leer 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:[
                  2. Moin,

                    Die einzige Chance, sich sicher vom kreativen Wahn der Browserbauer(n) zu distanzieren, ist ein div

                    Wieso ein div? output, wie von @Robert B. vorgeschlagen, trifft’s besser.

                    das ein input Element imitiert.

                    contenteditable="true".

                    In der Tat war <output contenteditable="true"> mein erster Gedanke gewesen. Ich hätte mal dabei bleiben sollen.

                    besser doch nicht: Ich habe meine Testseite im Chrome geladen, einen Proxy dazwischen geschaltet und geschaut, welche Round-Trips „nebenbei“ noch geschehen: Für contenteditable bietet Chrome nicht nur die erweiterte Rechtschreibprüfung/enhanced spell-check an, sondern verwendet diese auch und sendet die Eingabe an einen Service von Google.

                    Mit anderen Worten: Vom Aspekt der (Un-) Sicherheit sind

                    • input type="text"
                    • output contenteditable

                    identisch.

                    Viele Grüße
                    Robert

          2. Moin Gunnar,

            Alternativ kann man ein output anzeigen und das Passwortfeld verstecken, wie ich gerade ausprobiert habe.

            Die Idee mit zwei getrennten Feldern gefällt mir. Allerdings sollte man das Passwort nicht nur im Klartext angezeigt bekommen, sondern es auch im Klartext eingeben können.

            an dem Punkt war ich auch schon, aber mit der Bearbeitungsmöglichkeit holen wir uns auch wieder die Probleme mit den ganzen Möglichkeiten der Passwort-Abflüsse wieder herein 😕

            Ein output synchronisiert von einem input type="password" nebendran wäre auch nicht sonderlich elegant, aber immerhin eine „etwas bessere“ Möglichkeit:

            Passwort: [**] [Klartext im output]
            

            Ansonsten bleibt wohl wirklich nichts Anderes übrig als Browserhersteller oder die WhatWG zu nerven …

            Viele Grüße
            Robert

      3. @@Gunnar Bittersmann

        Bei meiner Recherche stieß ich auf Chris Coyiers Artikel The Options for Password Revealing Inputs (Oktober 2021).

        Option 1: Use type="password", then swap it out for type="text" with JavaScript war der Stein des Anstoßes hier im Thread; das wollen wir ja gerade vermeiden.

        Option 2: Use -webkit-text-security in CSS sieht trotz Vendor-Präfix vielversprechend aus; das wird von allen gängigen Browsern unterstützt – für Texteingabefelder.

        Und jetzt ratet mal, für welche Elemente das kein Browser unterstützt!
        Genau! Für Passworteingabefelder! 🤔😫🤮

        reveal password, -webkit-text-securitytype="text" gesetzt: die Umschaltung funktioniert. Für type="password": nö, nirgends. Es ist mir auch nicht gelungen, den Browserdefault zu überschreiben – weder mit !important noch mit @layer noch durch Setzen der CSS-Eigenschaft direkt mit JavaScript.

        Beim einzigen Element, wo man dieses CSS-Feature sinnvoll anwenden könnte, kann man es nicht anwenden. W T F!

        Zur Erinnerung: type="text" zu setzen ist ja gerade das, was wir nicht wollen.

        Option 3: input-security in CSS ist (fast) dasselbe als Versuch eines Standards; Browserunterstützung: keine. Wird wohl auch nicht kommen, denn wie im aktuellen Editor’s Draft zu lesen steht: “The CSS-WG has agreed that while be believe that providing this piece of functionality to users is important, doing it via CSS+JS is the wrong approach, and that instead it should be built into user agents.”

        Ähm, sag ich doch:

        Es wird Zeit, dass die Passwort-anzeigen-Funktion endlich dort implementiert wird, wo sie hingehört: in den Browsern! Das Password muss im Klartext angezeigt werden können, ohne dass der Typ des Eingabefeldes von password auf text geändert wird.

        Dort verlinkt: ein Github-Issue zum Entfernen von input-security aus dem Standard. Darin eine Diskussion vom Januar 2022. Was hat sich seitdem getan? input-security steht immer noch im Workung Draft und Passwort anzeigen wurde immer noch nicht in Browsern implementiert (außer Edge unter Windows?).

        Wenn’s um developer experience geht, sind die Browserentwickler schnell. Aber hier geht’s ja nur um user experience …

        Kwakoni Yiquan

        --
        Ad astra per aspera
        1. (außer Edge unter Windows?)

          Firefox: Rechtsklick auf type="password"; aus dem Kontextmenu „Passwort anzeigen“ wählen. Wurde mit Version 112.0 eingeführt.

          1. @@nicht leer

            Firefox: Rechtsklick auf type="password"; aus dem Kontextmenu „Passwort anzeigen“ wählen. Wurde mit Version 112.0 eingeführt.

            Ah! Warum sagt einem das keiner? (Wer liest schon release notes?)

            Warum verstecken die das im Kontextmenü, wo man – wenn überhaupt – mal zufällig drauf stößt, anstatt einen clickbaren Button ins Passworteingabefeld zu platzieren?

            Kwakoni Yiquan

            --
            Ad astra per aspera
            1. Moin,

              Firefox: Rechtsklick auf type="password"; aus dem Kontextmenu „Passwort anzeigen“ wählen. Wurde mit Version 112.0 eingeführt.

              Ah! Warum sagt einem das keiner? (Wer liest schon release notes?)

              User sind nicht unbeding Developer (und vice versa).

              Warum verstecken die das im Kontextmenü, wo man – wenn überhaupt – mal zufällig drauf stößt, anstatt einen clickbaren Button ins Passworteingabefeld zu platzieren?

              weil der mobile Firefox (auf Android) eh auch kein Kontextmenü hat. Dort gibt es eine vergleichbare Funktion nur, wenn der Firefox ein Passwort automatisch generieren und im Browser speichern darf – dafür wird das aber jedes Mal angezeigt, wenn man ins Passwort-Feld tippt. Was für ein Erlebnis!

              Viele Grüße
              Robert

  2. Servus!

    Hallo alle,

    ... Als 'writingsuggestions' hat es sogar seinen Weg in die Spec geschafft.

    <label>Ungeholfene Eingabe:
    <input type="text" writingsuggestions="false"></label>
    

    Ich habe es mal angelegt: HTML/Attribute/writingsuggestions

    Weiß jemand mehr darüber?

    Nein, und dieser Thread ist schon das 4. Suchergebnis.[1]

    Ich vermute aber, dass die KI im Browser bleibt und der Unterschied zu autocomplete ist, dass sich dieses auf feste Angaben bezieht, während writingsuggestions eher rät. Kein Wunder, dass die Browser mittlerweile mehr CPU-Power brauchen als Videobearbeitung.

    Ich beobachte das mal und aktualisiere - wenn ich was gefunden habe - das entsprechende Tutorial.

    Herzliche Grüße

    Matthias Scharwies

    --
    Das wirksamste Mittel gegen Sonnenbrand
    ist Urlaub am Ostseestrand!

    1. Grad gefunden: https://en.wikipedia.org/wiki/Autocomplete
      sehr ausführlich ↩︎

    1. Guten Morgen,

      Ich beobachte das mal und aktualisiere - wenn ich was gefunden habe - das entsprechende Tutorial.

      Schaut mal bitte hier: Formulare/Eingabe von Text

      Der erste Abschnitt stellt die verschiedenen Typen vor.

      Neu ist der Abschnitt Eingabehilfen

      Dazu einige Fragen/Bitten:

      • Wer könnte auf einem Android-Gerät einen Screenshot des autocomplete-Beispiels mit autocomplete="new-password" machen?

      • Wie sieht das writingsuggestions Beispiel bei Euch aus? (Nur Chromium-Browser)
        Bei mir wird im Satz: "Es war einmal ein Mächen, das durch den Wald ging" nur das Wort Mächen rot unterringelt und mit 3 Textvorschlägen ergänzt; das falsche das wird nicht bemängelt.

      • Wie soll der weitere Aufbau laufen? password jetzt schon erklären oder - wie von mir ursprünglich geplant, in einem eigenen Abschnitt?

      Herzliche Grüße

      Matthias Scharwies

      --
      Das wirksamste Mittel gegen Sonnenbrand
      ist Urlaub am Ostseestrand!
      1. Moin Matthias,

        Dazu einige Fragen/Bitten:

        • Wie sieht das writingsuggestions Beispiel bei Euch aus? (Nur Chromium-Browser)
          Bei mir wird im Satz: "Es war einmal ein Mächen, das durch den Wald ging" nur das Wort Mächen rot unterringelt und mit 3 Textvorschlägen ergänzt; das falsche das wird nicht bemängelt.

        welche „falsche ‚das‘“? Das ist hier doch ein Relativsatz. (Oder vermutest Du, dass die „KI“ mit gängigen Texten aus dem „Internetz“ trainiert worden ist? 😉).

        Viele Grüße
        Robert

        1. Servus!

          Moin Matthias,

          Dazu einige Fragen/Bitten:

          welche „falsche ‚das‘“? Das ist hier doch ein Relativsatz. (Oder vermutest Du, dass die „KI“ mit gängigen Texten aus dem „Internetz“ trainiert worden ist? 😉).

          Oh Gott - ich wollte das noch kurz vor Arbeitsbeginn fertigstellen und da kommt so wass raus! 😀

          Könntest Du mal testen und gucken, ob bei Dir was auffällt, was man im Tutorial hinzufügen könnte.

          Herzliche Grüße

          Matthias Scharwies

          --
          Das wirksamste Mittel gegen Sonnenbrand
          ist Urlaub am Ostseestrand!
      2. Moin Matthias,

        Neu ist der Abschnitt Eingabehilfen

        Dazu einige Fragen/Bitten:

        • Wer könnte auf einem Android-Gerät einen Screenshot des autocomplete-Beispiels mit autocomplete="new-password" machen?

        Chrome auf Android zeigt nichts Besonderes an, allerdings bietet Firefox ein automatisch generiertes Passwort an:
        Firefox auf Android schlägt ein Passwort vor

        Ab welcher Version soll da denn etwas implementiert sein?

        Viele Grüße Robert

        1. Servus!

          Chrome auf Android zeigt nichts Besonderes an, allerdings bietet Firefox ein automatisch generiertes Passwort an:
          Firefox auf Android schlägt ein Passwort vor

          Danke!

          Ab welcher Version soll da denn etwas implementiert sein?

          https://caniuse.com/mdn-api_htmlelement_writingsuggestions

          Chrome 124, Edge 124 und Opera 110.

          Herzliche Grüße

          Matthias Scharwies

          --
          Das wirksamste Mittel gegen Sonnenbrand
          ist Urlaub am Ostseestrand!
      3. Moin Matthias,

        • Wie sieht das writingsuggestions Beispiel bei Euch aus? (Nur Chromium-Browser)
          Bei mir wird im Satz: "Es war einmal ein Mächen, das durch den Wald ging" nur das Wort Mächen rot unterringelt und mit 3 Textvorschlägen ergänzt; das falsche das wird nicht bemängelt.

        wie sollen denn die Vorschläge genau funktionieren? Gibt es da eine

        • bestimmte Browser-Einstellung
        • Tastenkombination
        • Kontextmenü
        • Hardware

        die ich verwenden muss?

        Viele Grüße
        Robert

        1. Hallo zusammen,

          wie sollen denn die Vorschläge genau funktionieren? Gibt es da eine

          • bestimmte Browser-Einstellung
          • Tastenkombination
          • Kontextmenü
          • Hardware

          die ich verwenden muss?

          Nein, einfach mal nur was euch auffällt:

          Chrome 128 unter Win11

          Bei den unterringelten Wörtern werden im Kontextmenü Alternativen angeboten. "welcher" und "Walt" werden nicht angestrichen.

          Interessant, dass Word ganz viele Wörter unterringelt, die es einfach nicht im Wörterbuch hatte - der Begriff Hormonröschen (vom Frystyxradio von FFN) von Chrome als ok erkannt oder zumindest nicht bemängelt wird.

          Herzliche Grüße

          Matthias Scharwies

          --
          Das wirksamste Mittel gegen Sonnenbrand
          ist Urlaub am Ostseestrand!
    2. Servus!

      Ich habe ein neues Problem:

      Hier gibt es ein Beispiel mit autocomplete="new-password":

      Formulare/Eingabe von text Sonderfall type = "password"

      Selbst autocomplete=off wird bei aktivertem Passwortmanager (Firefox), Google Passwortmananger (Chrome) bzw Microsoft Wallet (Edge) ignoriert und alle bisher je eingegebenen Passwörter zum Einfügen angeboten.

      Habt ihr Tipps - außer einer Riesenwarnung, solche Services nur sparsam zu nutzen?

      Das ist natürlich für das Tutorial, zu Hause steh ich aber vor einem ähnlichen Problem: Neben der Bank Card kriegt das Kind jetzt Online-Banking - Sollen die Passwörter gespeichert werden (geht ja so einfach), bis dann mal der Kumpel 5min alleine drüber hockt. Ja, ich weiß, Überweisungen müssen erst in der App bestätigt werden. Trotzdem.

      Herzliche Grüße

      Matthias Scharwies

      --
      Das wirksamste Mittel gegen Sonnenbrand
      ist Urlaub am Ostseestrand!
      1. Aloha ;)

        Selbst autocomplete=off wird bei aktivertem Passwortmanager (Firefox), Google Passwortmananger (Chrome) bzw Microsoft Wallet (Edge) ignoriert und alle bisher je eingegebenen Passwörter zum Einfügen angeboten.

        Ja - das entspricht auch meimer Erfahrung. Dieses Attribut wird bei Passwortfeldern schlicht ignoriert.

        Besonders schlimm ist das bei "uneigentlichen" Passwortfeldern - also Passwörtern, die nicht wie ein normales Passwort zum Anmelden verwendet werden.

        Zwei Beispiele aus dem Kontext von DAFUK[1]:

        • Eingabe der Antwort auf eine zufällig gestellte Sicherheitsfrage als 2FA: da sich die richtige Antwort jedesmal ändert will man nicht random eine Antwort eingespeichert haben - zumal das fehlende Benutzernamen-Feld in Kombination mit dem existenten Benutzernamenfeld in der vorgelagerten Anmeldemaske sogar dafür sorgt, dass der Passwortmanager dann das korrekterweise gespeicherte Passwort überschreibt

        • Eine Einstellungsseite mit IMAP- und SMTP-Zugangsdaten. Auch das sind Anmeldedaten, aber nicht meine, und ich will auch bei leeren Feldern um Gottes willen nicht, dass der Browser hier was voreinfüllt - was er aber tut (in anderen Systemen, z.B. WebUntis und DokuWiki ist das ein riesiges UX-Ärgernis!).

        Habt ihr Tipps - außer einer Riesenwarnung, solche Services nur sparsam zu nutzen?

        Ich kann zumindest den von mir gewählten alternativen Lösungsweg teilen.

        Ich benutze in diesen Fällen, also bei Passwortfeldern für die auf keinen Fall der Passwortmanager einspringen soll, den Input-Type text statt password und erzeuge dann die nötige Abschirmung gegenüber wachsamen über die Schulter blickenden Augen dadurch, dass ich für das Textfeld einen Font verwende, in dem jede Glyphe ein Punkt ist - wie in einem Passwortfeld. Der Passwort-Peeker-Button schaltet dann den fürs Eingabefeld verwendeten Font um. Falls jemand den Font sucht: er heißt text-security-disk.

        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. DAFUK - Digitale Anlaufstelle für unterrichtsbezogene Koordination ↩︎

        1. Servus!

          Habt ihr Tipps - außer einer Riesenwarnung, solche Services nur sparsam zu nutzen?

          Ich kann zumindest den von mir gewählten alternativen Lösungsweg teilen.

          Ich benutze in diesen Fällen, also bei Passwortfeldern für die auf keinen Fall der Passwortmanager einspringen soll, den Input-Type text statt password und erzeuge dann die nötige Abschirmung gegenüber wachsamen über die Schulter blickenden Augen dadurch, dass ich für das Textfeld einen Font verwende, in dem jede Glyphe ein Punkt ist - wie in einem Passwortfeld. Der Passwort-Peeker-Button schaltet dann den fürs Eingabefeld verwendeten Font um. Falls jemand den Font sucht: er heißt text-security-disk.

          Das klingt sehr gut! Vielen Dank! Ich schaue, dass das den Weg ins Wiki findet.

          Herzliche Grüße

          Matthias Scharwies

          --
          Das wirksamste Mittel gegen Sonnenbrand
          ist Urlaub am Ostseestrand!
      2. Hallo Matthias,

        ein Passwortmanager sollte eigentlich beim ersten Eingeben des Passworts fragen, ob er sich das merken soll. Und als Antwort anbieten: Ja, Jetzt nicht, Nie. Einmal "Nie" gewählt sollte weitere Angebote dieser Art verstummen lassen.

        Ansonsten ist das eine Form der Medienkompetenz, die hier erworben werden muss. Die ersten Onlinebanking-Besuche solltest Du ihn nicht allein machen lassen. Bei der Gelegenheit lässt sich der Passwortmanager in die Schranken weisen.

        Im Übrigen sind autocomplete und Passwortmanager zwei sehr unterschiedliche Biester. Die Werte für autocomplete sind über alle Webseiten gleich und sollen die Eingabe von Adressen etc einsparen, während ein Passwortmanager nur Usernamen und Passworte merkt und diese „sicher“ im Kontext des Users speichert. Wird ein PC mit gleichem Login von mehreren Personen benutzt, ist ein Passwortmanager eher nicht ratsam.

        Oder habe ich das Problem nicht verstanden?

        Rolf

        --
        sumpsi - posui - obstruxi
        1. Servus!

          Hallo Matthias,

          ein Passwortmanager sollte eigentlich beim ersten Eingeben des Passworts fragen, ob er sich das merken soll. Und als Antwort anbieten: Ja, Jetzt nicht, Nie. Einmal "Nie" gewählt sollte weitere Angebote dieser Art verstummen lassen.

          Ja, genau! Und jetzt sei mal ehrlich: klickst du auf "Nie" oder wählst du den bequemen Weg?

          Ich persönlich muss da mein Verhalten mal zumindest hinterfragen.

          Ansonsten ist das eine Form der Medienkompetenz, die hier erworben werden muss. Die ersten Onlinebanking-Besuche solltest Du ihn nicht allein machen lassen. Bei der Gelegenheit lässt sich der Passwortmanager in die Schranken weisen.

          Auf jeden Fall. Anscheinend haben alle 12-Jährigen eine Debit-Karte. Wir wollen das jetzt auch ganz langsam angehen lassen. Bis jetzt kriegt er noch nicht mal Taschengeld, weil er von Groß- und Urgroßeltern so viel Cash mit heimnimmt - ist unpädagogisch, aber was kann ich gegen meine Schwiegerleut' ausrichten? 😀

          Im Übrigen sind autocomplete und Passwortmanager zwei sehr unterschiedliche Biester. Die Werte für autocomplete sind über alle Webseiten gleich und sollen die Eingabe von Adressen etc einsparen, während ein Passwortmanager nur Usernamen und Passworte merkt und diese „sicher“ im Kontext des Users speichert. Wird ein PC mit gleichem Login von mehreren Personen benutzt, ist ein Passwortmanager eher nicht ratsam.

          Genau das muss man in font-size:5em; color:red; jedem hinter die Ohren schreiben. Und da ist mein Desktop-Computer wohl noch ok, mein Dienst-Laptop und das Surface eben eher nicht. Und der Anfänger-Laptop meines Sohnes ist da eben auch kein Single-User-Device.

          Oder habe ich das Problem nicht verstanden?

          Doch, aber ich eben erst kurz vor Schreiben des Posts. Die Beispiele erhalten vom Passwortmanager Vorschläge zu allen selfhtml-Logins, die ich je hatte, wie blog.selfhtml.org, intern.selfhtml.orgvon 2014 und ebenso forum.de.selfhtml.org - Wahnsinn!

          [EDIT] Hab grad den Inkognito-Modus probiert - auch da hilft der Passwortmanager! [/EDIT]

          Herzliche Grüße

          Matthias Scharwies

          --
          Das wirksamste Mittel gegen Sonnenbrand
          ist Urlaub am Ostseestrand!
          1. „Mist, mein Account wurde gehackt!“

            „Hattest du ein schlechtes Passwort?“

            „Nein, überhaupt nicht! Das Jahr der Heiligsprechung des Heiligen Dominikus durch Papst Gregor den IX!“

            „Wann war das?“

            „1234.“


            Bis bald!

            Jonathan

            --
            "Ich habe heute ein Elan-Problem und mein Tatenvolumen ist fast aufgebraucht!"
    3. Hallo zusammen,

      ... Als 'writingsuggestions' hat es sogar seinen Weg in die Spec geschafft.

      Weiß jemand mehr darüber?

      Nein, und dieser Thread ist schon das 4. Suchergebnis.[^1]

      Formulare/Eingabe von Text

      Bei 3.2 writingsuggestions ist alles relativ knapp gehalten.

      Ich finde, dass alle Browser nur wenige Wörter unterringeln und Korrekturen vorschlagen.

      Ich weiß aber nicht, inwieweit ich dort an den Browser-Einstellungen fummeln kann, bzw. soll und wie das dann in den Wiki-Artikel soll.

      Sonderfall type = "password"

      @Rolf B Das 1. Beispiel hatte mich mit meinem Passwort-Manager, der für SELFfHTML 12 Logins angeboten hatte, zur Verzweiflung gebracht. Das wird ein Schüler im Computerraum so nicht haben.

      Das zweite Beispiel des sichtbar-Machens ist von setAttribute() hierherverschoben und durch writingsuggestions="false" ergänzt.

      Ich glaube, dass man da der Spec folgen soll und eben writingsuggestions="false" spellcheck="false" setzen muss. Wenn das noch niemand kennt, ist das eben unsere Aufgabe, das in unseren Tutorials zu empfehlen.

      Und diese ganze Irritiation habe ich in den letzten Abschnitt gepackt:

      Passwortmanager - Fluch und Segen

      Das war mein Damaskus-Erlebnis: Bis jetzt sah ich den Passwortmanager als bequeme Beschleunigung meines Arbeitsprozesses. Erst auf dem Rechner meines Sohnes fragte ich mich, ob das wirklich sinnvoll sei, Passworteingaben derart auszuhebeln.

      Und jetzt wird mir klar, warum alle möglichen Webseiten (z.B. github) in der letzten Zeit auf 2FA umgestiegen sind. Es gibt eben keine Passwortsicherheit mehr!

      Was mich so konfus macht: Das stand ja schon bei autocomplete (ist dort immer noch) und wird in diesem Abschnitt hoffentlich verständlich erklärt.

      Ich habe zusätzlich 2 Cards zu weiterführenden Artikeln angelegt. Da müsste das eigentlich auch noch rein.

      Bitte gebt mir ein Feedback, ob das so passt.

      Morgen am Discord-Stammtisch werde ich das vorstellen und diskutieren.

      Herzliche Grüße

      Matthias Scharwies

      --
      Das wirksamste Mittel gegen Sonnenbrand
      ist Urlaub am Ostseestrand!