Browser pfuscht bei <input> dazwischen

[Linuchs]

Moin,

ich habe viele Input-Felder, die per Ajax Vorschlagswerte vom Server holen und anzeigen.

Nun kommt es vor, dass der Browser (z.B. Firefox) meine Anzeige überdeckt (Feld mit weißem Hintergrund). Das ist nicht erwünscht:

HTML-Code des Feldes:

<p><l title="Postleitzahl | Postcode | Postcode">###Postleitzahl###Postcode###Postcode### <img id=such_plz class=help /></l>
<input [disabled]
type        = "text"
name        = "such_plz"
title       = "such_plz"
size        = 10
maxlength   = 10
VALUE       = "[such_plz]"
oninput     = "getOrte( this )"
onblur      = "getOrteSchliessen()"
/></p>

Nun habe ich mal geschaut, wie das Suchfeld bei gugel aussieht:

<input class="og3lId" maxlength="2048" id="REsRA" name="q" type="text" aria-autocomplete="both" aria-haspopup="false" autocapitalize="none" autocomplete="off" autocorrect="off" role="combobox" spellcheck="false" title="Suchen" value="Hochflanschnabe" aria-label="Suchen">

Wie kann ich grundsätzlich alle autos in einem Formular verbieten? Oder muss der Sermon bei jedem Feld einzeln gebetet werden?

Gruß, Linuchs

[Der Martin]

Hallo,

Wie kann ich grundsätzlich alle autos in einem Formular verbieten? Oder muss der Sermon bei jedem Feld einzeln gebetet werden?

zumindest autocomplete kannst du auch fürs form-Element notieren, dann gilt es für alle Inputs.
Die anderen Autos tun meines Wissens nicht weh.

Live long and pros healthy,
 Martin

[Linuchs]

Hallo,

deine verlinkte Seite behauptet default-Wert off

Kann das bei einem geheimen FF-update (jetzt 87.0 (64-Bit)) umgestellt worden sein?

Gestern konnte ich den „Fehler“ nicht nachvollziehen, heute tritt er auch bei mir auf. Hier ein öffentliches Formular, passiert das bei dir auch bei Eingabe der Postleitzahl?

Habe noch nicht auf autocomplete=off geändert, damit der Fehler nachvollziehbar ist.

https://remso.eu/?zp=p504&ORT=13165&lg=de

[Linuchs]

Auf mozilla.org lese ich,

The HTML autocomplete attribute is available on <input> elements that take a text or numeric value as input, <textarea> elements, <select> elements, and <form> elements.

Also mehr Elemente als bei SelfHTML angegeben. Gilt das nur für den Firefox?

Weiter unten:

The persistence feature is enabled by default. Setting the value of the autocomplete attribute to off disables this feature.

[Der Martin]

Mahlzeit,

deine verlinkte Seite behauptet default-Wert off

das wage ich zu bezweifeln; ich habe mich bei frisch installierten Firefoxen schon oft über dieses lästige "Feature" geärgert.

Kann das bei einem geheimen FF-update (jetzt 87.0 (64-Bit)) umgestellt worden sein?

Ich behaupte: Es war schon immer per Default "on".

Gestern konnte ich den „Fehler“ nicht nachvollziehen, heute tritt er auch bei mir auf. Hier ein öffentliches Formular, passiert das bei dir auch bei Eingabe der Postleitzahl?

Bei mir tritt der Effekt generell nicht auf, weil ich autocomplete global in meinen Browser-Einstellungen deaktiviert habe.

Live long and pros healthy,
 Martin

[Linuchs]

Ich behaupte: Es war schon immer per Default "on".

Wenn du Recht hast, lügt die Seite https://wiki.selfhtml.org/wiki/HTML/Attribute/autocomplete

[Auge]

Hallo

Ich behaupte: Es war schon immer per Default "on".

Wenn du Recht hast, lügt die Seite https://wiki.selfhtml.org/wiki/HTML/Attribute/autocomplete

Wie kommst du darauf? SelfHTML ist nicht die Doku für den Firefox, also lasse mit solchen Aussagen Vorsicht walten. Wenn der Standard sagt, der Defaultwert lautet „off“, gibt das SelfHTML so wieder, egal, ob ein Browserhersteller in seinem Produkt einen anderen Defaultwert benutzt (wenn das denn so sein sollte).

Tschö, Auge

[Der Martin]

Hallo,

Wenn du Recht hast, lügt die Seite https://wiki.selfhtml.org/wiki/HTML/Attribute/autocomplete

Wie kommst du darauf? SelfHTML ist nicht die Doku für den Firefox, also lasse mit solchen Aussagen Vorsicht walten. Wenn der Standard sagt, der Defaultwert lautet „off“, gibt das SelfHTML so wieder, egal, ob ein Browserhersteller in seinem Produkt einen anderen Defaultwert benutzt (wenn das denn so sein sollte).

okay, guter Punkt. Man sollte unterscheiden zwischen "Defaultwert gemäß Standard" und "Default der konkreten Browser-Implementierung".

Live long and pros healthy,
 Martin

[Der Martin]

Hi,

Ich behaupte: Es war schon immer per Default "on".

Wenn du Recht hast, lügt die Seite https://wiki.selfhtml.org/wiki/HTML/Attribute/autocomplete

ja, ich vermute, dass das falsch ist.

Live long and pros healthy,
 Martin

[Rolf B]

Hallo Linuchs,

Wenn du Recht hast, lügt die Seite https://wiki.selfhtml.org/wiki/HTML/Attribute/autocomplete

Die Seite lügt definitiv nicht. Bitte wähle deine Worte mit Bedacht. "Lüge" ist eine vorsätzliche Falschaussage. Das Wort, dass Du nutzen solltest, heißt "Irrtum".

Ich habe die Seite überarbeitet und hoffe, dass es nun besser ist.

Rolf

[Gunnar Bittersmann]

@@Linuchs

Kann das bei einem geheimen FF-update (jetzt 87.0 (64-Bit)) umgestellt worden sein?

In welcher Zeitschleife bist du denn gefangen? Aktuell ist 91.0.

😷 LLAP

[Der Martin]

Hallo nochmal,

Kann das bei einem geheimen FF-update (jetzt 87.0 (64-Bit)) umgestellt worden sein?

du solltest Firefox updaten. Aktuell ist Version 91.0.

