CSS-Kniffliges zum Wochenende

[Gunnar Bittersmann]

@@1unitedpower

Aber darauf bist du ja auch schon gekommen, wieso wolltest du die Lösung nochmal vermeiden?

Dann wäre wohl auch ein Clearfix fällig … Das wäre bestenfalls ein Hack, keine gute Lösung.

Mittel- bis langfristig wäre der Weg hier, die fehlende Unterstützung von display: contents in die Bugtracker aller Browser sans Firefox einzutüten. Stelle ich mir nicht besonders kompliziert vor, das zu implementieren. Das Feature ist auch anderswo nützlich/notwendig: Address book.

Das musst du auch für aria-expanded machen, im Moment lügt das Attribut noch über die Sichbarkeit der Navigations-Liste.

Nicht wirklich. Bei breiten Viewports ist der Button ja weg, im Sinne von: richtig weg – auch für AT (display: none). Das aria-expanded-Attribut eines Buttons, den es gar nicht gibt, sollte dann irrelevant sein.

Bei details liegt der Fall etwas anders: das open-Attribut hängt am details-Container-Element, nicht am verschwindenden summary-Element.

Außerdem: verschwindendes summary-Element — was passiert dann? Die Spec sagt: “If there is no summary child element, a user agent should provide its own legend (e.g. in English "Details" or Spanish "Detalles").” Könnten UAs solch ein eigenes Dingens auch anbieten, wenn man summary { display: none } setzt?

Entscheidend für das Markup sollte letzten Endes doch die Zugänglichkeit sein, nicht der Komfort für den Entwickler.

Auf jeden Fall.

Dabei wäre auch zu bedenken, dass nicht nur Browser details unterstützen müssen, sondern auch AT. Gegenwärtig bleiben womöglich noch mehr Nutzer auf der Strecke als Edge- und IE-Nutzer.

Ich weiß nicht, welche Lösung Nutzer(innen) von assistiver Technolgie hier bevorzugen, müsste man wohl mal Betroffene fragen.

Gute Frage; werde ich bei Gelegenheit mal weitergeben.

LLAP 🖖