Jquery: Auswahl von Checkboxen bei Change von Checkboxen

[Lukas .]

Hallo,

ich habe eine Checkboxhierarchie, die in etwa so aussieht:

Checkbox Box 1
 -Checkbox 
 -Checkbox 
 -Checkbox 

Checkbox Box 2
 -Checkbox 
 -Checkbox 
 -Checkbox 

Checkbox All

Nun sollen bei Changeevent Box 1 alle Checkboxen unterhab der Box 1 ge- oder unchecked werden und beoi Klick auf Box 2 entsprechend die unterhalb dieser Checkbox gelegenen Boxen. Bei Changeevent der "All-Box" sollen alle vorhandenen Checkboxen ge- oder unchecked werden.

Letzteres gelingt mir auch.

Aber das Ansprechen der einzelnen Boxen gelingt imr nicht. Wie macht man das?

Lukas

[Camping_RIDER]

Aloha ;)

Aber das Ansprechen der einzelnen Boxen gelingt imr nicht. Wie macht man das?

Zum Beispiel, indem du den untergeordneten Checkboxes eine Class mitgibst, anhand der du nur einen Teil selektieren kannst. Oder mittels sinnvollem Markup, z.B. verschachtelten <ul> oder verschachtelten <fieldset>, das dir eine Abbildung der Hierarchie auf das Markup und damit eine hierarchische Selektion ermöglicht (so wie es momentan ist ist das Markup auch nicht sinnvoll - wenn die Checkboxen zu einer Gruppe gehören, dann sollten sie auch durch ein entsprechendes Element gruppiert sein). Ansonsten könntest du auch einen Attributselektor verwenden, der auf den Anfang des name-Attribut reagiert (denn das ist ja schon entsprechend vergeben).

Oder mittels Vanilla-JavaScript, indem du dich Stück für Stück an den Elementen entlanghangelst. Das ist mal wieder eins der vielen Beispiele, in denen die Verwendung von jQuery nicht sinnvoll begründbar ist und den Blick auf die Lösung verstellt. Der Drache beist sich hier in den Schwanz - jQuery mag es ermöglichen, viele Dinge im Einzeiler zu erledigen (was sinnvoll ist), erhöht dabei aber die Komplexität der einzelnen Zeile, was fatal ist, wenn man nicht so recht weiß was man tut.

Grüße,

RIDER

[Felix Riesterer]

Lieber Lukas,

Aber das Ansprechen der einzelnen Boxen gelingt imr nicht. Wie macht man das?

so: Man definiert einen Eventhandler für die jeweilige Checkbox, der das Schlüsselwort this als die angeklickte Checkbox nimmt, und dann alle Kinder des Elternknoten der Checkbox (this.parentNode) daraufhin absucht (jQuery.find()), ob es sich um Checkboxen handelt. Über diese Menge wird dann der von Dir bereits verwendete Algorithmus angewandt.

Liebe Grüße,

Felix Riesterer.

[Felix Riesterer]

Lieber Felix,

so: [...]

da die jeweiligen "Teilmenge-Checkboxen" mittels eines CSS-Selektors ermittelt werden, kann man das auch für die "Mastercheckbox" tun. Damit verkürzt sich die Schreibweise enorm.

Liebe Grüße,

Felix Riesterer.

[Lukas .]

Lieber Felix,

so: [...]

da die jeweiligen "Teilmenge-Checkboxen" mittels eines CSS-Selektors ermittelt werden, kann man das auch für die "Mastercheckbox" tun. Damit verkürzt sich die Schreibweise enorm.

Danke. Und auch Danke für den lustigen Post auf Deinen eigenen Post :-)) Ich muss aber mal nachfragen: .... nein, hat sich geklärt. mit this.parentNode gehst Du erst eine Ebene höher im DOM, um über find() die darin enthaltenen Elemente zu finde, in diesem Fall die input:checkboxen?

Lukas

[Felix Riesterer]

Lieber Lukas,

mit this.parentNode gehst Du erst eine Ebene höher im DOM, um über find() die darin enthaltenen Elemente zu finde, in diesem Fall die input:checkboxen?

exakt. Deshalb "funzt" es ja auch.

Liebe Grüße,

Felix Riesterer.

[Lukas .]

Hi Felix,

mit this.parentNode gehst Du erst eine Ebene höher im DOM, um über find() die darin enthaltenen Elemente zu finde, in diesem Fall die input:checkboxen?

exakt. Deshalb "funzt" es ja auch.

Und wie würde ich auf derselben Ebene die Checkboxen selektieren?

Lukas

[Felix Riesterer]

Lieber Lukas,

Und wie würde ich auf derselben Ebene die Checkboxen selektieren?