Live long and pros healthy,
 Martin

[Gunnar Bittersmann]

@@Der Martin

Kann das bei einem geheimen FF-update (jetzt 87.0 (64-Bit)) umgestellt worden sein?

du solltest Firefox updaten. Aktuell ist Version 91.0.

Erster! 😜

Und dass Linux noch bei 87 hängt, lässt noch was Anderes vermuten: Er sollte die automatischen Updates aktivieren.

😷 LLAP

[Auge]

Hallo

… FF-update (jetzt 87.0 (64-Bit)) …

du solltest Firefox updaten. Aktuell ist Version 91.0.

Erster! 😜

Und dass Linux …

Wenn, dann „Linuchs“; Linux kennt Firefox 91.0.

… noch bei 87 hängt, lässt noch was Anderes vermuten: Er sollte die automatischen Updates aktivieren.

Meinst du automatische Updates über die Firefox-interne Updatefunktion, wie sie die Windows-Version hat? Die gibt es – zumindest in Debian-basierten Distros – schlicht nicht. Da läuft alles über die distributionseigene Paketverwaltung. Und die gibt den Firefox 91.0 (zumindest bei Ubuntu-basierten Distros) her.

Tschö, Auge

[Gunnar Bittersmann]

@@Auge

Und dass Linux …

Wenn, dann „Linuchs“; Linux kennt Firefox 91.0.

🧐

Immer ein waxames Auge …

😷 LLAP

[Der Martin]

Hallo Gunnar,

du solltest Firefox updaten. Aktuell ist Version 91.0.

Erster! 😜

jaja, schon gut. Ich muss nicht überall erster sein. 😉

Und dass Linux noch bei 87 hängt, lässt noch was Anderes vermuten: Er sollte die automatischen Updates aktivieren.

Linuchs verwendet Linux, AFAIK Ubuntu. Da ist ein systemweites automatisches Update eigentlich Standard. Nein, stimmt nicht ganz: Standard ist, dass der Update-Manager mehrmals täglich die Paketliste frisch abruft (also ein apt-get update im Hintergrund macht), und die Verfügbarkeit neuer Updates mit einem Symbol im Tray anzeigt. Wenn man dann darauf nicht reagiert ... selber schuld.

Live long and pros healthy,
 Martin

[Auge]

Hallo

Linuchs verwendet Linux, AFAIK Ubuntu. Da ist ein systemweites automatisches Update eigentlich Standard. Nein, stimmt nicht ganz: Standard ist, dass der Update-Manager mehrmals täglich die Paketliste frisch abruft (also ein apt-get update im Hintergrund macht), und die Verfügbarkeit neuer Updates mit einem Symbol im Tray anzeigt. Wenn man dann darauf nicht reagiert ... selber schuld.

Wenn er seit dem Erscheinen der Folgeversion von Firefox 87.0 (im März 2021) kein Systemupdate mehr durchgeführt haben sollte, wäre das mehr als fahrlässig. Wenn er jedesmal das Update des Firefox aus den angebotenen Updats herausnähme, ganz schön viel Arbeit. Die version 87 ist jedenfalls keine LTS-Version (was ja auch noch hätte sein können), das ist aktuell der 78-er Branch (jetzt: 78.13).

Tschö, Auge

[Linuchs]

Und dass Linux noch bei 87 hängt, lässt noch was Anderes vermuten: Er sollte die automatischen Updates aktivieren.

Früher hatte ich gefühlt zwei Ubuntu-Updates pro Woche, jetzt seit Monaten nichts mehr. Hatte ich da vielleicht mal auf später geklickt, weil's nervig wurde?

Beim Booten meldet Ubuntu 20.04 - was muss ich tun, um wieder aktuell dabei zu sein? Bin nicht so der „Schrauber“ für Betriebssysteme.

[Auge]

Hallo

Und dass Linux noch bei 87 hängt, lässt noch was Anderes vermuten: Er sollte die automatischen Updates aktivieren.

Früher hatte ich gefühlt zwei Ubuntu-Updates pro Woche, jetzt seit Monaten nichts mehr. Hatte ich da vielleicht mal auf später geklickt, weil's nervig wurde?

Beim Booten meldet Ubuntu 20.04 - was muss ich tun, um wieder aktuell dabei zu sein? Bin nicht so der „Schrauber“ für Betriebssysteme.

Rufe einfach die Updateverwaltung auf. Die durchsucht als erstes die aktuell verfügbaren Quellen nach Updates und sollte sie dir dann anbieten.

Im Terminal geht das auch in zwei Schritten …

sudo apt update
sudo apt upgrade

… oder in einem Schritt:

sudo apt update && sudo apt upgrade

Tschö, Auge

[Linuchs]

Nach dem Einzeiler kommt zum Schluss dies:

Aktualisierung für 380 Pakete verfügbar. Führen Sie »apt list --upgradable« aus, um sie anzuzeigen.
W: Während der Überprüfung der Signatur trat ein Fehler auf. Das Depot wurde nicht aktualisiert und die vorherigen Indexdateien werden verwendet. GPG-Fehler: http://download.opensuse.org/repositories/home:/stevenpusser/xUbuntu_20.04  InRelease: Die folgenden Signaturen waren ungültig: EXPKEYSIG 0FAD31CA8719FCE4 home:stevenpusser OBS Project <home:[e-mail]>
W: Fehlschlag beim Holen von http://download.opensuse.org/repositories/home:/stevenpusser/xUbuntu_20.04/InRelease Die folgenden Signaturen waren ungültig: EXPKEYSIG 0FAD31CA8719FCE4 home:stevenpusser OBS Project <home:[e-mail]>
W: Einige Indexdateien konnten nicht heruntergeladen werden. Sie wurden ignoriert oder alte an ihrer Stelle benutzt.
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.       
Statusinformationen werden eingelesen.... Fertig
Probieren Sie »apt --fix-broken install«, um dies zu korrigieren.
Die folgenden Pakete haben unerfüllte Abhängigkeiten:
 kyodialog : Hängt ab von: python-reportlab ist aber nicht installierbar
E: Unerfüllte Abhängigkeiten. Versuchen Sie »apt --fix-broken install« ohne Angabe eines Pakets (oder geben Sie eine Lösung an).
kalle@terra-laptop:~$

[Linuchs]

