@supports für Pseudoklassen?

[marctrix]

Hej alle,

gibt es eine Möglichkeit festzustellen ob ein Browser so etwas wie :focus-within unterstützt? @supports geht meines Wissens nach nur bei Eigenschaften/Werten?!?

Marc

[Felix Riesterer]

Lieber marctrix,

gibt es eine Möglichkeit festzustellen ob ein Browser so etwas wie :focus-within unterstützt?

caniuse.com

@supports geht meines Wissens nach nur bei Eigenschaften/Werten?!?

Aha... Du brauchst es also "programmatisch"? Offensichtlich ist @supports für Selektoren ungeeignet.

Liebe Grüße,

Felix Riesterer.

[marctrix]

Hej Felix,

gibt es eine Möglichkeit festzustellen ob ein Browser so etwas wie :focus-within unterstützt?

caniuse.com

@supports geht meines Wissens nach nur bei Eigenschaften/Werten?!?

Aha... Du brauchst es also "programmatisch"? Offensichtlich ist @supports für Selektoren ungeeignet.

Ja, das ist das Problem - gibt es da was von modernizr, fällt mir gerade so ganz spontan ein? - Ok, kann es nachschauen, aber wenn es jemand aus dem Kopf weiß, kommt das meiner Faulheit und meiner Diskussionsfreudigkeit sehr entgegen.

Im Gegenzug habe ich den Wiki-Artikel angepasst. 😉

So weit ich weiß, kann man mit @supports nur Eigenschaften und Werte überprüfen. Diese nennt man übrigens nicht Deklarationen…

Marc

[Felix Riesterer]

Lieber marctrix,

Im Gegenzug habe ich den Wiki-Artikel angepasst. 😉

+1

Liebe Grüße,

Felix Riesterer.

[Kasimir]

Hallo!

gibt es eine Möglichkeit festzustellen ob ein Browser so etwas wie :focus-within unterstützt?

Mit @supports wie gesagt nicht.

Wieso willst du den Support denn feststellen? Also was würdest du tun, wenn du es könntest? Die Focus-Styles auf das fokussierte Element anwenden anstatt auf das Elternelement?

Vielleicht kann man mit JavaScript etwas basteln: Ein unsichtbares Element programmatisch fokussieren und die computed styles des Elternelements mit :focus-within auslesen. Unschön, aber müsste gehen.

Das focusin-Event steigt auf (Bubbling) und kann bei einem Elternelement (z.B. label, fieldset oder gleich body/html) verarbeitet werden. Dem gewünschten Elternelement kann dann eine Klasse verpasst werden. Das Pendant ist focusout.

Kasimir

[marctrix]

Hej Kasimir,

gibt es eine Möglichkeit festzustellen ob ein Browser so etwas wie :focus-within unterstützt?

Mit @supports wie gesagt nicht.

Wieso willst du den Support denn feststellen? Also was würdest du tun, wenn du es könntest? Die Focus-Styles auf das fokussierte Element anwenden anstatt auf das Elternelement?

Nein, ich möchte eine einfache Darstellung für Browser die das nicht unterstützen, für Browser die focus-within können, würde ich gerne eine hübschere Variante anbieten.

Wenn ein Browser das nicht kann, muss er daher alles ignorieren, was an Gestaltung für Browser mit focus-within nötig ist.

Konkret möchte ich für Browser ohne focus-within ein Eingabefeld mit einem Label darüber haben wollen. Für Browser mit focus-within das Label im Eingabefeld anzeigen (ist unter Designern derzeit der Renner).

Mit JavaScript hat das @Gunnar Bittersmann bereits umgesetzt. Das Projekt hat derzeit noch kein eigenes JavaScript und ich würde gerne auf den zusätzlichen http-Request verzichten. Auch finde ich es unschön, dass die JS-Unterstützung wohl für immer drin bleiben würde, wenn es erstmal drin ist. Also auch dann, wenn alle relevanten Browser die Pseudoklasse längst unterstützen.

Marc

[marctrix]

Hej zusammen,

gibt es eine Möglichkeit festzustellen ob ein Browser so etwas wie :focus-within unterstützt? @supports geht meines Wissens nach nur bei Eigenschaften/Werten?!?