das klingt nach kaputter Dokumentstruktur. Zeig doch mal das echte Beispiel, anstatt eines theoretischen!

Liebe Grüße,

Felix Riesterer.

[Lukas .]

das klingt nach kaputter Dokumentstruktur. Zeig doch mal das echte Beispiel, anstatt eines theoretischen!

nein, ich mußte meine Checkbox, die alle anderen Checkboxen setzen soll, außerhalb der fieldsets in ein tbody stecken, daher müßte ich mein find() entweder vom aktuellen Node starten oder falls vom parentNode aus gestartet eine weitere Ebene tiefer suchen.

Lukas

[Camping_RIDER]

Aloha ;)

nein, ich mußte meine Checkbox, die alle anderen Checkboxen setzen soll, außerhalb der fieldsets in ein tbody stecken, daher müßte ich mein find() entweder vom aktuellen Node starten oder falls vom parentNode aus gestartet eine weitere Ebene tiefer suchen.

Und aus welchem Grund nochmal machst du es nicht so, wie ich von Anfang an geschrieben hatte, wenn das Durchhangeln nicht in Frage kommt?

Ich zitiere mal (Nummerierung nachträglich eingefügt):

Zum Beispiel,

1. indem du den untergeordneten Checkboxes eine Class mitgibst, anhand der du nur einen Teil selektieren kannst. Oder
2. mittels sinnvollem Markup, z.B. verschachtelten <ul> oder verschachtelten <fieldset>, das dir eine Abbildung der Hierarchie auf das Markup und damit eine hierarchische Selektion ermöglicht [...].
3. Ansonsten könntest du auch einen Attributselektor verwenden, der auf den Anfang des name-Attribut reagiert (denn das ist ja schon entsprechend vergeben).

Doch nicht nur deshalb, weil ich dir nicht direkt den zugehörigen Code geliefert habe, oder? :P

Grüße,

RIDER

[Lukas .]

Hi CampingRider,

2. mittels sinnvollem Markup, z.B. verschachtelten <ul> oder verschachtelten <fieldset>, das dir eine Abbildung der Hierarchie auf das Markup und damit eine hierarchische Selektion ermöglicht [...].

Naja, ich fand mein Markup ja sinnvoll und nach Felix Post schien die Lösung doch so nah. ;)

3. Ansonsten könntest du auch einen Attributselektor verwenden, der auf den Anfang des name-Attribut reagiert (denn das ist ja schon entsprechend vergeben).

Stimmt schon. Mache ich aber, warum auch immer, relativ ungern. Was ich eher mache, sind so eine Art id-Gruppen, die ich dann in der Selektion wieder auseinanderpflücke. Weißt Du, was ich damit meine?

Doch nicht nur deshalb, weil ich dir nicht direkt den zugehörigen Code geliefert habe, oder? :P

Selbstverständlich nicht! hust ;-)

Gruß, Lukas

[Camping_RIDER]

Aloha ;)

P.S....

nein, ich mußte meine Checkbox, die alle anderen Checkboxen setzen soll, außerhalb der fieldsets in ein tbody stecken

Das klingt auch nach dem, was @Felix Riesterer unter kaputter Dokumentstruktur versteht xD Quod erat demonstrandum?

Grüße,

RIDER

[Felix Riesterer]

Lieber Lukas,

das klingt nach kaputter Dokumentstruktur. [...]

nein,

doch!

ich mußte meine Checkbox, die alle anderen Checkboxen setzen soll, außerhalb der fieldsets in ein tbody stecken, daher müßte ich mein find() entweder vom aktuellen Node starten oder falls vom parentNode aus gestartet eine weitere Ebene tiefer suchen.

Wie bitte?! Was?? Jetzt nochmal zum Mitschreiben: Ich helfe Dir nur, wenn Du echten Code zeigst. Am liebsten per Link auf eine Testseite.

Liebe Grüße,

Felix Riesterer.

[Lukas .]

Hi Felix,

doch!

Echt? Na gut, kann sein ;)

Wie bitte?! Was?? Jetzt nochmal zum Mitschreiben: Ich helfe Dir nur, wenn Du echten Code zeigst. Am liebsten per Link auf eine Testseite.

Vielleicht hab ich mich da ein wenig verwurschtelt. Mir gings nur darum, dass ich die "Check all" Checkbox in der nächsten Tabellenzeile haben wollte.