Und weiter:

apt --fix-broken install
E: Sperrdatei /var/lib/dpkg/lock-frontend konnte nicht geöffnet werden. - open (13: Keine Berechtigung)
E: Erlangen der Sperre für die Dpkg-Oberfläche (/var/lib/dpkg/lock-frontend) nicht möglich; sind Sie root?

[Auge]

Hallo

apt --fix-broken install E: Sperrdatei /var/lib/dpkg/lock-frontend konnte nicht geöffnet werden. - open (13: Keine Berechtigung) E: Erlangen der Sperre für die Dpkg-Oberfläche (/var/lib/dpkg/lock-frontend) nicht möglich; sind Sie root?

Hast du das apt update eventuell ohne vorangestelltes sudo ausgeführt?

Tschö, Auge

[Linuchss]

ja, aber nun läuft's noch ...

[Linuchs]

Firefox 91.0 ist jetzt drauf, aber immer noch Ubuntu 20.04

[Auge]

Hallo

Firefox 91.0 ist jetzt drauf, aber immer noch Ubuntu 20.04

Ubuntu 20.04 ist ja auch die aktuelle LTS-Version. Es gibt zwar neuere Versionen (20.10, 21.04) aber das sind Testversionen und sie haben jeweils nur neun Monate Support. Auf einem Produktivsystem sollte man, wenn es denn Ubuntu sein soll, nur LTS-Versionen haben wollen.

Tschö, Auge

[Der Martin]

Hallo,

Firefox 91.0 ist jetzt drauf, aber immer noch Ubuntu 20.04

natürlich, die Basisversion deiner Linux-Distro ändert sich auch nicht, wenn du einzelne Software-Komponenten aktualisierst.

Ein dist-upgrade auf die derzeit aktuelle 21.04 würde ich dir aber nicht empfehlen. Denn deine vorhandene 20.04 ist eine LTS-Version (Long-Term Support), die fünf Jahre lang mit Updates versorgt wird. Die 21.04 ist dagegen eine Normalausgabe, die nur 18 Monate versorgt wird. Die nächste LTS ist 22.04, dann lohnt sich ein Upgrade auch wieder.

Live long and pros healthy,
 Martin

[Auge]

Hallo

Die 21.04 ist dagegen eine Normalausgabe, die nur 18 Monate versorgt wird.

Neun Monate, nicht achtzehn. Die Zeiten mit 18 Monaten sind lange vorbei. Wenn ich die Versionstabelle nicht missinterpretiere, war die 13.04 die erste Nicht-LTS-Version mit nur neun Monaten Laufzeit.

Tschö, Auge

[Der Martin]

Hi,

Die 21.04 ist dagegen eine Normalausgabe, die nur 18 Monate versorgt wird.

Neun Monate, nicht achtzehn. Die Zeiten mit 18 Monaten sind lange vorbei.

meine Zeit mit Ubuntu auch. Wenn ich mich recht erinnere, war Lucid (10.04) die letzte Ubuntu-Ausgabe, die ich benutzt habe, bevor ich zu Mint übergegangen bin.

Wenn ich die Versionstabelle nicht missinterpretiere, war die 13.04 die erste Nicht-LTS-Version mit nur neun Monaten Laufzeit.

Ja, sieht aus als hättest du recht.

Live long and pros healthy,
 Martin

[Gunnar Bittersmann]

@@Linuchs

HTML-Code des Feldes:

<p><l title="Postleitzahl | Postcode | Postcode">###Postleitzahl###Postcode###Postcode### <img id=such_plz class=help /></l>
<input [disabled]
type        = "text"
name        = "such_plz"
title       = "such_plz"
size        = 10
maxlength   = 10
VALUE       = "[such_plz]"
oninput     = "getOrte( this )"
onblur      = "getOrteSchliessen()"
/></p>

Nein, HTML-Code ist das nicht.

Es gibt in HTML kein l-Element.^[1]

Dass das Formular unbedienbar ist, weil die Eingabefelder keine Beschriftung^[2] haben, muss man dir immer wieder aufs Neue sagen‽

😷 LLAP

---

1. In XHTML 2 hätte es das geben sollen. *seufz* ↩︎

2. Sehe gerade, dass die Seite auch berichtigt werden muss. „Wird das betreffende input-Element als Kindelement des label definiert, so ist eine ausdrückliche Zuordnung zwischen input und label mittels for-Attribut nicht mehr zusätzlich nötig“ ist leider falsch. ↩︎

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Nein, HTML-Code ist das nicht.

Außerdem: dem img-Element fehlt das zwingend notwendige alt-Attribut. Bei dekorativen Bildern ist alt="" anzugeben (sofern die Bilder nicht per CSS auf die Seite kommen).

Und was soll das [disabled] da?

😷 LLAP

[Linuchs]

Hatte der Einfachheit halber die Rohform gepostet.

Das <img Element wird per Javascript ergänzt und sieht dann so aus:

<p><l title="Postleitzahl | Postcode | Postcode">Postleitzahl <img id="such_plz" class="help" src="img/icon_info.png" alt="(i)" style="width: 1.2em; height: 1.2em;"></l>
<input [disabled]="" type="text" name="such_plz" title="getOrte.js //remso.eu/ajax/getOrte.php?such_ort_name=6378" size="10" maxlength="10" value="63785" oninput="getOrte( this )" onblur="getOrteSchliessen()"></p>

Und die Armen Leute, die sich Javascript nicht leisten können, können mit diesem Bild ohnehin nichts anfangen, denn per Klick zeigt es einen per Ajax geholten Hilfstext zum Feld.

[disabled] ist durch NULL (nix, nada) zu ersetzen, Programmierfehler.

[Gunnar Bittersmann]

@@Linuchs

Das <img Element wird per Javascript ergänzt und sieht dann so aus:

<p><l title="Postleitzahl | Postcode | Postcode">Postleitzahl <img id="such_plz" class="help" src="img/icon_info.png" alt="(i)" style="width: 1.2em; height: 1.2em;"></l>
<input [disabled]="" type="text" name="such_plz" title="getOrte.js //remso.eu/ajax/getOrte.php?such_ort_name=6378" size="10" maxlength="10" value="63785" oninput="getOrte( this )" onblur="getOrteSchliessen()"></p>

