Fragen zum CSS-Flyout-Menü
Bimmelbeule
- css
- html
Hallo!
Ich habe noch einige Fragen zu meinem Projekt "Navigation oben Testseite":
Navigation oben Testseite
Fragen zum CSS-Flyout-Menü (ich habe das hier abgekupfert):
Selfhtml CSS Flyout Menü
Die verwendeten UTF-8 Zeichen "Hamburger" und "Multiplikation" werden auf dem Desktop und in Android einwandfrei dargestellt, aber im Ipad nicht (stattdessen ein Dreieck). Gibt es da einen Trick oder muss ich extra einen eigenen Font einbinden (beispielsweise von Fontello)?
Sollte man die Hamburger-Navigation fix machen (dann wäre die Navigation immer erreichbar, klaut aber Platz auf mobilen Geräten)?
Und wo ich gerade dabei bin, hier noch ein paar allgemeine Fragen zu meiner "Navigation oben Testseite":
Ist das jetzt von der rudimentären Bedienung korrekt so? DOM und Semantik sollten jetzt stimmen oder habe ich was übersehen? Ich habe mich vorher noch nie damit beschäftigt…
Ich habe meine Seiten immer mit lynx (links2 geht auch) auf die rudimentäre Logik in der Tastatur-Navigation getestet. Jetzt habe ich auch mal w3m/elinks probiert und beide finden bei der Nutzung des skiplinks main nicht. Passt da was nicht auf meiner Testseite oder liegt es an den Browsern? Sind Textbrowser heute überhaupt noch für irgendjemand relevant?
Kann man den HTML/CSS-Code noch weiter eindampfen, ohne Funktionalität zu verlieren (ich bin ein echtes Sparbrötchen, was Code angeht)?
Danke für Eure Mühe!
Hallo,
zu deinem eigentlichen Anliegen kann ich mangels Testmöglichkeiten leider nicht viel sagen, außer "bei mir funktioniert's zufriedenstellend", fwiw.
Aber ich habe einen anderen guten Rat: Die Domain unsinn.de, die du als Platzhalter verwendest, ist tatsächlich registriert, und vermutlich nicht auf dich. Ich empfehle dir daher, für solche Zwecke eine der eigens dafür vorgesehenen Beispiel- oder Testdomains zu verwenden, etwa unsinn.test. Die TLD .test und alle ihre Subdomains können nach Herzenslust für Test- und Demozwecke verwendet werden.
Apropos Unsinn: Das erinnert mich an eine ganz andere nette Begebenheit.
Ich reise ja gern in den Niedelanden rum, am liebsten mit einer Motoryacht auf dem verzweigten Fluss- und Kanalsystem zwischen Maas, Waal und Ijssel. Da gibt's herrliche verträumte alte Städtchen wie etwa Heusden an der Maas, oder herrliche Naturschutzgebiete wie de Biesbosch. Anyway, 1993 war ich mit Kameraden aus dem Ruhrgebiet unterwegs, und eines Nachmittags haben wir in Gouda angelegt. Genau, die Stadt, aus der der berühmte Käse kommt. Bei einem Landgang am Nachmittag fiel mir am Marktplatz ein chinesisches Restaurant auf, dessen Leuchtreklame den Namen WANH SIN verkündete.
Ich bedaure, dass ich kein Foto davon gemacht habe, denn etwa 3 Jahre später war ich mal wieder dort, und da gab's das Lokal mit dem originellen Namen nicht mehr.
Einen schönen Tag noch
Martin
Hi there,
Bei einem Landgang am Nachmittag fiel mir am Marktplatz ein chinesisches Restaurant auf, dessen Leuchtreklame den Namen WANH SIN verkündete.
Großartig!
@@Der Martin
Ijssel
Das sieht irgendwie falsch aus. Die Wikipedia meint zwar, im Deutschen schreibt man das so; es sieht aber trotzdem falsch aus.
🖖 Живіть довго і процвітайте
Hallo,
Ijssel
Das sieht irgendwie falsch aus. Die Wikipedia meint zwar, im Deutschen schreibt man das so; es sieht aber trotzdem falsch aus.
hmm, wenn du meinst ...
Ich kann dir aber aus jahrzehntelanger Erfahrung sagen, dass das sogar die Holländer manchmal auch so schreiben. Das Bewusstsein um die IJ-Ligatur (die vereinzelt auch als Y geschrieben wird) verliert sich da wohl auch allmählich. Die Wikipedia hängt da der Alltagssprache bzw. -schrift etwas hinterher.
Übrigens meinte ich vor allem die Hollandse, nicht die Gelderse Ijssel. Aber das wurde mir erst beim Lesen des von dir verlinkten Artikels deutlich.
Einen schönen Tag noch
Martin
@@Der Martin
IJ-Ligatur (die vereinzelt auch als Y geschrieben wird)
Besonders etwas weiter südlich. 😉
Digraph wäre der richtige Begriff. Es gibt IJ aber auch als Ligatur.
🖖 Живіть довго і процвітайте
Ijssel
Das sieht irgendwie falsch aus.
Wie ist das mit dt. Umlauten am Satz- oder Wortanfang, die ich im Programmcode, z.B. für Variablen-Namen, auch für Dateinamen, gerne vermeide wegen jahrzehntelanger Probleme.
AEnderungsvorschlaege, OEkologie, UEberlingen. Aber Uelzen,
Hallo Martin,
Die TLD .test und alle ihre Subdomains können nach Herzenslust für Test- und Demozwecke verwendet werden.
Für Testzwecke: Ja.
Für Demozwecke: Jein. Für Vorführungen und Dokumentationen ist eigentlich die Example-Familie gedacht (TLD .example sowie example.com, example.org, example.net und example.edu)
Zumindest hab ich das so verstanden...
Rolf
n'Abend Rolf,
Die TLD .test und alle ihre Subdomains können nach Herzenslust für Test- und Demozwecke verwendet werden.
Für Testzwecke: Ja.
Für Demozwecke: Jein. Für Vorführungen und Dokumentationen ist eigentlich die Example-Familie gedacht (TLD .example sowie example.com, example.org, example.net und example.edu)
die Variante .example hatte ich gerade gar nicht mehr auf dem Schirm, sondern nur example.com, example.org oder example.net. Aber ehrlich gesagt wüsste ich nicht, dass zwischen .test und .example ein signifikanter Unterschied bestünde. Beide werden nicht vergeben und kommen im DNS nicht vor. Also warum Unterchiede machen?
Zumindest hab ich das so verstanden...
Mag sein, dass du recht hast. Das ist dann aber eher das Zählen von Hülsenfrüchten[1].
Einen schönen Tag noch
Martin
Beim Geburtstag meiner Mutter letzten Mittwoch waren wir abends auswärts essen. Mein Vater hatte ein Schweinenackensteak mit Westernkartoffeln und Grillgemüse und stellte fest: Das sind keine Bohnen, sondern in der Schote gegrillte Erbsen. Sehr ungewöhnlich, finde ich. ↩︎
Hi there,
- Die verwendeten UTF-8 Zeichen "Hamburger" und "Multiplikation" werden auf dem Desktop und in Android einwandfrei dargestellt, aber im Ipad nicht (stattdessen ein Dreieck). Gibt es da einen Trick oder muss ich extra einen eigenen Font einbinden (beispielsweise von Fontello)?
Ein klassischeer Fall, daß man nicht beides haben kann, man muß sich für's Ei oder für das Omlett entscheiden. Oder anders's rum, wer sich für irgendein Klumpert von Apple entscheidet, der ist Kummer ohnehin gewohnt, der muß halt damit leben, daß man sich bei Apple die Darstellung mancher Zeichen etwas anders vorstellt. Ich würde dafür keinen eigenen Font laden, ausser irgendjemand, der die Mehrarbeit auch bezahlt, besteht darauf.
- Sollte man die Hamburger-Navigation fix machen (dann wäre die Navigation immer erreichbar, klaut aber Platz auf mobilen Geräten)?
Nein aber eventuell eine Möglichkeit einbauen, mit der ganz schnell nach oben gescrollt werden kann.
- Ich habe meine Seiten immer mit lynx (links2 geht auch) auf die rudimentäre Logik in der Tastatur-Navigation getestet. Jetzt habe ich auch mal w3m/elinks probiert und beide finden bei der Nutzung des skiplinks main nicht. Passt da was nicht auf meiner Testseite oder liegt es an den Browsern? Sind Textbrowser heute überhaupt noch für irgendjemand relevant?
Letzte Frage kann ich Dir nicht beantworten - im Sinne zum Testen vielleicht, aber ob damit noch jemand surft, keine Ahnung. Übrigens zeigt mein Browser Deinen Skiplink auch nicht an (Chromium Linux Mint)
- Kann man den HTML/CSS-Code noch weiter eindampfen, ohne Funktionalität zu verlieren (ich bin ein echtes Sparbrötchen, was Code angeht)?
Irgendwas geht immer, sinnvoll ist es imho nicht. Schade um die Zeit, die man für die letzten paar Prozent verplempert. Von der Geschwindigkeit her spielt das keine Rolle und vom "Datenverbrauch" her auch nicht...
Ein klassischeer Fall, daß man nicht beides haben kann, man muß sich für's Ei oder für das Omlett entscheiden. Oder anders's rum, wer sich für irgendein Klumpert von Apple entscheidet, der ist Kummer ohnehin gewohnt, der muß halt damit leben, daß man sich bei Apple die Darstellung mancher Zeichen etwas anders vorstellt.
Ich möchte sogar Apple-Nutzer gerne mit ins Boot holen… ツ
Gunnar Bittersmann hat mit ::marker eine Lösung…
- Sollte man die Hamburger-Navigation fix machen (dann wäre die Navigation immer erreichbar, klaut aber Platz auf mobilen Geräten)?
Nein aber eventuell eine Möglichkeit einbauen, mit der ganz schnell nach oben gescrollt werden kann.
Kommt noch…
Übrigens zeigt mein Browser Deinen Skiplink auch nicht an (Chromium Linux Mint)
Auf Chromium (Debian) schon (er wird nur sichtbar, wenn du mit der Tastatur navigierst)…
Irgendwas geht immer, sinnvoll ist es imho nicht. Schade um die Zeit, die man für die letzten paar Prozent verplempert. Von der Geschwindigkeit her spielt das keine Rolle und vom "Datenverbrauch" her auch nicht...
Mag sein… aber in zwei Jahren brauche ich nicht lange um den Kot zu kapieren…
Hi there,
Ich möchte sogar Apple-Nutzer gerne mit ins Boot holen… ツ
Ja eh, wenn Dir das den Aufwand wert ist.
Gunnar Bittersmann hat mit ::marker eine Lösung…
Hast Du das schon probiert? Normalerweise hat Gunnar ja Recht, aber was soll ::marker an Deinem Problem ändern? Hinter ::marker definierst Du mit content: ein Zeichen, und das wird vom Apple wieder anders dargestellt werden. Ich seh' da keine große Verbesserung.
Übrigens zeigt mein Browser Deinen Skiplink auch nicht an (Chromium Linux Mint)
Auf Chromium (Debian) schon (er wird nur sichtbar, wenn du mit der Tastatur navigierst)…
Ok, verstanden.
Irgendwas geht immer, sinnvoll ist es imho nicht. Schade um die Zeit, die man für die letzten paar Prozent verplempert. Von der Geschwindigkeit her spielt das keine Rolle und vom "Datenverbrauch" her auch nicht...
Mag sein… aber in zwei Jahren brauche ich nicht lange um den Kot zu kapieren…
Naja, der effizienteste Code ist nicht notwendigerweise der am leichtesten zu kapierende. Ich würde sogar sagen, das Gegenteil ist oft der Fall…
@@klawischnigg
Ich möchte sogar Apple-Nutzer gerne mit ins Boot holen… ツ
Ja eh, wenn Dir das den Aufwand wert ist.
Safari-Nutzer auf Desktop mögen eine vernachlässigbare Größe sein (wenn wir von progressive enhancement sprechen, wo die Grundfunktionalität gegeben ist). iPhone-/iPad-Nutzer möchte man vielleicht nicht vernachlässigen.
Normalerweise hat Gunnar ja Recht
Normalerweise? 😆
aber was soll ::marker an Deinem Problem ändern?
Ich hab nochmal genauer hingeschaut.
Hinter ::marker definierst Du mit content: ein Zeichen
Danke, das hat meinen Horizont erweitert.
Naja, der effizienteste Code ist nicht notwendigerweise der am leichtesten zu kapierende. Ich würde sogar sagen, das Gegenteil ist oft der Fall…
Das kann ich bestätigen. Wenn ich mir meine eigenen Lösungen in der CSSBattle ansehe, verstehe ich bei manchen auch nur noch Bahnhof.
🖖 Живіть довго і процвітайте
Gunnar Bittersmann hat mit ::marker eine Lösung…
Hast Du das schon probiert? Normalerweise hat Gunnar ja Recht, aber was soll ::marker an Deinem Problem ändern? Hinter ::marker definierst Du mit content: ein Zeichen, und das wird vom Apple wieder anders dargestellt werden. Ich seh' da keine große Verbesserung.
Habe ich mittlerweile leider auch bemerkt… ツ
Naja, der effizienteste Code ist nicht notwendigerweise der am leichtesten zu kapierende. Ich würde sogar sagen, das Gegenteil ist oft der Fall…
Möglich… ich persönlich finde es hilfreich…
@@Bimmelbeule
Fragen zum CSS-Flyout-Menü (ich habe das hier abgekupfert):
Selfhtml CSS Flyout Menü
Schade. Denn ein Ausklappmenü mit details
umzusetzen ist nicht so die beste Idee. Das funktioniert zwar irgendwie, mit Screenreadern aber nicht gut. Verwende die ebenfalls auf der Seite beschriebene Umsetzung mit Toggle-Button.
- Die verwendeten UTF-8 Zeichen
Es gibt keine „UTF-8-Zeichen“ (auch nicht ohne Deppenleerzeichen).
Zeichen gibt es in einem Zeichensatz. UTF-8 ist keiner, sondern eine Zeichencodierung. Du meinst: Unicode-Zeichen.
… "Hamburger" und "Multiplikation" werden auf dem Desktop und in Android einwandfrei dargestellt, aber im Ipad nicht (stattdessen ein Dreieck).
Nein, auch auf dem Desktop werden in Safari Dreiecke angezeigt.
Gibt es da einen Trick
Ja: ::marker
in Can I Use nachschlagen.
Bei Safari gibt’s da eine Fußnote. Dem Link zu 4.2. List Markers: the ::marker pseudo-element gefolgt: “The ::marker pseudo-element represents the automatically generated marker box of a list item.”
summary
ist kein list item.
- Ist das jetzt von der rudimentären Bedienung korrekt so?
Rudimentär? Vielleicht.
DOM und Semantik sollten jetzt stimmen
Nein.
Und wenn du die Umsetzung mit Toggle-Button machst, erledigt sich auch das mit den Dreiecken in Safari.
🖖 Живіть довго і процвітайте
@@Gunnar Bittersmann
Verwende die ebenfalls auf der Seite beschriebene Umsetzung mit Toggle-Button.
Aber nicht unbedingt so, wie im Wiki beschrieben. Die dortige Umsetzung ist nicht DRY (don’t repeat yourself), sondern WET (write everything twice). Sie verwendet zwei Dinge, die exakt dasselbe tun: den Zustand des Buttons anzuzeigen.
class
-Attribut is-active
wird gesetzt bzw. gelöschtaria-expanded
-Attribut wechselt zwischen "true"
und "false"
Das ist unsinning; eins genügt. Und das Eine ist das aria-expanded
-Attribut.
Anstatt des Klassenselektors .is-active
– der in CSS auch nur eine verkürzte Schreibweise des Attributselektors [class~="is-active"]
ist – lässt sich zum Stylen der Attributselektor [aria-expanded="true"]
verwenden.
🖖 Живіть довго і процвітайте
Hallo Gunnar,
Sei ein Pfadfinder und mach die Welt ein kleines bisschen besser 😉
Rolf
@@Gunnar Bittersmann
Fragen zum CSS-Flyout-Menü (ich habe das hier abgekupfert):
Selfhtml CSS Flyout MenüSchade. Denn ein Ausklappmenü mit
details
umzusetzen ist nicht so die beste Idee. Das funktioniert zwar irgendwie, mit Screenreadern aber nicht gut. Verwende die ebenfalls auf der Seite beschriebene Umsetzung mit Toggle-Button.
Dort steht aber extra: »Dieses Beispiel ist auch mit Tastatur und Screenreader benutzbar«.
Außerdem möchte ich kein Javascript auf meinen Seiten verwenden.
Gibt es da einen Trick
Danke!
DOM und Semantik sollten jetzt stimmen
Nein.
Ich habe jetzt die Navigation nach oben gesetzt und einen Skiplink angelegt, nachdem unter anderem du mir das in einem anderen Post nahe gelegt hast. Woran hapert es denn jetzt noch?
@@Bimmelbeule
Dort steht aber extra: »Dieses Beispiel ist auch mit Tastatur und Screenreader benutzbar«.
Nur weil das da steht, muss es ja nicht richtig sein.
Dass details
/summary
in Screenreadern irgendwie angesagt wird, heißt nicht, dass es für ein Hamburger-Menü richtig angesagt wird.
Es mag vielleicht „benutzbar“ sein. Das heißt aber nicht, dass das für Screenreader-Nutzer eine gute UX wäre.
Außerdem möchte ich kein Javascript auf meinen Seiten verwenden.
Warum nicht?
Und wenn nicht, dann möchtest du auf deinen Seiten keine Interaktion haben. Also auch kein Hamburger-Menü.
Wobei sich bei deinem Beispiel sowieso die Frage nach dem Warum stellt. Bei 4 Menüpunkten braucht man kein Hamburger-Menü; die kann man für alle anzeigen. Sind es auf deiner wirklichen Seite deutlich mehr Menüpunkte?
🖖 Живіть довго і процвітайте
@@Gunnar Bittersmann
Dort steht aber extra: »Dieses Beispiel ist auch mit Tastatur und Screenreader benutzbar«.
[…]
Es mag vielleicht „benutzbar“ sein. Das heißt aber nicht, dass das für Screenreader-Nutzer eine gute UX wäre.
Ich will kein Screenreader-UX-Wunder erstellen; ich will nur Screenreader- und Tastaturnutzern keine größeren Knüppel zwischen die Beine werfen… "benutzbar" reicht mir völlig!
Außerdem möchte ich kein Javascript auf meinen Seiten verwenden.
Warum nicht?
Ich möchte nichts auf meiner Website haben, von dem ich noch weniger verstehe als von HTML/CSS! ツ
Und wenn nicht, dann möchtest du auf deinen Seiten keine Interaktion haben. Also auch kein Hamburger-Menü.
Das Hamburger-Toggle-Menü habe ich nur gewählt, weil du die Erwartungskonformität ins Spiel gebracht hast (was ich auch einsehe; die meisten Websites lösen das so).
Es ist nicht möglich eine Website zu erstellen, die nur mit HTML/CSS auf allen Bildschirmgrößen brauchbar dargestellt und mit einer – wie auch immer gearteten – Navigation bedient werden kann?
Wobei sich bei deinem Beispiel sowieso die Frage nach dem Warum stellt. Bei 4 Menüpunkten braucht man kein Hamburger-Menü; die kann man für alle anzeigen.
Das ist eine Testseite! Ich fand es für die Fragestellung nicht erforderlich mehrere Unterseiten anzulegen.
Sind es auf deiner wirklichen Seite deutlich mehr Menüpunkte?
Ja, das soll mal eine Vorlage werden… und einige meiner Projekte haben deutlich mehr Menüpunkte (die alle zu Unterseiten führen)…
Hallo,
und einige meiner Projekte haben deutlich mehr Menüpunkte (die alle zu Unterseiten führen)…
wenn du eine Seitennavigation erstellst, ist es schon wichtig, wieviele Links du setzen willst, und ob es eine flache oder eine strukturierte Navigation werden soll. Ich glaube, scrollen im Menü ist keine gute Idee.
Hier https://wiki.selfhtml.org/wiki/JavaScript/Tutorials/zugängliche_Dropdown-Navigation kannst du sehen, wie man die Dreiecke beim Summary ersetzen kann.
Gruß
Jürgen
@@Bimmelbeule
Danke!
Nicht dafür.
Nochmal hingeschaut: Mit ::marker
machst du ja gar nichts. (Oder hast du den Code inzwischen geändert?)
Safari wendet list-style-type
nicht auf summary
an. Und da hilft es auch nicht, display: list-item
zu setzen. ☞ Codepen 1
Was ginge: Das Zeichen per summary::before
und den Marker ausblenden. Da für ::marker
nur ein paar bestimmte Eigenschaften gesetzt werden können, geht das nicht mit display: none
, wohl aber mit content: none
. (Dank an @klawischnigg für den Stups.) Im Safari mit proprietärem Pseudoelement ::-webkit-details-marker
, da geht dann display: none
. ☞ Codepen 2
Aber: Wenn man die Dreiecke gegen andere Zeichen austauschen will, ist das ein sicheres Indiz dafür, dass man gar nicht details
/summary
verwenden sollte.
Man könnte nun auf die Idee kommen, die Zeichen nicht per summary::before
, sondern per summary::marker
zu machen. Das scheitert allerdings daran, dass Safari auch @supports selector()
noch nicht unterstützt. ☞ Codepen 3
Erwähnte ich schon, dass wenn man die Dreiecke gegen andere Zeichen austauschen will, man gar nicht details
/summary
verwenden sollte?
🖖 Живіть довго і процвітайте
@@Bimmelbeule
Danke!
Nicht dafür.
Nochmal hingeschaut: Mit
::marker
machst du ja gar nichts.
Stimmt! Mist! Klappt ebenfalls nur für den Linux-Desktop und Android…
Was ginge: Das Zeichen per
summary::before
und den Marker ausblenden. Da für::marker
nur ein paar bestimmte Eigenschaften gesetzt werden können, geht das nicht mitdisplay: none
, wohl aber mitcontent: none
. (Dank an @klawischnigg für den Stubbs.)
(Linux)Desktop und Android machen es korrekt. Beim Safari (Ipad) ist der Hamburger jetzt zwar sichtbar, aber das Dreieck ebenfalls (oberhalb des Hamburgers: Aufm Ipad ist über dem Hamburger noch immer das Dreieck zu sehen
Im Safari mit proprietärem Pseudoelement
::-webkit-details-marker
, da geht danndisplay: none
.
Danke, aber Browser-Präfix möchte ich nicht verwenden…
@@Bimmelbeule
Beim Safari (Ipad) ist der Hamburger jetzt zwar sichtbar, aber das Dreieck ebenfalls (oberhalb des Hamburgers: Aufm Ipad ist über dem Hamburger noch immer das Dreieck zu sehen
Was nicht verwundern sollte, wenn du keine Anstalten machst, das Dreieck wegzubekommen.
Danke, aber Browser-Präfix möchte ich nicht verwenden…
Wenn du keine Anstalten machst, das Dreieck wegzubekommen, dann bleibt es eben da.
🖖 Живіть довго і процвітайте
Ich dachte, das mit content: none und display: none (mit zusätzlichen ::-webkit-details-marker), wären zwei unterschiedliche Möglichkeiten… da hatte ich wohl was falsch verstanden…
Okay, Toggle-Menü ist also erst mal gestrichen.
Was gibt es denn sonst noch für Möglichkeiten eine Navigation mit 8 bis 15 Links auf einem kleinen Bildschirm (Smartphone) zu erstellen? Ohne Javascript!
Hallo Bimmelbeule,
ohne JavaScript
Alle Punkte untereinander, und scrollen.
Eine fertige Komponente "flyout menü", nur mit Markup und CSS, gibt es vielleicht fertig zum einbinden, die nutzt dann aber auch JS und du bist auf direktem Weg zur Abhängigkeitshölle.
Rolf
@@Bimmelbeule
Ich dachte, das mit content: none und display: none (mit zusätzlichen ::-webkit-details-marker), wären zwei unterschiedliche Möglichkeiten… da hatte ich wohl was falsch verstanden…
Das hattest du wohl. summary::-webkit-details-marker { display: none }
ist der Polyfill für Safari, der summary::marker { content: none }
(die Angabe für andere Browser) nicht versteht.
Stimmt schon, experimentelle Pseudoelemente, Pseudoklassen, Eigenschaften und Werte mit Vendor-Präfix waren eigentlich nie dafür vorgesehen, produktiv verwendet zu werden. Aber wo sie nun mal da sind, warum verweigerst du dich, wenn das in einem Fall genau das Gewünschte tut, ohne schädliche Nebenwirkungen?
🖖 Живіть довго і процвітайте
@@Gunnar Bittersmann
Ich dachte, das mit content: none und display: none (mit zusätzlichen ::-webkit-details-marker), wären zwei unterschiedliche Möglichkeiten… da hatte ich wohl was falsch verstanden…
Das hattest du wohl.
summary::-webkit-details-marker { display: none }
ist der Polyfill für Safari, dersummary::marker { content: none }
(die Angabe für andere Browser) nicht versteht.
Stimmt! Läuft jetzt… nur das nach dem anwählen auf den IOS-Webkit-Browsern fette blaue Rahmen das Symbol oder main umschließen (so ähnlich wie es Chromium macht, wenn ich ihn auf meinem Linux-Desktop mit der Tastatur bediene)… das hatten sie aber bei meinen vorherigen Versuchen auch gemacht… hat das was mit dem summary-Konstrukt zu tun oder liegt das an was anderem?
Aber wo sie nun mal da sind, warum verweigerst du dich,
Weil ich mal befürchtet habe, das die Browser das irgendwann mal rausschmeißen werden… aber das ist Unsinn, sonst würde man ja viel mehr kaputte Seiten im Interweb sehen…
wenn das in einem Fall genau das Gewünschte tut, ohne schädliche Nebenwirkungen?
Du hast recht! Ich habe es jetzt eingebaut…
Hi,
Stimmt! Läuft jetzt… nur das nach dem anwählen auf den IOS-Webkit-Browsern fette blaue Rahmen das Symbol oder main umschließen (so ähnlich wie es Chromium macht, wenn ich ihn auf meinem Linux-Desktop mit der Tastatur bediene)… das hatten sie aber bei meinen vorherigen Versuchen auch gemacht… hat das was mit dem summary-Konstrukt zu tun oder liegt das an was anderem?
Meinst Du den Fokus-Rahmen, der markiert, welches Element gerade den Fokus hat? Wenn ja, hat das nix mit dem Summary-Konstrukt zu tun, sondern mit der Bedienbarkeit - woher soll der User sonst wissen, welches Element gerade ausgewählt ist?
cu,
Andreas a/k/a MudGuard
Meinst Du den Fokus-Rahmen, der markiert, welches Element gerade den Fokus hat? Wenn ja, hat das nix mit dem Summary-Konstrukt zu tun, sondern mit der Bedienbarkeit - woher soll der User sonst wissen, welches Element gerade ausgewählt ist?
Stimmt!
Habe gerade testweise summary und detail raus geschmissen… hatte nix mit dem Verhalten zu tun, da der auf dem IPad "nach oben" Button ebenfalls "main" blau einrahmt (wie schon zuvor)…
Chromium (Linux-Desktop) und Android-Browser verhalten sich "normal"…
Seltsames Verhalten… fände ich nur bei Tastaturbedienung sinnvoll… hat das vielleicht hiermit zu tun?
a:link,a:visited {
text-decoration:none;}
a:hover,a:focus {
text-decoration:underline;}
Update: Nee, das wars auch nicht…
@@Bimmelbeule
a:link,a:visited { text-decoration:none;} a:hover,a:focus { text-decoration:underline;}
Das ist eine sehr schlechte Idee. Wie sollen Nutzer denn erkennen, was ein Link ist, wenn Links nicht unterstrichen sind?
Grundregel: Verwende niemals Farbe als alleiniges Unterscheidungsmerkmal.
Bei einigen Links kannst du die Unterstreichung entfernen. Das bietet sich für die Links in einem Menü an, das als solches schon erkennbar ist.
Aber nicht bei allen! Links im Fließtext müssen ihre Unterstreichung behalten.
🖖 Живіть довго і процвітайте
Habe gerade testweise summary und detail raus geschmissen… hatte nix mit dem Verhalten zu tun, da der auf dem IPad "nach oben" Button ebenfalls "main" blau einrahmt (wie schon zuvor)…
Hat wohl doch was mit dem Summary/detail-Konstrukt zu tun…
Das Problem, das nach dem drücken des "nach oben" Buttons main blau umrahmt wird, konnte ich mit dem löschen von tabindex="-1"
aus dem Linkziel des skip-links beheben (Gunnar meinte ja eh, das dass mit tabindex="-1"
möglicherweise keine gute Idee war)…
Guten Morgen,
Fragen zum CSS-Flyout-Menü (ich habe das hier abgekupfert):
Selfhtml CSS Flyout Menü
- Kann man den HTML/CSS-Code noch weiter eindampfen, ohne Funktionalität zu verlieren (ich bin ein echtes Sparbrötchen, was Code angeht)?
Die Variante des CSS-Flyout-Menüs mit details wurde ja im April im Forum diskutiert und aufgrund mangelnder Zugänglichkeit verworfen. [1]
Habe eben (und schon mal im Mai) grad was von der Popup API der open-ui.org gehört und gesehen:
Das HTML-Markup ist wie im ersten Beispiel im Wiki; es fallen nur die popup
- und togglepopup
-Attribute auf.
<button togglepopup="pop">Toggle PopUp</button>
<div id="pop" popup>
And they're Rad! <span class="hand">🤙</span>
</div>
Wo ist der Witz? Die open-ui.org wollen die Lücke zwischen den „normalen“ HTML-Elementen und custom elements schließen, indem sie Lösungen für einzelne Probleme anbieten, die dann ohne JavaScript oder Framework direkt im Browser laufen.
In Chrome Canary geht das schon:
https://codepen.io/jh3y/pen/dymMYWR
Mal schauen, wann das in den anderen Browsern auftaucht. Evtl. wird es dann auch einen Polyfill geben und universell einsetzbar sein.
Diese Popups arbeiten mit light dismiss. Während details
mit einem Klick auf summary
geschlossen werden, geht hier auch [ESC] oder ein Klick irgendwo in die Webseite.
Im August (noch 3 Wochen!) werde ich den bestehenden Artikel ergänzen / glätten. Wer vorher will - nur zu!
Herzliche Grüße
Matthias Scharwies
SELF:Forum: Menü mit details und summary im Screenreader VoiceOver von Marc ↩︎
Hallo,
gibt es schon Erfahrung, wie sich diese Lösung in Vorlesebrowsern verhält?
Gruß
Jürgen
Servus!
Hallo,
gibt es schon Erfahrung, wie sich diese Lösung in Vorlesebrowsern verhält?
Bis jetzt noch nicht, mach die Abschlussarbeiten für's Schuljahr und werde Anfang August mal testen.
Ich habe außerhalb des Twitter-Tweets und dieser Webseite auch noch nie was von denen gehört.
Herzliche Grüße
Matthias Scharwies