Problem: für Browser die :focus-within verstehen, sollen einige Angaben gemacht werden, die Browser ohne :focus-within ignorieren.

Die Lösung ist simpel: was nur von Browsern mit :focus-within-Unterstützung angewendet werden soll, wenn :focus-within nicht zutrifft in einen negation-Selektor notieren, also so:

*:not(:focus-within) {
  foo: bar;
}

Das klappt natürlich bei allen Selektoren, die noch nicht von allen Browsern unterstützt werden.

Vorteil: progressive enhancement (wobei es sich eigentlich um graceful degradation handelt).

Beispiel zum Spielen bei Codepen (ein Fork von Gunnar Bittersmann, der diese Lösung für alle Browser mit JavaScript umgesetzt hat): http://codepen.io/haunschild/pen/NjEZYm

@Gunnar Bittersmann: die Formularfelder habe ich untereinander gesetzt, was aus BF-Gründen empfohlen wird - das Beispiel hat aber noch ein BF-Problem: die hübsche Animation einhergehend mit Schriftverkleinerung dürfte die Nutzung für Menschen mit Fehlsichtigkeiten und kognitiven Einschränkungen erschweren. - Und mein vorgegebenes Layout, um das es im konkreten Fall geht, sieht auch nebeneinaderstehende Formularfelder vor. Dort werde ich zur Positionierung aber flexbox verwenden…

Beitrag auf haunschild.de folgt

Marc

[Matthias Apsel]

Hallo marctrix,

Die Lösung ist simpel: was nur von Browsern mit :focus-within-Unterstützung angewendet werden soll, wenn :focus-within nicht zutrifft in einen negation-Selektor notieren, also so:

*:not(:focus-within) {
  foo: bar;
}

Aber wirklich. Und Browser, die :focus-within aber nicht :not() unterstützen, sollte es nicht geben.

Bis demnächst
Matthias

[marctrix]

Hej zusammen,

Beitrag auf http://haunschild.de/ folgt

Hier ist er: CSS: Pseudoklasse focus-within sinnvoll nutzen

Marc

[Mitleser]

Hier ist er: CSS: Pseudoklasse focus-within sinnvoll nutzen

Hübsch. Nur... wenn ich etwas eingegeben habe und das Feld wieder verlasse...

[Christian Kruse]

Hallo marctrix,

Beitrag auf http://haunschild.de/ folgt

Hier ist er: CSS: Pseudoklasse focus-within sinnvoll nutzen

Da gibts aber irgendwie noch ein paar Probleme…

Safari:

Chrome:

Firefox:

LG,
CK

[marctrix]

Hej Christian und Mitleser,

@Christian Kruse und

Beitrag auf http://haunschild.de/ folgt

Hier ist er: CSS: Pseudoklasse focus-within sinnvoll nutzen

Da gibts aber irgendwie noch ein paar Probleme…

Ja, aber man kann ja nicht an alles denken!

Nein im Ernst: das ist ja übel, dass ich da keinen Text eingegeben habe! Autsch!!!

Habe ich jetzt alles umsonst geschrieben? - Ich gehe erst noch mal zurück in mein stilles Kämmerlein…

Marc

[Matthias Apsel]

Hallo marctrix,

Nein im Ernst: das ist ja übel, dass ich da keinen Text eingegeben habe! Autsch!!!

Habe ich jetzt alles umsonst geschrieben? - Ich gehe erst noch mal zurück in mein stilles Kämmerlein…

Vielleicht kann man die Pseudoklassen :valid und :invalid zur Unterstützung heranziehen.

Bis demnächst
Matthias

[marctrix]

Hej Matthias,

Nein im Ernst: das ist ja übel, dass ich da keinen Text eingegeben habe! Autsch!!!

Habe ich jetzt alles umsonst geschrieben? - Ich gehe erst noch mal zurück in mein stilles Kämmerlein…

Vielleicht kann man die Pseudoklassen :valid und :invalid zur Unterstützung heranziehen.

Danke für die Idee, aber ich denke das wird nicht klappen. Mein erster Reflex war :not(:empty) - aber all das bezieht sich ja auf das Fromularfeld und an das davor stehende label komme ich damit nicht dran…

Wenn du aber was im Kopf hattest, brauche ich noch Hilfe: ich bin von alleine nicht drauf gekommen…