„(i)“ ist nun auch kein sinnvoller Alternativtivtext. Soll ein Screenreader „Klammer auf – I – Klammer zu“ vorlesen?

Nein. Sondern was?

Vielleicht gar nichts? Dann ist alt="" anzugeben. Bei fehlendem alt-Attribut wird der Dateiname vorgelesen.

Oder was anderes? alt="Info"? Welchen Zweck hat das Icon?

Übrigens wäre eine Vektorgrafik (SVG) fürs Icon sicher sinnvoller als ein PNG.

---

Und wie ist das mit dem <l>? Wird das auch mit JavaScript durch irgendwas anderes ersetzt?

😷 LLAP

[MudGuard]

Hi,

Vielleicht gar nichts? Dann ist alt="" anzugeben. Bei fehlendem alt-Attribut wird der Dateiname vorgelesen.

Das glaub ich nicht.

Evtl. wird der Teil der Url vorgelesen, der wie ein Dateiname aussieht, evtl. der der Teil der Url, der nach dem letzten / steht?

Aber den Dateinamen kann der Screenreader nicht wissen - unter der Bild-Url "bla.png" kann der Webserver ja auch eine Datei mit Namen "blubb.png" ausliefern.

Oder der Webserver erzeugt das Bild dynamisch, dann gibt es nicht einmal eine Datei …

cu,
Andreas a/k/a MudGuard

[Gunnar Bittersmann]

@@MudGuard

Vielleicht gar nichts? Dann ist alt="" anzugeben. Bei fehlendem alt-Attribut wird der Dateiname vorgelesen.

Das glaub ich nicht.

Ich will dich von deinem Nicht-Glauben nicht abbringen. 😉

Evtl. wird der Teil der Url vorgelesen, der wie ein Dateiname aussieht, evtl. der der Teil der Url, der nach dem letzten / steht?

„Evtl.“ ist die Abkürzung für „ganz bestimmt“?

😷 LLAP

[dedlfix]

Tach!

Nein, HTML-Code ist das nicht.

Es gibt in HTML kein l-Element.

Formal hast du da recht, aber wo ist das Problem, ein Custom Element zu verwenden?

Dass das Formular unbedienbar ist, weil die Eingabefelder keine Beschriftung haben,

Kann es sein, dass du da mal wieder übertreibst. Ein Text wird auch nicht unlesbar, wenn ein Schreibfehler enthalten ist, oder wenn keine Übersetzungen in alle anderen Sprachen dieser Welt vorhanden sind.

muss man [dir immer wieder aufs Neue sagen]‽

Nein, das muss man ihm nicht sagen. Es besteht keine Notwendigkeit, dass man sich wie sein Erziehungsberechtigter benimmt. Und man muss sich auch nicht selbst zum Fürsprecher seiner Zielgruppe ernennen. Das soll nicht heißen, dass man nicht auf Verbesserungsmöglichkeiten hinweisen darf. Man darf dabei aber ruhig einen gemäßigteren Ton verwenden. Ich würde das jedenfalls sehr begrüßen.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Es gibt in HTML kein l-Element.

Formal hast du da recht, aber wo ist das Problem, ein Custom Element zu verwenden?

Beim fehlenden Bindestrich.

Dass das Formular unbedienbar ist, weil die Eingabefelder keine Beschriftung haben,

Kann es sein, dass du da mal wieder übertreibst.

Nein.

Wenn ich „Beschriftung“ sage, dann meine ich „Beschriftung für alle“, nicht nur für Priviligierte.

Nein, das muss man ihm nicht sagen.

Weil Linuchs sowieso aufnahmeunwillig ist und man gegen eine Wand redet?

Es besteht keine Notwendigkeit, dass man sich wie sein Erziehungsberechtigter benimmt.

Du meinst: Oberlehrer‽

Und man muss sich auch nicht selbst zum Fürsprecher seiner Zielgruppe ernennen.

Was nervt: (gefühlt) immer, wenn man sich hier für Barrierefreiheit einsetzt, grätscht irgendein Stammposter dazwischen und meint: ach, ist doch nicht so wichtig.

Man darf dabei aber ruhig einen gemäßigteren Ton verwenden.

Mein Ton war nicht ungemäßigt.

😷 LLAP

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Es gibt in HTML kein l-Element.

Formal hast du da recht, aber wo ist das Problem, ein Custom Element zu verwenden?

Beim fehlenden Bindestrich.

Custom elements müssen einen solchen enthalten.

Mir ist bewusst, dass HTML-Parser auch Phantasie-Elemente verarbeiten – (fast) wie span. Und stylen kann man die Dinger mit CSS auch.

In der CSSBattle hatte ich mir das auch mal zunutzegemacht.

Andere auch: <s><l><o><n>. Chapeau!

😷 LLAP

[dedlfix]

Tach!

Es gibt in HTML kein l-Element.

Formal hast du da recht, aber wo ist das Problem, ein Custom Element zu verwenden?

Beim fehlenden Bindestrich.

Das konkrete Problem daran ist welches?

Und man muss sich auch nicht selbst zum Fürsprecher seiner Zielgruppe ernennen.

Was nervt: (gefühlt) immer, wenn man sich hier für Barrierefreiheit einsetzt, grätscht irgendein Stammposter dazwischen und meint: ach, ist doch nicht so wichtig.

Es geht nicht darum, dass du dich für die Barrierefreiheit einsetzt, sondern um die Art und Weise, wie du das machst. Wenn ich Fürsprecher für irgendeine Sache suchen würde, würde meine Wahl nicht auf diejenigen fallen, die das mit Gewalt in die Zielgruppe hineinzuprügeln versuchen. Wenn ich mich als Entwickler nicht ernst genommen fühle, warum solte ich dann meinerseits die Argumente ernst nehmen? "Das funktioniert überhaupt nicht" ist eine komplett gegensätzliche Aussage zu dem, was der Entwickler selbst beobachten kann, denn aus seiner Sicht funktioniert es ja. Mir geht es bei solchen Aussagen eher so, dass sich die Distanz zum Aussagenden erhöht. Sich zu entfremden kann ja wohl kaum der Weg sein, ein Ziel zu einem gemeinsamen zu machen.

dedlfix.

[Der Martin]

Hallo,

Mir geht es bei solchen Aussagen eher so, dass sich die Distanz zum Aussagenden erhöht.