<table>
<th></th>
<tbody class='all_checkboxes'>
<tr>
<td>
Feld 1
</td>
<td>
<fieldset class='f_all'>
<legend class='c1'>Eintrag: c1</legend>
<input type=checkbox id="c1">
<input type=checkbox name="chboxName[c1][]" value="item1">1
<input type=checkbox name="chboxName[c1][]" value="item2">2
<input type=checkbox name="chboxName[c1][]" value="item3">3
<input type=checkbox name="chboxName[c1][]" value="item4">4
<input type=checkbox name="chboxName[c1][]" value="item5">5
<input type=checkbox name="chboxName[c1][]" value="item6">6
<input type=checkbox name="chboxName[c1][]" value="item7">7
</fieldset>
<fieldset class='f_all'>
<legend class='c2'>Eintrag: c2</legend>
<input type=checkbox id="c2">
<input type=checkbox name="chboxName[c2][]" value="item1">1
<input type=checkbox name="chboxName[c2][]" value="item2">2
<input type=checkbox name="chboxName[c2][]" value="item3">3
<input type=checkbox name="chboxName[c2][]" value="item4">4
<input type=checkbox name="chboxName[c2][]" value="item5">5
<input type=checkbox name="chboxName[c2][]" value="item6">6
<input type=checkbox name="chboxName[c2][]" value="item7">7
<input type=checkbox name="chboxName[c2][]" value="item8">8
</fieldset>
</td>
</tr>
<tr>
<td>
Alle markieren:
</td>
<td>
<input type=checkbox id="all_checkboxes">
</td>
</tr>
</tbody>
</table>

P.S: Da es sich um tabellarische Daten handelt, ist eine Tabelle schon gerechtfertigt.

Lukas

[Lukas .]

Im Prinzip dasselbe

Lukas

[Lukas .]

...irgendwie hab ich noch nicht raus, wie man in so einem fiddle abspeichert..

Der hier sollte passen

Lukas

[Lukas .]

Habs jetzt so gelöst

Danke für die Hilfe.

Lukas

[Gunnar Bittersmann]

@@Felix Riesterer

und dann alle Kinder des Elternknoten der Checkbox (this.parentNode) daraufhin absucht (jQuery.find()), ob es sich um Checkboxen handelt.

Bei $(this.parentNode).find("input:checkbox") sträuben sich meine Nackenhaare.

Entweder man verwendet jQuery – dann konsequent: $(this).parent().find(":checkbox").^[1]

Oder man verwendet jQuery nicht: this.parentNode.querySelectorAll('[type="checkbox"]').

Aber nicht gemischt.

LLAP 🖖

---

1. Da Checkboxen immer vom Elementtypen input sind, ist ein Selektor "input:checkbox" überspezifiziert. Sollte man vermeiden. ↩︎

[Felix Riesterer]

Lieber Gunnar,

Bei $(this.parentNode).find("input:checkbox") sträuben sich meine Nackenhaare.

das dürfen sie. Aber warum wäre das für mich von Bedeutung?

Entweder man verwendet jQuery – dann konsequent: $(this).parent().find(":checkbox").

Warum sollte ich extra eine Methode für etwas nutzen, wenn ich durch die Punkt-Notation das gewünschte Objekt direkt adressieren kann? Das klingt nach "aus Prinzip umständlich"!

Da Checkboxen immer vom Elementtypen input sind, ist ein Selektor "input:checkbox" überspezifiziert. Sollte man vermeiden.

Du meinst :checkbox anstatt input:checkbox? Darüber kann man reden.

Oder man verwendet jQuery nicht: this.parentNode.querySelectorAll('[type="checkbox"]').

Das geht in allen UA, die diese Methode anbieten. Das Framework bietet mir die Sicherheit, dass ich find() auf jeden Fall benutzen kann.

Aber nicht gemischt.

Wie Du meinst.

Liebe Grüße,

Felix Riesterer.

[Gunnar Bittersmann]

@@Felix Riesterer

Entweder man verwendet jQuery – dann konsequent: $(this).parent().find(":checkbox").

Warum sollte ich extra eine Methode für etwas nutzen

Weil das der jQuery-Weg ist. Wer den gehen will, bitteschön. Wer nicht, dann auch nicht find().

Das klingt nach "aus Prinzip umständlich"!

Was wäre an $(this).parent() jetzt umständlicher als an $(this.parentNode)?

Das geht in allen UA, die diese Methode [querySelectorAll()] anbieten.

Also in allen relevanten.

LLAP 🖖

[Camping_RIDER]

Aloha ;)

Ich mach dann mal einen auf Chuck Norris...

Entweder man verwendet jQuery – dann konsequent: $(this).parent().find(":checkbox").

Warum sollte ich extra eine Methode für etwas nutzen

Weil das der jQuery-Weg ist. Wer den gehen will, bitteschön. Wer nicht, dann auch nicht find().