Marc

[Matthias Apsel]

Hallo marctrix,

<div class="field-container">
    <input id="foo" pattern=".+">
    <label for="foo">
        Beschriftung für foo
    </label>
</div>

.field-container:focus-within > :invalid + label { top: -1em }

ungetestet

Bis demnächst
Matthias

[marctrix]

Hej Matthias,

Wenn das Label hinter dem Feld steht, kann ich mir den ganzen Quatsch mit Focus-within sowieso sparen… 😉

Ist für blinde aber ziemlich doof, wenn sie nach dem Ausfüllen eines Feldes erfahren was da rein gehört hätte… 😉

Marc

[Matthias Apsel]

Hallo marctrix,

Mein erster Reflex war :not(:empty) - aber all das bezieht sich ja auf das Fromularfeld und an das davor stehende label komme ich damit nicht dran…

Das input-Element ist immer leer, unabhängig von Inhalt seines value-Attributes.

Bis demnächst
Matthias

[marctrix]

Hej Matthias,

Mein erster Reflex war :not(:empty) - aber all das bezieht sich ja auf das Fromularfeld und an das davor stehende label komme ich damit nicht dran…

Das input-Element ist immer leer, unabhängig von Inhalt seines value-Attributes.

Ja hatte ich vergessen zu erwähnen, das war mir nach dem ersten Reflex auch eingefallen.

Marc

[Auge]

Hallo

CSS: Pseudoklasse focus-within sinnvoll nutzen

Dein Blogbeitrag enthält leider ein paar Fehler und Ungereimtheiten.

„Die Schrift soll aus dem Feld verschwinden, wenn das Feld ausgefüllt wird, um dem getippten Text nicht im Weg zu stehen.

Lässt sich leicht umsetzen mit dem placeholder-Attribut, was aber aus Gründen der Nutzerfreundlichkeit, Zugänglichkeit und Semantik tunlichst zu unterlassen ist.

Formular-Felder müssen immer mit label beschriftet werden, placeholder ist für Beispiele und Ausfüllhilfen gedacht. Seine Verwendung ist optional und kann eine ordentliche Beschriftung nicht ersetzen!“

Der zweite Satz könnte ein „Das“ an seinem Anfang vertragen („Das lässt sich leicht …“). Zudem impliziert der Satz, dass placeholder nicht benutzt werden soll. Der darauffolgende Satz wiederum sagt, dass ein Label vorhanden sein muss und placeholder optional verwendet werden können. Wie denn nun? Können placeholder zusätzlich zum label verwendet werden oder sind sie „tunlichst“ zu vermeiden? Die Formulierung im zweiten Absatz sollte mMn klarer darauf abstellen, dass placeholder nicht statt label verwendet werden sollen.

„Das heißt, dass Browser, die die Beschriftung nicht wieder aus dem fokussierten Feld schieben können, die Beschriftung gar nciht erst im Feld zeigen dürfen, sonst würden Beschriftung und befüllter Text aufeinander ligen und keines von beiden wäre lesbar.“

Rechtschreibung, Hervorhebung von mir.

Ganz generell erschließt sich mir dein Beispiel aber nicht. Die auch und gerade hier imemr wieder ins feld geführte nicht funktionierende Bedienbarkeit des Formulars bei Verwendung von placeholder statt label ist ja nicht das einzige Argument gegen einen solchen Aufbau. Ein zweiter Punkt ist das Verschwinden der Beschriftung des Formularfeldes, sobald begonnen wird, dieses auszufüllen. In deinem Beispiel ist es sogar noch schlimmer, da die Beschriftung bereits verschwindet, wenn das Feld nur den Focus erhält.

Meiner Meinung nach ist das ein überaus schlecht gewähltes Beispiel.

Tschö, Auge

[marctrix]

Hej Auge,

das ist aber nett, dass du dir den Beitrag nicht nur durchgelesen hast, sondern auch so eine ausführliche Rückmeldung gibst. Danke dafür!

„Die Schrift soll aus dem Feld verschwinden, wenn das Feld ausgefüllt wird, um dem getippten Text nicht im Weg zu stehen.

Lässt sich leicht umsetzen mit dem placeholder-Attribut, was aber aus Gründen der Nutzerfreundlichkeit, Zugänglichkeit und Semantik tunlichst zu unterlassen ist.