sehe ich genauso. Das erinnert mich an meinen Vater: Er hat die schlechte Angewohnheit, andere an lästige oder unangenehme Aufgaben zu erinnern, das aber so polemisch zu formulieren, dass man sich dabei beleidigt oder verletzt fühlen könnte.
Er meint, so würde er die/den Angesprochene/n motivieren, die fällige Aufgabe endlich zu erledigen. Tatsächlich erreicht er bei einigen Menschen genau das Gegenteil: Eine Trotzreaktion, die mit jedem Mal stärker wird, obwohl man genau weiß, dass sie jeder Vernunft widerspricht.

Live long and pros healthy,
 Martin

[Gunnar Bittersmann]

@@Der Martin

Das erinnert mich an meinen Vater: Er hat die schlechte Angewohnheit, andere an lästige oder unangenehme Aufgaben zu erinnern, das aber so polemisch zu formulieren, dass man sich dabei beleidigt oder verletzt fühlen könnte.

ACK

Tatsächlich erreicht er bei einigen Menschen genau das Gegenteil: Eine Trotzreaktion

Hier muss gestehen, dass ich etwas trotzig werde, wenn ich jemandem Grundlagen vermittle und ebenderselbe ein paar Tage später hier wieder aufschlägt und erkennen lässt, dass er sämtliche Hinweise zu den Grundlagen in den Wind schlägt.

😷 LLAP

[Tabellenkalk]

Hallo,

jemandem und ebenderselbe

Dir ist klar, dass dieser vom Alter her dein Großvater sein könnte? Nein, offenbar nicht. Ich wär froh, wenn mein Vater so eine Webkompetenz wie Linuchs hätte...

Gruß
Kalk

[Der Martin]

Hi,

jemandem und ebenderselbe

Dir ist klar, dass dieser vom Alter her dein Großvater sein könnte?

na na, ich glaube, du schätzt ihn deutlich zu alt ein. Oder Gunnar zu jung.

Ich wär froh, wenn mein Vater so eine Webkompetenz wie Linuchs hätte...

Daran kann sich mancher ein Beispiel nehmen. Aber ich schlage mir auch manchmal die Hände vors Gesicht, wenn ich sehe, was für abstruse Mittel und Wege er nutzt.

Live long and pros healthy,
 Martin

[Tabellenkalk]

Hallo,

na na, ich glaube, du schätzt ihn deutlich zu alt ein. Oder Gunnar zu jung.

Du meinst, die zwei sind weniger als 23 Jahre auseinander?

Gruß
Kalk

[Der Martin]

Hi,

na na, ich glaube, du schätzt ihn deutlich zu alt ein. Oder Gunnar zu jung.

Du meinst, die zwei sind weniger als 23 Jahre auseinander?

ich glaube ja, denke aber, es wird so etwa in der Größenordnung liegen.
Und ... 23 Jahre für zwei Generationen? Wow, sportlich! 🤔

Live long and pros healthy,
 Martin

[Gunnar Bittersmann]

@@Tabellenkalk

Dir ist klar, dass dieser vom Alter her dein Großvater sein könnte?

Du schätzt mich ein, zwei Jahrzehnte jünger? Das nehm ich als Kompliment. 👴

😷 LLAP

[Der Martin]

Hallo,

Hier muss gestehen, dass ich etwas trotzig werde, wenn ich jemandem Grundlagen vermittle und ebenderselbe ein paar Tage später hier wieder aufschlägt und erkennen lässt, dass er sämtliche Hinweise zu den Grundlagen in den Wind schlägt.

kann ich zwar verstehen, ich wäre dann auch etwas ... na sagen wir, ich käme mir vor, als wollte man mich ärgern. Meine Reaktion ginge dann aber anstatt Trotz eher in Richtung Ignorieren.

Live long and pros healthy,
 Martin

[dedlfix]

Tach!

Hier muss gestehen, dass ich etwas trotzig werde, wenn ich jemandem Grundlagen vermittle und ebenderselbe ein paar Tage später hier wieder aufschlägt und erkennen lässt, dass er sämtliche Hinweise zu den Grundlagen in den Wind schlägt.

Vielleicht solltest du in solchen Fällen gelassener werden. Für dich mag es wichtig aussehen, was du da zu vermitteln versuchst. Aber der Entwickler hat seine eigene Sicht auf seine Dinge, hat andere Prioritäten, muss andere Herausforderungen bestehen. Wenn eine Sache läuft, lässt man sie lieber laufen, anstatt noch eine Baustelle zu eröffnen, für die man den Nutzen nicht selbst erkennt oder als nicht so wichtig einschätzt. Es hilft dann auch nicht, wenn du aus deiner externen Position nochmal draufschlägst. Wenn die Leute deine Ziele verfolgen sollen, dann muss sich das in deren Problemumfeld so integrieren kassen, dass es nicht zu einer zusätzlichen Last wird. Zum Beispiel, wenn jemand mit einem Tool arbeitet, und das aus deiner Sicht schlecht ist, hilft es demjenigen nicht, nur das Tool schlechtgeredet zu bekommen. Man nimmt das ja, um eine Aufgabe zu erledigen. Und die verschwindet nicht, wenn man das Tool einfach nur wegzunehmen versucht. Da muss eine Alternative her, die möglichst keinen Umstellungsaufwand erfordert, und die man auch mit den vorhandenen technischen, finanziellen und anderen Fähigkeiten einsetzen kann.

dedlfix.

[Rolf B]

Hallo dedlfix,

Linuchs ist wirklich nicht mehr der jüngste. Er hat schon einmal sehr klar gesagt, dass er sich aus dem Thema eigentlich zurückziehen und in den Ruhestand gehen möchte, und einen Nachfolger sucht, den er einarbeiten kann. Deswegen würde ich an seiner Stelle ebenfalls sagen: Ich mache das, was direkten Nutzen für die bekannten Nutzer bietet, und den Rest kann mein Nachfolger erledigen. Wenn's denn einen gibt.

Wenn er keinen negativen Feedback von den Nutzern bekommt, was Accessibility angeht, dann hat der diese Nutzer nicht - oder eben schon längst verloren - und gewinnt nichts durch Accessibility-Maßnahmen.

Für einen A11Y Evangelisten wie Gunnar ist das natürlich eine Ohrfeige. Für Linuchs ist Scope-Limitierung eine Frage des Überlebens.