... das ist jetzt aber auch kein Argument. Prinzipien mögen schön und gut sein, es gibt aber nicht immer einen Grund, sie strikt zu verfolgen - insbesondere ist situationsangepasstes, prinzipien-inspiriertes Handeln immer dem Handeln nach einem Prinzip vorzuziehen. Im Speziellen gibt es keinerlei rationalen Grund, bei Einsatz eines Frameworks nicht auch die zur Verfügung stehenden nativen Methoden mit einzubeziehen. Aber wenigstens argumentiert ihr beide auf gleich wackeligem Fundament :P

Das klingt nach "aus Prinzip umständlich"!

Was wäre an $(this).parent() jetzt umständlicher als an $(this.parentNode)?

Man könnte, und darauf wollte Felix wahrscheinlich raus, gemäß Funktionsaufruf vs. Attributzugriff diskutieren. Das ist aber, mit Verlaub, bei einer derart hoch abstrahierten Sprache wie JavaScript wirklich eher unsinnig.

Das geht in allen UA, die diese Methode [querySelectorAll()] anbieten.

Also in allen relevanten.

Naja. Was relevant ist und was nicht ist vom Projekt und von den Anforderungen abhängig. Wenn legacy-Support wichtig ist (was in einzelnen Projekten so sein kann), dann ist es richtig, jquery für diesen Zweck zu verwenden. Allerdings wisst ihr Beide nicht, ob legacy-support in diesem Fall wichtig ist oder nicht, es ist also etwas müßig, die Alternativen gegeneinander abzuwiegen ;)

Grüße,

RIDER

[Gunnar Bittersmann]

@@Camping_RIDER

Im Speziellen gibt es keinerlei rationalen Grund, bei Einsatz eines Frameworks nicht auch die zur Verfügung stehenden nativen Methoden mit einzubeziehen.

Einen technischen Grund gibt es nicht, aber vielleicht einen methodischen.

Was wäre an $(this).parent() jetzt umständlicher als an $(this.parentNode)?

Man könnte, und darauf wollte Felix wahrscheinlich raus, gemäß Funktionsaufruf vs. Attributzugriff diskutieren.

Was ändert das für den Entwickler? Für den Entwickler wäre es eher umständlich, verschiedene Konzepte gemischt zu verwenden.

Das geht in allen UA, die diese Methode [querySelectorAll()] anbieten.

Also in allen relevanten.

Allerdings wisst ihr Beide nicht, ob legacy-support in diesem Fall wichtig ist oder nicht

Es ist 2016 und das Prinzip von progressive enhancement hat sich immer noch nicht herumgesprochen. :-( (Deshalb sollte das ja auch unbedingt in JS-Artikeln für Anfänger vermittelt werden; aber das diskutieren wir an anderer Stelle.)

Das An-/Abwählen der einzelnen Checkboxen funktioniert bestens in allen Browsern. Der Komfort, alle Checkboxen einer Gruppe mit einem Click an-/abwählen zu können, kommt obendrauf.

Das Sahnehäubchen wäre freilich, die Checkbox für alle an-/abwählen nur dann anzuzeigen, wenn die Funktion auch zur Verfügung steht; hier also, wenn der Browser querySelectorAll() unterstützt.

LLAP 🖖

[Camping_RIDER]

Aloha ;)

Im Speziellen gibt es keinerlei rationalen Grund, bei Einsatz eines Frameworks nicht auch die zur Verfügung stehenden nativen Methoden mit einzubeziehen.

Einen technischen Grund gibt es nicht, aber vielleicht einen methodischen.

Nein, auch der beruht auf unreflektiertem Anwenden von Prinzipien und ist (in diesem Fall) nicht sinnvoll begründbar. Und an Empfehlungen die ich geben möchte knüpfe zumindest ich die Bedingung, dass sie und die zugrundeliegenden Beweggründe sinnvoll belegt werden können - abseits von allgemein formulierten Prinzipien.

Was wäre an $(this).parent() jetzt umständlicher als an $(this.parentNode)?

Man könnte, und darauf wollte Felix wahrscheinlich raus, gemäß Funktionsaufruf vs. Attributzugriff diskutieren.

Was ändert das für den Entwickler? Für den Entwickler wäre es eher umständlich, verschiedene Konzepte gemischt zu verwenden.

Stimmt nicht. Methodenaufruf vs. Attributzugriff ist eine Frage der Performance, also sehr wohl für den Entwickler relevant. Dass das in diesem Fall ein eher illegitimes Argument ist habe ich ja schon gesagt. Grundsätzlich ist das aber schon relevant.

