nicht angemeldet
Camping_RIDER
Rolf B
Gunnar Bittersmann
Rolf B
Rolf B
Camping_RIDER
Rolf B
Camping_RIDER
MudGuard
Camping_RIDER
Rolf B
Rolf B
Aloha ;)
mir ist eben ein Verhalten bei der Verwendung von DataList aufgefallen, das vielleicht erwähnenswert ist.
Folgendes Minimalbeispiel funktioniert nämlich nicht wie von mir intendiert:
<input type="text" list="myList" />
<datalist id="myList">
<option>1 Leerzeichen</option>
<option>2 Leerzeichen</option>
<option>3 Leerzeichen</option>
</datalist>
Sowohl Chrome als auch Firefox "optimieren die Leerzeichen weg" - das entspricht ja auch dem Standard-Verhalten, wenn man mehr als ein Leerzeichen hintereinander irgendwo im HTML-Code stehen hat.
Es führt nur leider in diesem Fall dazu, dass die String-Werte, mit denen ich im späteren Programm-Verlauf wieder vergleichen muss, dann eben nicht genau übereinstimmen. Klar wärs cool, wenn in meinen Werten gar keine (sinnlosen) doppelten Leerzeichen vorkommen - aber darüber habe ich leider keine Kontrolle.
Folgendes führt allerdings zum Ziel:
<input type="text" list="myList" />
<datalist id="myList">
<option value="1 Leerzeichen"></option>
<option value="2 Leerzeichen"></option>
<option value="3 Leerzeichen"></option>
</datalist>
Weil die Werte hier in "" eingeschlossen sind werden sie genau so übernommen wie sie sind - und ich kann den eingetragenen String dann nachher auch problemlos wieder zu Vergleichen heranziehen.
Nun meine Frage: Übersehe ich irgendwelche Nachteile am "Weg Nr. 2"?
Sollte man vielleicht gar generell empfehlen, die Werte für Options immer ins value-Feld zu packen (und nur im Ausnahmefall zusätzlich ins innerHTML)?
Unser Wiki legt aktuell nahe, dass es andersrum sei - dass man den Wert möglichst ins innerHTML schreiben soll und nur bei abweichenden values auch tatsächlich das value-Attribut benutzt. Das ist das Gegenteil von dem, was ich jetzt spontan - dem oben genannten usecase nach, außer ich übersehe was - für empfehlenswert halte.
Bin mal gespannt auf ein paar Meinungen/Erfahrungen/Erkenntnisse eurerseits!
Grüße,
RIDER
Hallo Camping_RIDER,
Unser Wiki legt aktuell nahe, dass es andersrum sei - dass man den Wert möglichst ins innerHTML schreiben soll und nur bei abweichenden values auch tatsächlich das value-Attribut benutzt.
Unser Wiki tut nichts dergleichen. Solange man an diese oder jene richtige Stelle schaut.
Die option-Liste eines select MUSS gefüllte Inhalte haben, weil da die values nicht angezeigt werden.
Eine datalist zeigt (in Chrome) primär die Values an und die Elementinhalte als Sekundärinformation. Zum Suchen werden value und Text verwendet.
Ein todo könnte sein, bei der Erklärung von <option> darauf hinzuweisen, dass select/option und datalist/option nicht identisch sind.
Rolf
@@Rolf B
Unser Wiki tut nichts dergleichen. Solange man an diese oder jene richtige Stelle schaut.
Die option-Liste eines select MUSS gefüllte Inhalte haben, weil da die values nicht angezeigt werden.
Wenn man an die einzig richtige Stelle schaut (und die ist nicht das Wiki!), sieht man schnell, dass das nicht stimmt.
… werden value und Text verwendet.
Wobei value Vorrang hat, wenn beides verwendet wird.
🖖 Живіть довго і процвітайте
Hallo Gunnar,
value und label haben beide Vorrang, wenn sie verwendet werden. Der Textinhalt des option-Elements ist ein Default für beide.
Als ich den von dir zitierten Satz schrub, hatte ich tatsächlich noch keine Ahnung vom label-Attribut des option-Elements und habe immer gedacht, dass der Textinhalt dafür da sei.
Rolf
@@Rolf B
Als ich den von dir zitierten Satz schrub, hatte ich tatsächlich noch keine Ahnung vom label-Attribut des option-Elements und habe immer gedacht, dass der Textinhalt dafür da sei.
Das ist er ja auch. Im Normalfall wird man Textinhalt verwenden anstatt value und den Wert nochmal im label-Attribut duplizieren. Außer man will was anderes anzeigen als das, was man als Wert aus dem Formular haben will.
Oder halt so ein Fall wie @Camping_RIDER’s. (Wobei man da kein label braucht.) Und nein, ich sehe keinen Grund, das nicht so zu machen.
🖖 Живіть довго і процвітайте
Aloha ;)
Oder halt so ein Fall wie @Camping_RIDER’s. (Wobei man da kein
labelbraucht.) Und nein, ich sehe keinen Grund, das nicht so zu machen.
Super - danke für die Einschätzung!
Im Normalfall wird man Textinhalt verwenden anstatt
valueund den Wert nochmal imlabel-Attribut duplizieren. Außer man will was anderes anzeigen als das, was man als Wert aus dem Formular haben will.
Ja, so war ja auch mein Vorgehen (und dann bin ich in diese schwer erkennbare Falle mit den Leerzeichen getappt - habe zuerst ewig den Fehler in meinem PHP-Code gesucht bis ich erkannt habe, dass die Option-Elemente ihren value nicht 1:1 aus dem Textinhalt übernehmen...).
Was mir aus dem Stegreif nicht klar war ist, dass datalist und select mit ihren options unterschiedlich umgehen - weil select bei fehlendem label und fehlendem Textinhalt nichts anzeigt (im Gegensatz zu datalist, wo value herangezogen wird) kann man also tatsächlich nicht einfach "umdenken" und das in Zukunft immer über den value machen, sondern muss sich diese Ausnahme also auch noch einprägen 😂
Grüße,
RIDER
@@Camping_RIDER
Was mir aus dem Stegreif nicht klar war ist, dass
datalistundselectmit ihrenoptions unterschiedlich umgehen - weilselectbei fehlendemlabelund fehlendem Textinhalt nichts anzeigt (im Gegensatz zu datalist, wovalueherangezogen wird)
Nö, datalist zeigt bei fehlendem label und fehlendem Textinhalt auch nichts an. 😉
Weil datalist nie was anzeigt (solange man nicht den Default display: none ändert). Du kannst ja auf der Spielwiese mal den Wert auf block ändern – dann bekommst du den Inhalt des datalist-Elements angezeigt.
Was du da beim input-Element als Auswahlliste angezeigt bekommst, ist Magie, aber nicht der Inhalt des datalist-Elements.
🖖 Живіть довго і процвітайте
Aloha ;)
Was mir aus dem Stegreif nicht klar war ist, dass
datalistundselectmit ihrenoptions unterschiedlich umgehen - weilselectbei fehlendemlabelund fehlendem Textinhalt nichts anzeigt (im Gegensatz zu datalist, wovalueherangezogen wird)Nö,
datalistzeigt bei fehlendemlabelund fehlendem Textinhalt auch nichts an. 😉Weil
datalistnie was anzeigt (solange man nicht den Defaultdisplay: noneändert). Du kannst ja auf der Spielwiese mal den Wert aufblockändern – dann bekommst du den Inhalt desdatalist-Elements angezeigt.
Stimmt. Aber genau genommen nur Wortklauberei 😉
Was du da beim
input-Element als Auswahlliste angezeigt bekommst, ist Magie, aber nicht der Inhalt desdatalist-Elements.
Right. Aber die Spielregeln für diese Magie wären nice to know 😀
Grüße,
RIDER
Hallo Gunnar,
so, habe das option-Element nochmal erweitert.
@Matthias Scharwies: Ich habe die Html-El-Referenz Vorlage um ein Feld "Zusatztext" erweitert. Es ist doch oft so, dass man eine Einleitung schreibt, ein Beispiel macht und dann noch ein paar Worte verlieren loswerden will, die aber als {{BeispielText|...}} nicht so recht passen.
Da das Beispiel Pflicht ist, kann man diese beiden Parameter auch nicht einfach weglassen und das Pflichtbeispiel als {{Beispiel...}} in die Beschreibung aufnehmen, um nach dem Beispiel einfach weiterzuschreiben.
Also habe ich jetzt einen Vorlagenparameter Zusatztext hinzugefügt, mit dem man hinter dem Pflichtbeispiel noch Text bringen kann.
Rolf
Aloha ;)
so, habe das option-Element nochmal erweitert.
Super! Danke dir für die Klarstellung in der Unterscheidung datalist-Option und select-Option!
Wäre noch irgendwo ein Hinweis auf das, was die Spec mit "not inter-element whitespace" meint, gut? Denn das war ja, was meinem Usecase das Genick brach: dass der Textinhalt eben nicht 1:1 als Value-Default herhält, sondern erst nach Zeichenersetzungen.
Dass
Grüße,
RIDER
Hallo Camping_RIDER,
den Begriff des inter-element Whitespace habe ich ja gar nicht im Wiki verwendet, sondern einfach nur "Leerraum". Das mag vielleicht nicht so präzise sein, aber dafür sollte Willi Webschrauber (nicht der mit der Rakete dran) damit mehr anfangen können.
Wer es bis zu Spec schafft, findet dort auch die Begriffsdefinition dazu.
Rolf
Aloha ;)
Da haben wir jetzt aneinander vorbeigeschrieben 😂
den Begriff des inter-element Whitespace habe ich ja gar nicht im Wiki verwendet, sondern einfach nur "Leerraum".
Ja, genau - mir fehlt sowas in die Richtung hier und da.
Eine Art Warnung könnte ich mir vorstellen:
"Wenn Sie statt der Attribute label und value den Textinhalt angeben, bedenken Sie dabei, dass dabei (wie in jedem HTML-Textinhalt üblich mit Ausnahme von <pre>) vorkommende Leerräume vom Browser ignoriert werden könnten - beispielsweise werden mehrere hintereinander gesetzte Leerzeichen zu einem einzelnen zusammengeführt. Wollen Sie das vermeiden, kommen Sie um eine direkte Angabe von label bzw. value nicht drumherum."
Das mag vielleicht nicht so präzise sein, aber dafür sollte Willi Webschrauber (nicht der mit der Rakete dran) damit mehr anfangen können.
Wer es bis zu Spec schafft, findet dort auch die Begriffsdefinition dazu.
Das ist schon klar, was das Wording angeht.
Mir fehlt nur die Erwähnung auf den beiden Seiten. Wo du "Leerraum" geschrieben hast habe ich auf die Schnelle nicht gefunden.
Grüße,
RIDER
Hi,
"Wenn Sie statt der Attribute label und value den Textinhalt angeben, bedenken Sie dabei, dass dabei (wie in jedem HTML-Textinhalt üblich mit Ausnahme von
<pre>) vorkommende Leerräume vom Browser ignoriert werden könnten - beispielsweise werden mehrere hintereinander gesetzte Leerzeichen zu einem einzelnen zusammengeführt. Wollen Sie das vermeiden, kommen Sie um eine direkte Angabe von label bzw. value nicht drumherum."
Spielt da nicht auch noch CSS (white-space:pre und co) mit rein?
cu,
Andreas a/k/a MudGuard
Aloha ;)
Spielt da nicht auch noch CSS (
white-space:preund co) mit rein?
Ich glaube nicht - denn es geht ja nicht (nur) um die Darstellung; der POST-value ist ja auch ohne Leerzeichen und das kann ja dann nicht von CSS abhängig sein (CSS wäre ja auch user-veränderbar).
Grüße,
RIDER
Hallo Camping_RIDER,
gerade geschaut - bei select werden auch aus dem label-Attribut die Leerstellen entfernt. Bei datalist nicht.
Aber das mag auch am Brauser hängen.
Rolf
Aloha ;)
gerade geschaut - bei select werden auch aus dem label-Attribut die Leerstellen entfernt. Bei datalist nicht.
Okay - das ist jetzt ein WTF-Moment für mich 😬
Grüße,
RIDER
Aloha ;)
hier isses dabei (im Referenzteil unten) und da war ich noch gar nicht dran…
Ah. Ja, jetzt sehe ich. So wie es jetzt dasteht ist es allerdings leicht missverständlich. Man kann das so verstehen, dass das mit dem Zusammenziehen generell bei value-Angaben passieren kann (der Bezug von "dabei" ist uneindeutig).
Vielleicht kann man den Hinweis auch oben unter "erlaubte Inhalte" unterbringen? Das ist zwar auch nicht ganz korrekt (erlaubt ist ja auch Text mit mehreren Leerzeichen, funktioniert halt nur nicht erwartungsgemäß), ich würde nach einem solchen Hinweis aber eher da suchen als beim value-Attribut (das ich ja im Szenario der Fehlersuche noch gar nicht verwendet hatte).
Grüße,
RIDER