Formular-Felder müssen immer mit label beschriftet werden, placeholder ist für Beispiele und Ausfüllhilfen gedacht. Seine Verwendung ist optional und kann eine ordentliche Beschriftung nicht ersetzen!“

Die Formulierung im zweiten Absatz sollte mMn klarer darauf abstellen, dass placeholder nicht statt label verwendet werden sollen.

Auf jeden Fall! - Ich hoffe die neue Formulierung ist deutlicher.

Rechtschreibung

Korrigiert.

Ganz generell erschließt sich mir dein Beispiel aber nicht. Die auch und gerade hier imemr wieder ins feld geführte nicht funktionierende Bedienbarkeit des Formulars bei Verwendung von placeholder statt label ist ja nicht das einzige Argument gegen einen solchen Aufbau. Ein zweiter Punkt ist das Verschwinden der Beschriftung des Formularfeldes, sobald begonnen wird, dieses auszufüllen. In deinem Beispiel ist es sogar noch schlimmer, da die Beschriftung bereits verschwindet, wenn das Feld nur den Focus erhält.

Wieso, sie verschwindet ja nicht - ich bin damit aber auch nicht ganz glücklich. Es ist ein Kompromiss aus häufig an mich herangetragenem Design-Wunsch und der besten Zugänglichkeit. Ich würde die Schrift beim Verschieben nach oben noch etwas größer, schwarz und vielleicht fett machen - muss man noch ein wenig experimentieren. Zoomen verträgt die Lösung übrigens gut.

Meiner Meinung nach ist das ein überaus schlecht gewähltes Beispiel.

Wenn es - so wie jetzt - nicht funktioniert, hast du natürlich recht. Aber das entscheidende Problem ist derzeit, dass sich eingegebener Text und Beschriftung überlagern, wenn das befüllte Feld verlassen wird.

Da mir dazu nichts einzufallen scheint, werde ich den Beitrag vermutlich komplett umschreiben und den Codepen umbauen, so dass es nur noch um graceful degradation beim Einsatz von Pseudoklassen geht.

Oder ich lösche ihn ganz. Mal sehen…

Schade, wenn man so nah dran war…

Marc

[Mitleser]

Oder ich lösche ihn ganz. Mal sehen… Schade, wenn man so nah dran war…

Mir gefällt der Ansatz! Was spricht dagegen, das Ganze um ein klein wenig JS zu erweitern, was z.B. generell auf "input" für inputs horcht und denen dann je nach Zustand eine Klasse zu verpassen?

[Auge]

Hallo

das ist aber nett, dass du dir den Beitrag nicht nur durchgelesen hast, sondern auch so eine ausführliche Rückmeldung gibst. Danke dafür!

Bitte, bitte.

Die Formulierung im zweiten Absatz sollte mMn klarer darauf abstellen, dass placeholder nicht statt label verwendet werden sollen.

Auf jeden Fall! - Ich hoffe die neue Formulierung ist deutlicher.

Man könnte das bestimmt auch noch klarer formulieren, aber mir fällt auch nichts Sinnvolles ein, das nicht umständlicher formuliert und damit schlecht lesbar wäre. Zumindest ist für mich die Widersprüchlichkeit des zweiten und dritten Absatzes weg.

… das Verschwinden der Beschriftung des Formularfeldes, sobald begonnen wird, dieses auszufüllen. In deinem Beispiel ist es sogar noch schlimmer, da die Beschriftung bereits verschwindet, wenn das Feld nur den Focus erhält.

Wieso, sie verschwindet ja nicht …

Das kommt davon, wenn man das Beispiel nicht aufruft und sich stattdessen auf Textteile verlässt. 😀 Jetzt sehe ich es auch. Wie es zu meiner Interpretation kam:

Ganz unten …

„Ein hübscheres Beispiel habe ich auf Codepen bereit gestellt: label like placeholder (without JS)“

… (quasi) ganz oben …

„Die Schrift soll aus dem Feld verschwinden, wenn das Feld ausgefüllt wird, um dem getippten Text nicht im Weg zu stehen.“

Hervorhebung von mir.

Der Link zum Beispiel im ersten Zitat ist mir durchgeflutscht. Gedanklich festgehalten habe ich mich stattdessen am zweiten von mir zitierten Satz.