Dagegen ist das "verschiedene Konzepte gemischt zu verwenden" nur dann schädlich, wenn man sich mit seinem Handwerkszeug (noch) nicht auskennt. Wenn man weiß was man tut stellt das kein Problem dar, auch kein konzeptionelles.

Das geht in allen UA, die diese Methode [querySelectorAll()] anbieten.

Also in allen relevanten.

Allerdings wisst ihr Beide nicht, ob legacy-support in diesem Fall wichtig ist oder nicht

Es ist 2016 und das Prinzip von progressive enhancement hat sich immer noch nicht herumgesprochen. :-(

Das An-/Abwählen der einzelnen Checkboxen funktioniert bestens in allen Browsern. Der Komfort, alle Checkboxen einer Gruppe mit einem Click an-/abwählen zu können, kommt obendrauf.

nana, jetzt schießt du aber übers Ziel hinaus. Auch mit der entsprechenden jQuery-Methode stellt das ganze progressive enhancement dar, das An-/Abwählen einzelner Checkboxen war ja nie Gegenstand des Gesprächs.

Also: Erklär mir mal, inwiefern progressive enhancement via Vanilla-JavaScript besser ist, als progressive enhancement via jQuery, das auch in veralteteren (<- Unwort) Browsern die "enhancete" Funktionalität zur Verfügung stellt.

Du hast grad argumentiert, dass es sinnvoll ist, veralteten Browser nicht die volle Funktionalität zur Verfügung zu stellen, wenn man die freie Wahl hat das zu tun oder zu lassen :P

Progressive Enhancement ist der Weg, Funktionierendes nicht kaputtzumachen und für veraltete Browser Basisfunktionalität zur Verfügung zu stellen oder zumindest nicht zu verbauen. Das ist besser, als veraltete Browser grundsätzlich auszuschließen (was mit jQuery ja gerade nicht passiert, und in diesem Fall sowieso nie im Raum stand), aber sicher schlechter als ein Tool (jQuery) zu benutzen, was auch veralteten Browsern volle Funktionalität zur Verfügung stellt.

Und wie gesagt, in diesem speziellen Fall ist legacy-Browsersupport sogar noch mit progressive enhancement kombiniert, so what?

Grüße,

RIDER

[Gunnar Bittersmann]

@@Camping_RIDER

Stimmt nicht. Methodenaufruf vs. Attributzugriff ist eine Frage der Performance, also sehr wohl für den Entwickler relevant.

Nein. Dass diese Mikrooptimierung kaum sinnvoll ist, hat du selbst schon gesagt. Und wenn sie es wäre, dürfte man an gar keiner Stelle jQuery einsetzen.

Dagegen ist das "verschiedene Konzepte gemischt zu verwenden" nur dann schädlich, wenn man sich mit seinem Handwerkszeug (noch) nicht auskennt.

Ich würde eher denken, dass wenn man sich mit seinem Handwerkszeug auskennt, man nicht verschiedene Konzepte (für dasselbe) gemischt verwenden wird.

nana, jetzt schießt du aber übers Ziel hinaus.

??

Auch mit der entsprechenden jQuery-Methode stellt das ganze progressive enhancement dar

Ja. (Die Checkboxen für alle an-/abwählen dürften auch bei Verwendung von jQuery nur dann angezeigt werden, wenn JavaScript ausgeführt wird.)

das An-/Abwählen einzelner Checkboxen war ja nie Gegenstand des Gesprächs.

Weil das die Grundfunktionalität ist.

Also: Erklär mir mal, inwiefern progressive enhancement via Vanilla-JavaScript besser ist, als progressive enhancement via jQuery, das auch in veralteteren (<- Unwort) Browsern die "enhancete" Funktionalität zur Verfügung stellt.

Hab ich hier nicht behauptet. Mein Argument war in diesem Thread nicht, auf jQuery zu verzichten, sondern wenn man jQuery einsetzt, dann konsequent.

Du hast grad argumentiert, dass es sinnvoll ist, veralteten Browser nicht die volle Funktionalität zur Verfügung zu stellen, wenn man die freie Wahl hat das zu tun oder zu lassen :P

Ich kram dann mal erneut Jeremy Keith raus: „Es ist ein verbreiteter Irrglaube, dass progressive enhancement heißt, seine Zeit in alte Browser zu stecken – das Gegenteil ist der Fall. Die Grundfunktionalität zu erstellen dauert nicht allzu lange. Wenn man das getan hat, kann man seine Zeit damit verbringen, mit den neusten und großartigsten Browsertechnologien zu experimentieren; sicher in dem Wissen, dass selbst wenn diese noch nicht weitgehend unterstützt werden, man den Fallback ja bereits hat.“

Inwieweit man also Entwicklungszeit da reinstecken möchte, die Checkboxen für alle an-/abwählen auch in IE < 9 zur Verfügung zu stellen, wäre zu überlegen. Vermutlich lohnt der Gedanke nicht. Die erweiterte Funktionalität auch in steinalten Browsern anzubieten wäre hier wohl kein Argument für den Einsatz von jQuery.

Progressive Enhancement ist der Weg, Funktionierendes nicht kaputtzumachen und für veraltete Browser Basisfunktionalität zur Verfügung zu stellen oder zumindest nicht zu verbauen.

So gesagt ist das falsch. (Reihenfolge)

Progressive Enhancement ist der Weg, für alle Browser Basisfunktionalität zur Verfügung zu stellen und diese nicht kaputtzumachen.

Das ist besser, als veraltete Browser grundsätzlich auszuschließen (was mit jQuery ja gerade nicht passiert, und in diesem Fall sowieso nie im Raum stand)

Was du hier meinst, ist graceful degredation.

aber sicher schlechter als ein Tool (jQuery) zu benutzen, was auch veralteten Browsern volle Funktionalität zur Verfügung stellt.

Nein, s.o.

LLAP 🖖

[Camping_RIDER]

Aloha ;)

