nicht angemeldet
Akkordeon mit CSS
0 
Der Martin
0 0 Der Martin
Akkordeon mit CSS
Hi,
ich möchte ein Akkordeon bauen dass allein mit CSS funktioniert.
Meine Idee war die Header der einzelnen Akkordeon-Tabs als label zu deklarieren die Radiobuttons auswählen.
Über die Radiobuttons kann ich dann rausfinden welcher Inhalt angezeigt werden soll.
Ein Beispiel, ungetestet und nur runtergeschrieben zur besseren Veranschaulichung was ich meine:
<!doctype html>
<html>
<head>
<title></title>
<link rel="stylesheet" href="/styles.css">
</head>
<body>
<label for="akkTab1">Akkordeon Tab Eins</label>
<input type="radio" id="akkTab1" name="akkoredeon"/>
<div>
Akkordeon Inhalt 1
</div>
<label for="akkTab2">Akkordeon Tab Zwei</label>
<input type="radio" id="akkTab2" name="akkoredeon"/>
<div>
Akkordeon Inhalt 2
</div>
</body>
</html>
Das CSS:
[name=akkordeon] + div {
display:none;
}
[name=akkordeon]:checked + div {
display:block;
}
Dass das in veralteten Browsern nicht funktioniert ist mir genauso klar wie egal.
Meine Frage ist nun, was ihr von diesem Ansatz haltet?
Sind die inputs so unsemantisch dass ihr darauf verzichten würdet und es über JS lösen würdet (ich finde sie nicht komplett unsemantisch, da sie ja eindeutig anzeigen welcher inhalt _gewählt_ wurde)?
Oder was ist an dieser Möglichkeit noch schlecht, was ich vergessen habe?
~dave
-
Hallo,
Meine Idee war die Header der einzelnen Akkordeon-Tabs als label zu deklarieren die Radiobuttons auswählen.
ich bin irgendwie nicht so richtig begeistert von der Idee, label- und input-Elemente ohne Formular zu verwenden, auch wenn das für diesen Fall recht vernünftig klingt.
Über die Radiobuttons kann ich dann rausfinden welcher Inhalt angezeigt werden soll.
Ich würde Checkboxen nehmen, damit man auch mal mehrere Blöcke sichtbar machen kann - ich ärgere mich bei horizontalen oder vertikalen Accordion-Implementierungen oft darüber, dass immer nur ein Block sichtbar ist.
Und die Checkboxen selbst kann man dann noch unsichtbar machen. Ausgelöst werden sie ja auch durch das Aktivieren (Klicken) der zugeordneten Labels, und der Status ist daran erkennbar, welche Felder angezeigt werden und welche nicht.
Und wenn wir schon Formular-Komponenten verbauen, könnten wir als Container für die wählbaren Inhalte auch je ein fieldset nehmen.Dass das in veralteten Browsern nicht funktioniert ist mir genauso klar wie egal.
Einverstanden. :-)
Meine Frage ist nun, was ihr von diesem Ansatz haltet?
Sind die inputs so unsemantisch dass ihr darauf verzichten würdet und es über JS lösen würdet (ich finde sie nicht komplett unsemantisch, da sie ja eindeutig anzeigen welcher inhalt _gewählt_ wurde)?Ich bin hin- und hergerissen zwischen der Semantik, die label, input und fieldset eigentlich haben sollten (nämlich Formulare zu bilden), und der Semantik, die du hier abweichend davon, aber auch irgendwie passend reinbringst.
Oder was ist an dieser Möglichkeit noch schlecht, was ich vergessen habe?
Außer der Semantik für Puristen fällt mir da im Moment auch nichts auf ... oder ein. ;-)
Ciao,
Martin--
Die letzten Worte des Helden:
Feigling! Traust dich ja doch nicht!
Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(-
Hi,
Ich würde Checkboxen nehmen, damit man auch mal mehrere Blöcke sichtbar machen kann - ich ärgere mich bei horizontalen oder vertikalen Accordion-Implementierungen oft darüber, dass immer nur ein Block sichtbar ist.
Dann ist's aber kein Akkordeon mehr, sondern nur mehrere einklappbare Container :-P
Und wenn wir schon Formular-Komponenten verbauen, könnten wir als Container für die wählbaren Inhalte auch je ein fieldset nehmen.
Wo würdest du da ein fieldset einfügen? Anstelle des divs?
Mir ist nicht ganz klar wo du das einfügen würdest und weshalb.Ich bin hin- und hergerissen zwischen der Semantik, die label, input und fieldset eigentlich haben sollten (nämlich Formulare zu bilden), und der Semantik, die du hier abweichend davon, aber auch irgendwie passend reinbringst.
Die Semantik ist auch mein Hauptbedenken, aber ich kann in der Spezifikation nichts finden dass input außerhalb von form in irgendeiner Weise verbieten oder davon abraten würde.
Allerdings bedeutet valide ja nicht unbedingt semantisch. Andererseits: welchen semantisch korrekten Anwendungsfall gibt es sonst ein input außerhalb eines forms zu haben?~dave
-
Hallo,
Ich würde Checkboxen nehmen, damit man auch mal mehrere Blöcke sichtbar machen kann - ich ärgere mich bei horizontalen oder vertikalen Accordion-Implementierungen oft darüber, dass immer nur ein Block sichtbar ist.
Dann ist's aber kein Akkordeon mehrdoch, sicher - ein Akkordeon kann man ja auch so auseinanderziehen, dass man mehr als nur eine Falte sieht.
Und wenn wir schon Formular-Komponenten verbauen, könnten wir als Container für die wählbaren Inhalte auch je ein fieldset nehmen.
Wo würdest du da ein fieldset einfügen? Anstelle des divs?Ja.
Mir ist nicht ganz klar wo du das einfügen würdest und weshalb.
Sie bilden mit den label- und den input-Elementen eine harmonische Familie. Und ich dachte, wenn du schon bei den beiden erstgenannten mit der ursprünglichen Semantik etwas großzügig umgehst, warum dann nicht gleich Nägel mit Köpfen? :-)
Die Semantik ist auch mein Hauptbedenken, aber ich kann in der Spezifikation nichts finden dass input außerhalb von form in irgendeiner Weise verbieten oder davon abraten würde.
Natürlich, verboten ist es nicht; das Dokument könnte ohne weiteres valide sein.
Allerdings bedeutet valide ja nicht unbedingt semantisch. Andererseits: welchen semantisch korrekten Anwendungsfall gibt es sonst ein input außerhalb eines forms zu haben?
Ein Eingabeelement, dessen Wert zyklisch per Javascript (rein clientseitig) abgefragt und angewendet wird? Dann wäre das Formular als Vehikel für Daten, die an ein serverseitiges Script gesendet werden sollen, unnötig.
So long,
Martin--
In Ägypten haben früher 150000 Leute 35 Jahre lang an einer Pyramide gearbeitet. Aber bei uns arbeiten doppelt so viele Leute doppelt so lange allein an der Baugenehmigung.
(Dieter Nuhr, deutscher Kabarettist)
Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(-
Hi,
Allerdings bedeutet valide ja nicht unbedingt semantisch. Andererseits: welchen semantisch korrekten Anwendungsfall gibt es sonst ein input außerhalb eines forms zu haben?
Ein Eingabeelement, dessen Wert zyklisch per Javascript (rein clientseitig) abgefragt und angewendet wird? Dann wäre das Formular als Vehikel für Daten, die an ein serverseitiges Script gesendet werden sollen, unnötig.
Das heißt wenn ich anfange zu speichern welche Akkordeon-Blöcke geöffnet sind (um genau diese beim nächsten Seitenaufruf bereits geöffnet zu haben) ist es semantisch? O.o
~dave
-
Hallo,
Allerdings bedeutet valide ja nicht unbedingt semantisch. Andererseits: welchen semantisch korrekten Anwendungsfall gibt es sonst ein input außerhalb eines forms zu haben?
Ein Eingabeelement, dessen Wert zyklisch per Javascript (rein clientseitig) abgefragt und angewendet wird? Dann wäre das Formular als Vehikel für Daten, die an ein serverseitiges Script gesendet werden sollen, unnötig.
Das heißt wenn ich anfange zu speichern welche Akkordeon-Blöcke geöffnet sind (um genau diese beim nächsten Seitenaufruf bereits geöffnet zu haben) ist es semantisch? O.odie Argumentation ist zwar ein wenig von hinten durch die Brust ins Knie - aber der Aspekt ist eigentlich gut. Und ja, so sind vermutlich auch Hardcore-Semantiker ruhiggestellt.
Ciao,
Martin--
Schon gewusst, dass Aftershave trotz des Namens eigentlich eher fürs Gesicht gedacht ist?
Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
-
-
-
-