Es ist ein Kompromiss aus häufig an mich herangetragenem Design-Wunsch und der besten Zugänglichkeit.

Hmm, ich sehe ja nun, dass der Text nicht verschwindet. Das ist zumindest um Längen besser als der Mist den Wordpress standardmäßig für Kommentare anbietet (Label in der linken oberen Ecke des Eingabefelds, verschwindet bei Fokussierung des Feldes). Mir gefällts allerdings nicht.

Ich würde die Schrift beim Verschieben nach oben noch etwas größer, schwarz und vielleicht fett machen - muss man noch ein wenig experimentieren.

Ja, ein wenig größer könnte der Text schon bleiben.

das entscheidende Problem ist derzeit, dass sich eingegebener Text und Beschriftung überlagern, wenn das befüllte Feld verlassen wird.

Sollte sich das nicht mit :not(:focus-within) auch wieder zurückstellen lassen?

… komplett umschreiben … Oder ich lösche ihn ganz.

Schade, wenn man so nah dran war…

Ja, das wäre schade, sowohl um die Idee an sich als auch um die Mühe.

Tschö, Auge

[marctrix]

Hej Auge,

das ist aber nett, dass du dir den Beitrag nicht nur durchgelesen hast, sondern auch so eine ausführliche Rückmeldung gibst. Danke dafür!

Bitte, bitte.

Das bedeutet mir sehr viel, denn da ich ja weiß, was ich meine. Daher sehe ich solche Fehler selber nur, nachdem ich den Text eine ganze Weile nciht mehr angeschaut habe…

„Die Schrift soll aus dem Feld verschwinden, wenn das Feld ausgefüllt wird, um dem getippten Text nicht im Weg zu stehen.“

Hervorhebung von mir.

Verstehe, mache aus „verschwinden“ „verschoben werden“.

Es ist ein Kompromiss aus häufig an mich herangetragenem Design-Wunsch und der besten Zugänglichkeit.

Hmm, ich sehe ja nun, dass der Text nicht verschwindet. Das ist zumindest um Längen besser als der Mist den Wordpress standardmäßig für Kommentare anbietet (Label in der linken oberen Ecke des Eingabefelds, verschwindet bei Fokussierung des Feldes). Mir gefällts allerdings nicht.

Ist ein netter Kunde und wir haben für den konkreten Fall eine andere Lösung gefunden, die ich auch für das focus-within-Beispiel nehmen werde: Das Label steht die ganze auf der oberen Kante des Formular-Feldes und wird bei Fokussierung geändert (werde im Beispiel einfach die Hintergrund-Farbe ändern - ist eine nette Hervorhebung für ein fokussiertes Feld mMn)).

das entscheidende Problem ist derzeit, dass sich eingegebener Text und Beschriftung überlagern, wenn das befüllte Feld verlassen wird.

Sollte sich das nicht mit :not(:focus-within) auch wieder zurückstellen lassen?

Nein, weil das würde ja auch den ursprungs-Zustand betreffen, also wäre der Text immer oben.

… komplett umschreiben … Oder ich lösche ihn ganz.

Schade, wenn man so nah dran war…

Ja, das wäre schade, sowohl um die Idee an sich als auch um die Mühe.

War halt eine Sch…-Idee 😉

Nein, wenn es prinzipiell geklappt hätte, wäre ich schon froh, denn so was ist im Moment beliebt. Sehe das (leider) oft in letzter Zeit und nicht jeder Kunde lässt sich seinen ursprünglichen Design-Wunsch ausreden — schon gar nicht „nur“ wegen Zugänglichkeit. Dann muss man halt gute Kompromisse finden - aber oft lässt man mich an so was auch gar nciht erst ran. Dann ist das mit placeholder gemacht, sieht aus wie gewünscht und man bekommt gesagt: „Warum wollen Sie das denn ändern, funktioniert doch!“ - Kennt sicher jeder…

Wenn das HTML nicht in meiner Verantwqortung ist, kann ich ja auch nur um Änderungen bitten, gerade wenn es CMS-generiert oder aus einer PHP-Anwendung ist.