Stimmt nicht. Methodenaufruf vs. Attributzugriff ist eine Frage der Performance, also sehr wohl für den Entwickler relevant.

Nein. Dass diese Mikrooptimierung kaum sinnvoll ist, hat du selbst schon gesagt.

Nein, das habe ich nicht gesagt. Ich habe gesagt, dass sie an dieser Stelle kaum sinnvoll ist. Es gibt durchaus Probleme, bei denen solche Mikrooptimierung sinnvoll ist.

Und wenn sie es wäre, dürfte man an gar keiner Stelle jQuery einsetzen.

Natürlich nicht.

Dagegen ist das "verschiedene Konzepte gemischt zu verwenden" nur dann schädlich, wenn man sich mit seinem Handwerkszeug (noch) nicht auskennt.

Ich würde eher denken, dass wenn man sich mit seinem Handwerkszeug auskennt, man nicht verschiedene Konzepte (für dasselbe) gemischt verwenden wird.

Doch, wenn es dafür Gründe gibt. Mikrooptimierung kann einer sein (allerdings bitte nicht in hochabstrahierten Web-Programmier-Skriptsprachen), es gibt aber auch andere denkbare Gründe.

nana, jetzt schießt du aber übers Ziel hinaus.

??

Meiner Meinung nach hat der Fall (vielleicht bis aufs Einblenden der Checkboxen, das ist mMn aber nichtmal wirklich wichtig) absolut nichts mit progressive enhancement zu tun und ich habe ein bissl den Eindruck, wie wenn du versuchst diesen anders gelagerten Fall mit einem allgemein akzeptierten Schlagwort zu matchen (kann aber auch falsch liegen, siehe unten).

Auch mit der entsprechenden jQuery-Methode stellt das ganze progressive enhancement dar

Ja. (Die Checkboxen für alle an-/abwählen dürften auch bei Verwendung von jQuery nur dann angezeigt werden, wenn JavaScript ausgeführt wird.)

Also warum bringst du das Gespräch dann überhaupt auf progressive enhancement, wenn das Prinzip bei keiner der beiden Methoden missachtet wird?

Also: Erklär mir mal, inwiefern progressive enhancement via Vanilla-JavaScript besser ist, als progressive enhancement via jQuery, das auch in veralteteren (<- Unwort) Browsern die "enhancete" Funktionalität zur Verfügung stellt.

Hab ich hier nicht behauptet.

Deine Aussage zu progressive enhancement liest sich allerdings so. Das kann allerdings auch eine Fehlinterpretation meinerseits sein, in dem Fall ziehe ich das zurück.

Rekapitulieren wir:

Das geht in allen UA, die diese Methode [querySelectorAll()] anbieten.

Also in allen relevanten.

Allerdings wisst ihr Beide nicht, ob legacy-support in diesem Fall wichtig ist oder nicht