Rolf

[ottogal]

Für einen A11Y Evangelisten wie Gunnar ...

Vorsicht, Rolf! Gunnar ist auch ein Deppen Leerzeichen Evangelist ...

[Rolf B]

Hallo dedlfix,

Das konkrete Problem daran ist welches?

Dass es kein Standard ist. Sich Tagnamen auszudenken, die potenziell irgendwann mit neu hinzukommenden Standard-Tags kollidieren, ist keine gute Idee. Deswegen gibt es die Vorgabe, custom tags mit einem "-" darin zu versehen. Die Spec sichert zu, dass es keine Standard-Tags mit einem "-" im Namen geben wird.

Es ist natürlich lästig, wenn man gerne kurze, knappe Tags wie <l> für "Line" haben möchte. Aber wenn sich zu Zeiten von HTML 5.0 ausgedacht hätte, Elemente wie menu oder dialog zu "erfinden", wäre er mit dialog jetzt schon auf die Nase gefallen, und menu könnte auch noch kommen.

Es besteht dann immer noch Kollisionsgefahr, wenn man HTML aus mehreren Quellen mischt, aber das zu erkennen liegt noch im Scope des Entwicklers.

Rolf

[dedlfix]

Tach!

Das konkrete Problem daran ist welches?

Dass es kein Standard ist. Sich Tagnamen auszudenken, die potenziell irgendwann mit neu hinzukommenden Standard-Tags kollidieren, ist keine gute Idee.

Wie gesagt, formal gesehen ist das richtig. Im konkreten Fall dient das Element augenscheinlich dazu, Daten ins Dokument zu bekommen, die vom Browser nicht direkt angezeigt werden sollen. Da findet eine Bearbeitung statt, bevor da was zur Anzeige kommt. Es ist Teil des Systems, dass sich Linuchs für die Realisierung von Mehrsprachigkeit ausgedacht hat. Hatte er auch schon früher irgendwann erwähnt. Ich würde mir keine gesteigerten Gedanken darüber machen, dass das System wegen neu eingeführter HTML-Elemente in Zukunft grundlegend kaputtgehen wird.

Wie auch immer, ich hätte es besser gefunden, wenn Gunnar nicht von oben herab nur geblafft hätte, dass das kein HTML sei, sondern den Vorschlag unterbreitet hätte, dass ein Elementname mit Bindestrich die bessere Lösung sei, wegen $kurze_erklärung. Wenn es mein Projekt gewesen wäre, hätte ich bei der Aussage jedenfalls nur mit den Schultern gezuckt und es so gelassen, weil es ja läuft. Das war eine viel zu leichtfertig verspielte Chance, Bewusstsein für ein mögliches Problem zu schaffen.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Wie auch immer, ich hätte es besser gefunden, wenn Gunnar nicht von oben herab nur geblafft hätte, dass das kein HTML sei

Kein Geblaffe.

Ich gehe bei meinen Antworten oft auf das ein, was der/die andere geschrieben hat. So auch hier: „Nein, HTML-Code ist das nicht“ bezog sich direkt auf Linuchs’ „HTML-Code des Feldes“.

Die sprachlichen Feinheiten scheinen nicht von allen verstanden zu werden … 🤔

😷 LLAP

[Matthias Scharwies]

Servus!

Ich gehe bei meinen Antworten oft auf das ein, was der/die andere geschrieben hat. So auch hier: „Nein, HTML-Code ist das nicht“ bezog sich direkt auf Linuchs’ „HTML-Code des Feldes“.

Die sprachlichen Feinheiten scheinen nicht von allen verstanden zu werden … 🤔

Ich würde das hier gerne beenden, bzw. nicht weiter anfachen. Und trotzdem bin ich inhaltlich auf @dedlfix Seite.

Mich hat geärgert, dass Du das Wiki verlinkt und gleich wieder als fehlerhaft bezeichnet hast.

Dass das Formular unbedienbar ist, weil die Eingabefelder keine Beschriftung^[1] haben, muss man dir immer wieder aufs Neue sagen‽

Im SELF-Wiki steht:

Drei Arten, label logisch einem Eingabe-Element (hier input) zuzuordnen:

1. Wird das betreffende input-Element als Kindelement des label definiert, so ist eine ausdrückliche Zuordnung zwischen input und label mittels for-Attribut nicht mehr zusätzlich nötig. Die Zuordnung erfolgt dabei implizit über die Struktur des Quelltextes. Dies führt jedoch bei Screenreadern zu Schwierigkeiten.

Empfehlung: Nutzen Sie auch bei einer impliziten Zuordnung der Labels zu den Eingabefeldern for-Attribute.

Die von mir markierten Textstellen hast Du, der von sprachlichen Feinheiten redet, geflissentlich weggelassen.

Der Aufbau des Beispiels richtet sich nach der Spec, die das label ebenfalls um das input-Element notiert:

<p><label>Full name: <input name=fn> <small>Format: First Last</small></label></p>
<p><label>Age: <input name=age type=number min=0></label></p>
<p><label>Post code: <input name=pc> <small>Format: AB12 3CD</small></label></p>

Im Übrigen sind alle folgenden Live-Beispiele eben nicht input innerhalb label, sondern label + input.

Der von Dir verlinkte Twitter-Thread dreht sich um den von Nuance vertriebenen Dragon-User-Agent, der bei label-um-input einen Bug hat.

Avoid: <label><input […]></label>

Dragon does not support this.

Still an issue. Known by Dragon. No public bug tracker. Hopefully new owners (Microsoft) can fix this and other issues (like failures with native date picker, ARIA support, etc.).

Manchmal frage ich mich, warum du so viel Energie darauf verwendest uns beweisen zu wollen, dass wir alle blöd sind?

Herzliche Grüße

Matthias Scharwies

---

1. Sehe gerade, dass die Seite auch berichtigt werden muss. „Wird das betreffende input-Element als Kindelement des label definiert, so ist eine ausdrückliche Zuordnung zwischen input und label mittels for-Attribut nicht mehr zusätzlich nötig“ ist leider falsch. ↩︎

[Gunnar Bittersmann]

@@Matthias Scharwies

Mich hat geärgert, dass Du das Wiki verlinkt und gleich wieder als fehlerhaft bezeichnet hast.