Ich finde auch, man muss nicht immer so ganz streng sein: wenn ich beispielsweise ein LogIn-Formular habe, weiß ich eigentlich schon ohne Beschriftung, dass in das erste Feld der Benutzername kommt, ins zweite das Passwort.

Ähnliches gilt für ein einzelnes Feld mit einem Lupen-Symbol für sehende und einem (versteckten) Label für Blinde — man weiß, dass das die Freitext-Suche ist.

Marc

[Auge]

Hallo

„Die Schrift soll aus dem Feld verschwinden, wenn das Feld ausgefüllt wird, um dem getippten Text nicht im Weg zu stehen.“

Verstehe, mache aus „verschwinden“ „verschoben werden“.

👍

Ist ein netter Kunde und wir haben für den konkreten Fall eine andere Lösung gefunden, die ich auch für das focus-within-Beispiel nehmen werde: Das Label steht die ganze auf der oberen Kante des Formular-Feldes und wird bei Fokussierung geändert (werde im Beispiel einfach die Hintergrund-Farbe ändern).

Diese Idee gefällt mir besser. Mir ist in deinem Codepen auch erstmals bewusst die Veränderung des Borders eines Eingabefelds bei dessen Fokussierung ins Auge gesprungen. Das machen so viele Programme von sich aus und doch nehme zumindest ich es so überhaupt nicht wahr.

Ich bin zwar gegen übermäßiges Herumgefummle an den betriebssystemeigenen Formularelementen, aber das aktuell fokussierte Formularfeld besonders™️ hervorzuheben, halte auch ich für sinnvoll.

… wäre schade, sowohl um die Idee an sich als auch um die Mühe.

War halt eine Sch…-Idee 😉

Nicht, wenn sie dich weiter gebracht hat. Manchmal braucht es halt mehrere Anläufe, bis etwas brauchbares dabei herauskommt. Das ging und geht weltweit berühmten Erfindern auch nicht anders.

Tschö, Auge

[marctrix]

Hej Auge,

Ist ein netter Kunde und wir haben für den konkreten Fall eine andere Lösung gefunden, die ich auch für das focus-within-Beispiel nehmen werde: Das Label steht die ganze auf der oberen Kante des Formular-Feldes und wird bei Fokussierung geändert (werde im Beispiel einfach die Hintergrund-Farbe ändern).

Diese Idee gefällt mir besser. Mir ist in deinem Codepen auch erstmals bewusst die Veränderung des Borders eines Eingabefelds bei dessen Fokussierung ins Auge gesprungen. Das machen so viele Programme von sich aus und doch nehme zumindest ich es so überhaupt nicht wahr.

Viele Usability-Maßnahmen funktionieren ohnehin unbewusst. Kaum ein Nutzer wäre in der Lage zu sagen, dass er die Freitext-Suche oben rechts erwartet. Sagt man aber Nutzern, sie sollen einen Artikel zu einem bestimmten Thema auf einer Webseite suchen, gehen die Blicke alle nach oben rechts 😉

Ich will mich aber nciht mit fremden Federn schmücken, daher noch mal der Hinweis: die Gestaltung habe ich von dem geforkten Beispiel eines gewissen @Gunnar Bittersmann übernommen. 😉

Das neue Beispiel ist dann aber so weit weg von der eigentlichen Idee, das ich das komplett neu bauen werde - da werden Rahmen-Farbe und Hinterlegung des labels dann übrigens aufeinander abgestimmt sein, so dass Beschriftung und Feld eine erkennbare Einheit bilden.

Ich bin zwar gegen übermäßiges Herumgefummle an den betriebssystemeigenen Formularelementen, aber das aktuell fokussierte Formularfeld besonders™️ hervorzuheben, halte auch ich für sinnvoll.

Ja, gebe dir da teilweise recht. Es gibt für beides gute Argumente. Problematisch wird es für mich, wenn ich jetzt gesagt kriege: Sieht gut aus Marc, mach das jetzt mal mit einem Fileupload 😐

War halt eine Sch…-Idee 😉

Nicht, wenn sie dich weiter gebracht hat. Manchmal braucht es halt mehrere Anläufe, bis etwas brauchbares dabei herauskommt. Das ging und geht weltweit berühmten Erfindern auch nicht anders.

Auf jeden Fall: nicht alles, was umsonst ist, ist vergeblich — und umgekehrt!

Marc