Es ist 2016 und das Prinzip von progressive enhancement hat sich immer noch nicht herumgesprochen. :-(

Ich interpretiere mal anders: Ging es dir lediglich um den Begriff legacy-support? Natürlich ist progressive enhancement geboten, das ändert aber nichts daran, dass man im Zweifelsfall und bei manchen Projekten (siehe "in diesem Fall") auch veraltete Browser mit voller Funktionalität versorgen möchte, statt nur mit Basisfunktionalität. Das ist, was ich unter legacy-support verstehe. Ich verstehe insbesondere nicht darunter, dass ohne legacy-support veraltete Browser nicht mit Basisfunktionalität unterstützt werden. Vielleicht war das ja eine Unklarheit, die mit zu deiner Aussage, meiner Verwirrung darüber und vielleicht auch meiner Fehleinschätzung ("allgemein anerkanntes Schlagwort") geführt hat.

Mein Argument war in diesem Thread nicht, auf jQuery zu verzichten, sondern wenn man jQuery einsetzt, dann konsequent.

Das habe ich herausgelesen, mir fehlt aber nach wie vor die sinnvolle Begründung dafür, warum das wichtig wäre.

Du hast grad argumentiert, dass es sinnvoll ist, veralteten Browser nicht die volle Funktionalität zur Verfügung zu stellen, wenn man die freie Wahl hat das zu tun oder zu lassen :P

Ich kram dann mal erneut Jeremy Keith raus: „Es ist ein verbreiteter Irrglaube, dass progressive enhancement heißt, seine Zeit in alte Browser zu stecken – das Gegenteil ist der Fall. Die Grundfunktionalität zu erstellen dauert nicht allzu lange. Wenn man das getan hat, kann man seine Zeit damit verbringen, mit den neusten und großartigsten Browsertechnologien zu experimentieren; sicher in dem Wissen, dass selbst wenn diese noch nicht weitgehend unterstützt werden, man den Fallback ja bereits hat.“

Dieses Zitat hat inhaltlich nichts mit dem zu tun, was ich geschrieben hatte.

Inwieweit man also Entwicklungszeit da reinstecken möchte, die Checkboxen für alle an-/abwählen auch in IE < 9 zur Verfügung zu stellen, wäre zu überlegen. Vermutlich lohnt der Gedanke nicht.

Ich weiß ja, dass du gerne pauschale Aussagen triffst, ich betone aber nochmal (auch wenn ich das schonmal deutlich geschrieben hatte): In einzelnen Projekten kann das volle Unterstützen veralteter Browser (ja, auch IE 8) durchaus zu Anforderungen und Rahmenbedingungen gehören. Und das kann dann schon durchaus auch ein Argument für die Verwendung von jQuery sein.

Die erweiterte Funktionalität auch in steinalten Browsern anzubieten wäre hier wohl kein Argument für den Einsatz von jQuery.

Doch, nämlich genau dann, wenn das zu den Anforderungen gehört. Und ob es das tut oder nicht ist reine Spekulation; meine Aussage war ausschließlich, dass das so sein könnte - ich sehe keinen Grund, dem zu widersprechen.

Progressive Enhancement ist der Weg, Funktionierendes nicht kaputtzumachen und für veraltete Browser Basisfunktionalität zur Verfügung zu stellen oder zumindest nicht zu verbauen.

So gesagt ist das falsch. (Reihenfolge)

Progressive Enhancement ist der Weg, für alle Browser Basisfunktionalität zur Verfügung zu stellen und diese nicht kaputtzumachen.

Okay, akzeptiert. Wir wissen beide was gemeint ist.

Das ist besser, als veraltete Browser grundsätzlich auszuschließen (was mit jQuery ja gerade nicht passiert, und in diesem Fall sowieso nie im Raum stand)

Was du hier meinst, ist graceful degredation.

Den Namen hat es nur verdient, wenn man es richtig macht. Ansonsten nennt man es auch Murks. Ich hatte eher Murks im Sinn, auf graceful degradation passt die Aussage aber auch, ja.

aber sicher schlechter als ein Tool (jQuery) zu benutzen, was auch veralteten Browsern volle Funktionalität zur Verfügung stellt.

Nein, s.o.

Doch, in zwei Fällen:

1. Wenn das für das konkrete Projekt den Anforderungen entspricht (was wir im vorliegenden Fall nicht wissen) oder
2. Wenn es keinen zusätzlichen Aufwand kostet (was im vorliegenden Fall so ist, der TO will so oder so jQuery verwenden, und bei jQuery ist legacy-Browsersupport inklusive).

Da letzterer hier vorliegt ist reines progressive enhancement schlechter als die Verwendung von jQuery, das Browsersupport sicherstellt und dabei, wie im vorliegenden Fall, keine Basisfunktionalität kaputtmacht (also auch progressive enhancement umsetzt).

Grüße,

RIDER

[Gunnar Bittersmann]

@@Camping_RIDER

Meiner Meinung nach hat der Fall (vielleicht bis aufs Einblenden der Checkboxen, das ist mMn aber nichtmal wirklich wichtig) absolut nichts mit progressive enhancement zu tun

Doch, doch. Die einzelnen Checkboxen bieten die Grundfunktionalität. In dazu fähigen UAs (heißt in dem Fall: wenn JavaScript ausgeführt wird) wird diese angereichert (enhanced) um Checkboxen, die auf einen Click die An-/Abwahl einer ganzen Grupe ermöglichen.

(Ob das mit Vanille oder jQuery implementiert wird, ist an dieser Stelle irrelevant.)

Ich interpretiere mal anders: Ging es dir lediglich um den Begriff legacy-support? Natürlich ist progressive enhancement geboten, das ändert aber nichts daran, dass man im Zweifelsfall und bei manchen Projekten (siehe "in diesem Fall") auch veraltete Browser mit voller Funktionalität versorgen möchte, statt nur mit Basisfunktionalität.

Das ist eben gerade nicht der Grundgedanke von progressive enhancement, siehe Zitat von Jeremy Keith.

Vielleicht will man bei manchen Projekten auch veraltete Browser mit voller Funktionalität versorgen; in diesem Fall halte ich das für überflüssig.

Wenn man nun die Anreicherung um die Checkbox für alle mit jQuery implementiert, kriegt man die Funktionalität in alten Browsern frei Haus dazu – fein. Wenn man die Anreicherung mit querySelectorAll() implementiert, dann nicht – auch fein! Der Punkt ist, dass IE < 9 so irrelevant sind, dass es egal ist. (Die Grundfunktionalität ist ja gegeben.)

Die Checkbox für alle auch in IE < 9 funktionieren zu lassen wäre kein Grund, jQuery einzusetzen. Es mag aber andere Gründe für den Einsatz von jQuery geben.

LLAP 🖖

[Camping_RIDER]

Aloha ;)