Dich würde es weniger ärgern, wenn ich das Wiki gar nicht erst verlinke?

Im SELF-Wiki steht:

Drei Arten, label logisch einem Eingabe-Element (hier input) zuzuordnen:

1. Wird das betreffende input-Element als Kindelement des label definiert, so ist eine ausdrückliche Zuordnung zwischen input und label mittels for-Attribut nicht mehr zusätzlich nötig. Die Zuordnung erfolgt dabei implizit über die Struktur des Quelltextes. Dies führt jedoch bei Screenreadern zu Schwierigkeiten.

Empfehlung: Nutzen Sie auch bei einer impliziten Zuordnung der Labels zu den Eingabefeldern for-Attribute.

Die von mir markierten Textstellen hast Du, der von sprachlichen Feinheiten redet, geflissentlich weggelassen.

Oops. Standen die schon da?

Ja, standen sie. Dann ziehe ich mein „dass die Seite auch berichtigt werden muss“ zurück und ersetze durch „dass die Seite umformuliert werden sollte“.

Erst zu sagen „so ist eine ausdrückliche Zuordnung zwischen input und label mittels for-Attribut nicht mehr zusätzlich nötig“ und dann hinterherzuschieben ‚April, April, muss doch!‘ ist schon verwirrend.

Der Aufbau des Beispiels richtet sich nach der Spec, die das label ebenfalls um das input-Element notiert:

Dass laut HTML-Spec die Zuordnung Label–Eingabefeld bei input in label implizit erfolgt, steht ja außer Frage.

Das Dumme ist ja eben, dass sich nicht alle an die Spec halten. Wie eben die Spracherkennung Dragon.

Manchmal frage ich mich, warum du so viel Energie darauf verwendest uns beweisen zu wollen, dass wir alle blöd sind?

Ich verstehe nicht, warum du aus „Dragon ist blöd“ „wir sind alle blöd“ machst.

😷 LLAP

[Gunnar Bittersmann]

@@dedlfix

Im konkreten Fall dient das Element augenscheinlich dazu, Daten ins Dokument zu bekommen, die vom Browser nicht direkt angezeigt werden sollen. Da findet eine Bearbeitung statt, bevor da was zur Anzeige kommt.

Dann wäre es Linuchs’ Fehler, das mit „HTML-Code des Feldes“ übertitelt zu haben.

😷 LLAP

[Linuchs]

Hallo Rolf,

Deswegen gibt es die Vorgabe, custom tags mit einem "-" darin zu versehen. Die Spec sichert zu, dass es keine Standard-Tags mit einem "-" im Namen geben wird.

Danke für den Hinweis.

Aus zwei Gründen vermeide ich das Minuszeichen in Namen:

1. es kann (in irgend einem anderen Zusammenhang) mit einem Rechenvorgang verwechselt werden.

2. Beim Doppelklick im Editor werden nur die Buchstaben zwischen - markiert.

Kann es Standard-Tags mit Unterstrich _ geben?

Gruß, Linuchs

[Der Martin]

Hi,

Aus zwei Gründen vermeide ich das Minuszeichen in Namen:

1. es kann (in irgend einem anderen Zusammenhang) mit einem Rechenvorgang verwechselt werden.