Ja, so kann ich dem schon zustimmen...

(Ob das mit Vanille oder jQuery implementiert wird, ist an dieser Stelle irrelevant.)

...mit Vanille implementiere ich allerdings für gewöhnlich nur Kuchen, Eis, oder Pudding (nicht den von @marctrix^[1], denn den implementiert man bekanntlich mit CSS).

Ich interpretiere mal anders: Ging es dir lediglich um den Begriff legacy-support? Natürlich ist progressive enhancement geboten, das ändert aber nichts daran, dass man im Zweifelsfall und bei manchen Projekten (siehe "in diesem Fall") auch veraltete Browser mit voller Funktionalität versorgen möchte, statt nur mit Basisfunktionalität.

Das ist eben gerade nicht der Grundgedanke von progressive enhancement, siehe Zitat von Jeremy Keith.

Ja, einverstanden. Das liegt aber nicht daran, dass legacy-support so böse ist, sondern vor allem daran, dass progressive enhancement eine Philosophie ist, die das Ziel hat, sich nicht mehr um legacy-support kümmern zu müssen. (Aber bei manchen Projekten, ... du weißt schon.)

Vielleicht will man bei manchen Projekten auch veraltete Browser mit voller Funktionalität versorgen; in diesem Fall halte ich das für überflüssig.

Prinzipiell ja.

Wenn man nun die Anreicherung um die Checkbox für alle mit jQuery implementiert, kriegt man die Funktionalität in alten Browsern frei Haus dazu – fein. Wenn man die Anreicherung mit querySelectorAll() implementiert, dann nicht – auch fein! Der Punkt ist, dass IE < 9 so irrelevant sind, dass es egal ist. (Die Grundfunktionalität ist ja gegeben.)

Die Checkbox für alle auch in IE < 9 funktionieren zu lassen wäre kein Grund, jQuery einzusetzen. Es mag aber andere Gründe für den Einsatz von jQuery geben.

Sagen wir mal so: Es ist (außer in Spezialfällen) zumindest kein hinreichender Grund, jQuery einzusetzen, ja.

Grüße,

RIDER

---

1. Wollte dich nicht mit reinziehen, *scnr* ↩︎

[marctrix]

Hej Camping_RIDER,

(Ob das mit Vanille oder jQuery implementiert wird, ist an dieser Stelle irrelevant.)

...mit Vanille implementiere ich allerdings für gewöhnlich nur Kuchen, Eis, oder Pudding (nicht den von @marctrix^[1], denn den implementiert man bekanntlich mit CSS).

Doch wolltest du. ;-)

Ist aber ok. Ich lache gerne - auch über andere, also darf man auch über mich lachen!

Ist mir lieber als der umgekehrte Fall: ich darf nicht mehr über euch lachen, und im Gegenzug seht ihr davon ab, Euren Schabernack mit mir zu treiben... ;-)

Wäre doch langweilig. Man muss ja niemanden (bösartig) auslachen!

Marc

---

1. Wollte dich nicht mit reinziehen, *scnr* ↩︎