theoretisch ja, aber das ist weit hergeholt. Das Problem tritt bei CSS-Eigenschaften mit Bindestrich im Namen auf (z.B. font-weight), wenn man sie in Javascript ansprechen will (und nicht weiß, wie's dann richtig geht). Bei HTML-Elementnamen kann ich mir da gerade keinen Konflikt vorstellen.

2. Beim Doppelklick im Editor werden nur die Buchstaben zwischen - markiert.

Okay, ein Aspekt der Fau Bequemlichkeit. Kann ich gelten lassen. 😉

Kann es Standard-Tags mit Unterstrich _ geben?

Derzeit gibt es keine. Verboten wären sie aber nicht. Es ist also denkbar, dass es mal welche geben könnte. Halte ich aber für sehr unwahrscheinlich.

Live long and pros healthy,
 Martin

[Gunnar Bittersmann]

@@Der Martin

Das Problem tritt bei CSS-Eigenschaften mit Bindestrich im Namen auf (z.B. font-weight), wenn man sie in Javascript ansprechen will (und nicht weiß, wie's dann richtig geht)

Richtig geht so: niemals CSS-Eigenschaften mit JavaScript ändern. 😜

Kann es Standard-Tags mit Unterstrich _ geben?

Derzeit gibt es keine. Verboten wären sie aber nicht. Es ist also denkbar, dass es mal welche geben könnte. Halte ich aber für sehr unwahrscheinlich.

Das ist aber keine Begründung, sich nicht an den Standard zu halten.

😷 LLAP

[Der Martin]

Hallo,

Das Problem tritt bei CSS-Eigenschaften mit Bindestrich im Namen auf (z.B. font-weight), wenn man sie in Javascript ansprechen will (und nicht weiß, wie's dann richtig geht)

Richtig geht so: niemals CSS-Eigenschaften mit JavaScript ändern. 😜

okay, Punkt für dich. 😀

Kann es Standard-Tags mit Unterstrich _ geben?

Derzeit gibt es keine. Verboten wären sie aber nicht. Es ist also denkbar, dass es mal welche geben könnte. Halte ich aber für sehr unwahrscheinlich.

Das ist aber keine Begründung, sich nicht an den Standard zu halten.

Richtig, das wollte ich damit auch nicht andeuten. Wobei ... wenn die Spezifikation etwas syntactical sugar einerseits für verboten erklärt, andererseits über die Regeln zur Fehlertoleranz fordert, dass die Browser das trotzdem in einer bestimmten Weise behandeln ... 😈

Aber wem sag ich das? Genau solche Kniffe nutzt du doch bei der CSS Battle regelmäßig aus.

Live long and pros healthy,
 Martin

[Gunnar Bittersmann]

@@Der Martin

… andererseits über die Regeln zur Fehlertoleranz fordert, dass die Browser das trotzdem in einer bestimmten Weise behandeln ... 😈

Aber wem sag ich das? Genau solche Kniffe nutzt du doch bei der CSS Battle regelmäßig aus.

Ich würde aber nicht proprogieren, das, was ich da ausnutze, als Produktivcode zu verwenden.

Ich ertappe mich schon öfter dabei, bei Eigenschaft:Wert das Leerzeichen hinterm Doppelpunkt wegzulassen. 😱

😷 LLAP

[Gunnar Bittersmann]

@@dedlfix

Es gibt in HTML kein l-Element.

Formal hast du da recht, aber wo ist das Problem, ein Custom Element zu verwenden?

Beim fehlenden Bindestrich.

Das konkrete Problem daran ist welches?

l ist kein custom element. x-l wäre eins. (So verwende ich das: Beispiel.)

"Das funktioniert überhaupt nicht" ist eine komplett gegensätzliche Aussage zu dem, was der Entwickler selbst beobachten kann, denn aus seiner Sicht funktioniert es ja.

Du beziehst dich auf „weil die Eingabefelder keine Beschriftung haben“?

Du übersiehst dabei, dass ich das so nicht gesagt habe. Sondern: „weil die Eingabefelder keine Beschriftung haben“.

Und die Eingabefelder haben bei Linuchs keine labels.

😷 LLAP

[Linuchs]

Liebe Streitrunde,

meine Frage war

Wie kann ich grundsätzlich alle autos in einem Formular verbieten?

Habe was gefunden, überraschend einfach und eingefügt in die immer verwendete Datei standard.js. Es hing nicht an dem tag l:

window.addEventListener('DOMContentLoaded', function () {
...
  var formulare = document.getElementsByTagName( "form" );
  var form_nachricht  = "standard.js - " +formulare.length +" form/s: ";
  for ( let i=0; i<formulare.length; i++ ) {
    formulare[i].setAttribute( "autocapitalize",  "none"  );
    form_nachricht +=  'autocapitalize="none" ';
    formulare[i].setAttribute( "autocomplete",    "off"   );
    form_nachricht +=  'autocomplete="off" ';
    formulare[i].setAttribute( "autocorrect",     "off"   );
    form_nachricht +=  'autocorrect="off" ';
  }
  console.log( form_nachricht );
});

Funktioniert mit Firefox 91. Wäre lieb, wenn ihr das mit diversen Browsern prüft auf Seite remso.eu

Im guggel-Suchfeld gibt es noch aria-autocomplete="both", was ist das? Gibt es noch weitere autos, die abzuschalten wären?

Gruß, Linuchs

[Der Martin]

Hallo,

Wie kann ich grundsätzlich alle autos in einem Formular verbieten?

Habe was gefunden, überraschend einfach

und immer noch umständlicher als nötig.

window.addEventListener('DOMContentLoaded', function () {
...
  var formulare = document.getElementsByTagName( "form" );

Was du hier "zu Fuß" nachbaust, stellt Javascript dir als document.forms schon fix und fertig zur Verfügung - eine Collection aller form-Elemente im Dokument.

  var form_nachricht  = "standard.js - " +formulare.length +" form/s: ";
  for ( let i=0; i<formulare.length; i++ ) {
    formulare[i].setAttribute( "autocapitalize",  "none"  );
    form_nachricht +=  'autocapitalize="none" ';
    formulare[i].setAttribute( "autocomplete",    "off"   );
    form_nachricht +=  'autocomplete="off" ';
    formulare[i].setAttribute( "autocorrect",     "off"   );
    form_nachricht +=  'autocorrect="off" ';
  }

Und ob man hier den Umweg über setAttribute() gehen muss, bezweifle ich auch. Ich nehme an, dass man stattdessen auch direkt die entsprechende Eigenschaft des DOM-Objekts setzen kann.

Live long and pros healthy,
 Martin

[Linuchs]

Hallo Martin,

Ich nehme an, dass man stattdessen auch direkt die entsprechende Eigenschaft des DOM-Objekts setzen kann.

Das Attribut autocorrect ist ja nicht gesetzt, wie sollte ich dessen Eigenschaft ändern?

[Rolf B]

Hallo Linuchs,

das ist jetzt eine Feinheit von HTML und JavaScript, bei der man genau aufpassen muss.

Im HTML gibt es Attribute. In <input type="text" autocorrect="off"> steht das autocorrect-Attribut.

In JavaScript kannst Du diese Attribute generisch mit getAttribute / setAttribute ansprechen.

Ein HTML Element wird aber für JavaScript nicht generisch durch ein Objekt mit der HTMLElement-Schnittstelle repräsentiert, sondern durch eine davon abgeleitete, speziellere Schnittstelle. Dieses Schnittstelle verleiht dem JavaScript-Objekt Methoden und Eigenschaften. Das input type="text" Element wird durch ein JavaScript-Objekt mit der Schnittstelle HTMLInputElement repräsentiert.

Nun ist es so, dass diejenigen HTML-Attribute, die laut Spezifikation zu einem bestimten Element gehören, sich auf JavaScript-Seite fast immer als Objekt-Eigenschaften wiederfinden. D.h. ob ich nun elem.autofocus=true oder elem.setAttribute("autofocus", "true") schreibe, läuft auf's gleiche hinaus, weil die autofocus-Eigenschaft genau das gleiche tut: sie ändert das Attribut.

Problematisch wird es, wenn Du autocorrect verwendest. Das autocorrect-Attribut ist eine Safari-Erweiterung. Heißt: Du kannst es nach Lust und Laune mit deinem HTML Editor setzen, und Du kannst es auch mit getAttribute/setAttribute lesen und ändern. Aber NUR in einem Safari-Browser kannst Du erwarten, den Wert des autocorrect Attributs in der autocorrect-Eigenschaft wiederzufinden. Wenn überhaupt. Es kann genauso gut sein, dass Safari dieses Attribut nicht mit einer Eigenschaft unterstützt; das musst Du im Safari testen.

Und wenn Du die Eigenschaft im Script verwendest, wirst Du höchstens in einem Safari true oder false vorfinden. Vielleicht auch "on" und "off" - keine Ahnung. Ich habe keinen Mac und kein iPhone, und ich weiß auch nicht, ob sich Mac-Safari und iSafari gleich verhalten. Die Spezifikation des DOM schreibt nichts dazu. Kann sie nicht, es ist ja Safari-spezifisch.

Für solche browserspezifischen Attribute ist es besser, wenn man getAttribute und setAttribute verwendet. JavaScript-Eigenschaften verwendet man besser nur für solche Attribute, für die es spezifizierte Eigenschaften gibt.

Rolf