nicht angemeldet
Auge
Gunnar Bittersmann
marctrix
JürgenB
Gunnar Bittersmann
Auge
hallo
Ich habe mich kürzlich etwas um die Möglichkeiten von <picture> <source> und srcset und sizes informiert.
Ich gestehe aber dass ich nicht leicht einen Nutzen daraus ziehen kann.
Ich würde lieber auf folgende Informationen reagieren können:
Wir wissen ja, dass die Gleichung Bildgrösse entspricht Dateigrösse, nicht immer stimmt. Je nach Einsatz ersetzen wir das eventuell eingesparte auch mit mehr Code-Noise.
Die Frage ist deshalb: Gibt es irgendwelche Methoden, an die zwei Informationen heranzukommen?
Meine Vorstellung wäre:
hallo
Ich habe mich kürzlich etwas um die Möglichkeiten von <picture> <source> und srcset und sizes informiert.
Ich gestehe aber dass ich nicht leicht einen Nutzen daraus ziehen kann.
Das ist auch nichts einfaches.
Ich würde lieber auf folgende Informationen reagieren können:
- Ich hänge an einem mobile net und mein Download-Volumen ist beschränkt.
- Ich bin mit einer leistungsschwanchen CPU ausgestattet.
Da geht's schon los. Denn soweit ich das weiß kommt man an diese Informationen gar nicht ran. Freilich könnte man mit JS die eine CPU heiß machen in dem man die ersten hundert Stellen von PI berechnet und dann mal schaut wie lange das gedauert hat... ich befürchte aber fast, dass würde vielen genau so "gut" gefallen wie wenn "erst mal ein paar Bitcoins durchgerechnet" werden.
Ich sehe auf manchen Seiten Buttons "Zur Desktop-Version wechseln". Ob die "mobile Ansicht" dann tatsächlich schlanker ist?
Auf Stackoverflow gefunden: Javascript: Detecting a mobile browser
Allerdings läuft das auf die im vorigen Jahrtausend propagierten "Browserweichen" hinaus, von denen man etwa seit der Jahrtausendwende weiß, dass das "nur beschränkt gute Ideen" sind. Für diejenigen, die es deutlicher ausgedrückt haben wollen: "Das ist Mist."
Meine Vorstellung wäre:
- setze ein Cookie und lass den Server darauf reagieren und alternative Ressourcen ausliefern.
Das funktioniert manchmal auch nur bis das Tablet oder Smartphone um 90° gedreht wird.
Aus meiner Sicht dürfte es also das beste und einfachste sein, die guten alten css-media-queries zu verwenden, ein paar Grundregeln zum responsiven Design zu beachten und ansonsten stets daran zu denken, dass eher schlanke Leute mit dem Auto und dem Fahrrad kompatibel sind.
hallo
Ich finde, wir denken da beide sehr ähnlich.
Wo ich Potential sehe ist:
Nachteile wären:
Da müsste ich nur noch eine sichere Detektion implementieren.
Weitere Nachteile?
Wo ich Potential sehe ist:
- Notiere data-src statt src.
Naja... das senkt die Zahl der Requests aber nicht die Datenmenge (+ca. 40%) oder den Stress für die CPU des Clients (wobei es natürlich ein Klacks ist, aus base64-ascii die binären Daten zu erzeugen).
Zudem kann man gerade im Zusammenhang mit media-queries einfacher auf andere Ressourcen verweisen wenn man im CSS url() verwendet.
Aber für Kleinkram in Button- oder Symbolgröße ist das (neben SVG und der Verwendung von "UTF-8-Symbolen" für "allerlei Häkchen und Telefone" aus den Schriftarten) durchaus eine Lösung.
hallo
Wo ich Potential sehe ist:
- Notiere data-src statt src.
Naja... das senkt die Zahl der Requests aber nicht die Datenmenge (+ca. 40%) oder den Stress für die CPU des Clients (wobei es natürlich ein Klacks ist, aus base64-ascii die binären Daten zu erzeugen).
Ich meine data-src als Attribut, nicht src="data:..."
Zudem kann man gerade im Zusammenhang mit media-queries einfacher auf andere Ressourcen verweisen wenn man im CSS url() verwendet.
Aber für Kleinkram in Button- oder Symbolgröße ist das (neben SVG und der Verwendung von "UTF-8-Symbolen" für "allerlei Häkchen und Telefone" aus den Schriftarten) durchaus eine Lösung.
Hallo
Wo ich Potential sehe ist:
- Notiere data-src statt src.
- Schreibe das Attribut erst um, wenn das Element auch in den Viewport gelangt.
Nachteile wären:
- noScript Usern wird ein Teil des Inhalte vorenthalten.
Das ließe sich ja umgehen, wenn man die URL einer verhältnismäßig kleinen Version des Bildes als Default-Wert im src-Attribut einträgt. Ein Bild sollte damit angezeigt werden. Ob das auf jedem Bildschirm ansehnlich aussieht, sei mal dahingestellt.
Da müsste ich nur noch eine sichere Detektion implementieren.
Hmm. Viel Spaß dabei …
Tschö, Auge
hallo
Freilich könnte man mit JS
dieeine CPU heiß machen in dem man die ersten hundert Stellen von PI berechnet und dann mal schaut wie lange das gedauert hat...
Mal unabhängig davon, es wäre gewiss ein eigenes Projekt den effizientesten Benchmark-Test zu machen, das heisst ein Optimum an Aussagekraft gegen Aufwand.
In unserem Fall ist ja nur wichtig die Grössenordnung zu erfahren. Kann das OS nur mit 10kb JS oder auch mit 100kB JS vernünftig umgehen?
@@Regina Schaukrug
Allerdings läuft das auf die im vorigen Jahrtausend propagierten "Browserweichen" hinaus, von denen man etwa seit der Jahrtausendwende weiß, dass das "nur beschränkt gute Ideen" sind. Für diejenigen, die es deutlicher ausgedrückt haben wollen: "Das ist Mist."
Und für diejenigen, die es noch deutlicher ausgedrückt haben wollen … ach, lassen wir das, sonst schweift der Thread ab in eine weitere Diskussion, welche Wörter hier anstößig sind …
Sagen wir: Das ist völlig unbrauchbar. Eine Browserweiche erkennt weder, wenn ein Smartphone im WLAN hängt, noch, wenn ein Laptop übers Smartphone im Mobilfunknetz hängt.
LLAP 🖖
Sagen wir: Das ist völlig unbrauchbar. Eine Browserweiche erkennt weder, wenn ein Smartphone im WLAN hängt, noch, wenn ein Laptop übers Smartphone im Mobilfunknetz hängt.
Und selbst das sagt ganz und gar nichts darüber aus, wie fix das Mobilfunknetz oder das WLAN sind. LTE ist manchmal sehr viel schneller als manches DSL und das WLAN kann das vom Smartphone sein, welches an manchen Bahnhöfen von $TELKO mit EDGE versorgt wird. (Dazwischen gar nicht.)
Dann wären da noch die Kosten und Limits... aber das hatten wir doch schon neulich. Die werden ja auch nicht zum Server "durchtelefoniert".
Würde man jetzt HTTP um einen Request-Header erweitern, mit dem schlanke Versionen von Webseiten angefordert würden, dann, so vermute ich mal, würden alsbald 60 bis 70% der Benutzer nach dem Lesen der "111 Tipps wie Ihr Computer 500% schneller wird" in den Tiefen der Konfiguration deren Browsers eine Option aktivieren, die diesen Header stets sendet. Für den Rest tun das die Administratoren, Distributoren oder die Android/IOS-Konfiguratoren.
Freilich könnte man den Durchsatz vor jeden Seitenaufruf mit einer Javascript-Version von iperf messen... (lachend wegduck)
@@Regina Schaukrug
Sagen wir: Das ist völlig unbrauchbar. Eine Browserweiche erkennt weder, wenn ein Smartphone im WLAN hängt, noch, wenn ein Laptop übers Smartphone im Mobilfunknetz hängt.
Und selbst das sagt ganz und gar nichts darüber aus, wie fix das Mobilfunknetz oder das WLAN sind. LTE ist manchmal sehr viel schneller als manches DSL und das WLAN kann das vom Smartphone sein
Ja, die eine Seite kann nicht wissen, wie es auf der anderen Seite des WLANs weitergeht.
Oder doch? Ein MacBook zeigt bei Verbindung zu einem WLAN allgemein das 
-Icon; bei Verbindung zum WLAN eines iPhones aber das 
-Icon oben in der Menüleiste.
LLAP 🖖
Hej Gunnar,
@@Regina Schaukrug
Ja, die eine Seite kann nicht wissen, wie es auf der anderen Seite des WLANs weitergeht.
Oder doch? Ein MacBook zeigt bei Verbindung zu einem WLAN allgemein das
Na ja, das ist ja eine Apple-interne Geschichte. Ich sag ja immer: so toll die Geräte alle für sich genommen sind, das gesamte Potential erschließt man sich erst, wenn man mehrere Apple-Geräte nutzt. Da ergeben sich Möglichkeiten, die kein anderes System besitzt.
Marc
Hej Regina,
ansonsten stets daran zu denken, dass eher schlanke Leute mit dem Auto und dem Fahrrad kompatibel sind.
Wo immer möglich handhabe ich es deshalb so. Ich erstelle ein jpg für alle.
Das Bild wird mindestens in der größten Auflösung bereit gestellt (bedenken, dass 1 CSS-Pixeln ggfs. 4 Hardware-Pixeln entspricht!).
Man komprimiert das Bild mit jpeg "bis es weh tut“, das heißt man schiebt den Regler für die Qualität so weit runter, bis erste Artefakte sichtbar werden, dann wieder ein bisschen zurück. Also eben so weit wie irgend möglich.
Man bindet dieses eine Bild für alle Geräte ein.
Wenn ich alles richtig verstanden habe, ist der Trick folgender. Das JPEG-Komprimierungsverfahren geht davon aus, dass zwei nebeneinander liegende Bildpunkte oft (fast) denselben Farbwert besitzen und fasst dann mehrere Pixel in eine Information zusammen, so dass eben nicht mehr für jeden einzelnen Pixel, sondern für Gruppen von Farbpixeln 24bit oder gar 32bit benötigt werden.
Die Annahme, dass nebeneinander liegende Pixel (fast) dieselbe Farbe haben, trifft auf ein größeres Bild wesentlich häufiger zu, als für ein kleineres Bild.
Dadurch lassen sich größere Bilder stärker komprimieren, als kleinere Bilder. Oft mit folgendem Effekt: das flächenmäßig größere benötigt Bild eine geringere Dateigröße.
Mir ist das ganz am Anfang meiner Beschäftigung mit RWD aufgefallen und ich wollte immer mal schauen, ob sich das verifizieren lässt, dann habe ich aber den Artikel Retina Revolution gefunden, den ich seither statt eines eigenen Textes immer verlinke. 😉
Matthias ApselpictureMarc
Hi Beat,
Auf den ersten Blick würde mir hierzu eine Proxylösung einfallen. Evntl. mit ICMP. Wobei dem Mobileé natürlich mitgeteilt werden muss daß es den Proxy verwenden soll.
MfG
hallo
Hi Beat,
Auf den ersten Blick würde mir hierzu eine Proxylösung einfallen. Evntl. mit ICMP. Wobei dem Mobileé natürlich mitgeteilt werden muss daß es den Proxy verwenden soll.
Das musst du mir schon erklären.
hallo
Hi Beat,
Auf den ersten Blick würde mir hierzu eine Proxylösung einfallen. Evntl. mit ICMP. Wobei dem Mobileé natürlich mitgeteilt werden muss daß es den Proxy verwenden soll.
Das musst du mir schon erklären.
ICMP: Damit kannst Du Inhalte austauschen. Z.B. große Bilder gegen kleine Bilder.
MfG
Hallo pl,
ICMP: Damit kannst Du Inhalte austauschen. Z.B. große Bilder gegen kleine Bilder.
Ist das ein selbst erfundener Begriff? ICMP ist bereits anderweitig belegt, in unserem Bereich meint man damit speziell das Internet Control Message Protocol.
LG,
CK
Ich meine natürlich ICAP sorry.
hallo
Hi Beat,
Auf den ersten Blick würde mir hierzu eine Proxylösung einfallen. Evntl. mit ICMP. Wobei dem Mobileé natürlich mitgeteilt werden muss daß es den Proxy verwenden soll.
Das musst du mir schon erklären.
ICMP: Damit kannst Du Inhalte austauschen. Z.B. große Bilder gegen kleine Bilder.
Das kann ich aber schon mit mod_rewrite sobald der Client mir nur eine nutzbare Information zukommen lässt.
hallo
Hi Beat,
Auf den ersten Blick würde mir hierzu eine Proxylösung einfallen. Evntl. mit ICMP. Wobei dem Mobileé natürlich mitgeteilt werden muss daß es den Proxy verwenden soll.
Das musst du mir schon erklären.
ICMP: Damit kannst Du Inhalte austauschen. Z.B. große Bilder gegen kleine Bilder.
Das kann ich aber schon mit mod_rewrite sobald der Client mir nur eine nutzbare Information zukommen lässt.
Genau. Z.B. ein HTTP_VIA.. (Proxy) Und ja, ich meinte natürlich ICAP. ICMP und Proxy macht ja keinen Sinn 😉
hallo
Das kann ich aber schon mit mod_rewrite sobald der Client mir nur eine nutzbare Information zukommen lässt.
Genau. Z.B. ein HTTP_VIA.. (Proxy) Und ja, ich meinte natürlich ICAP. ICMP und Proxy macht ja keinen Sinn 😉
Jetzt weiss ich aber immer noch nicht, wie ich über den proxie etwas über den Client erfahre.
Hallo beatovich,
Jetzt weiss ich aber immer noch nicht, wie ich über den proxie etwas über den Client erfahre.
Ich vermute, er hat den Sinn des ICAP-Protokolls missverstanden?
LG,
CK
hallo
Das kann ich aber schon mit mod_rewrite sobald der Client mir nur eine nutzbare Information zukommen lässt.
Genau. Z.B. ein HTTP_VIA.. (Proxy) Und ja, ich meinte natürlich ICAP. ICMP und Proxy macht ja keinen Sinn 😉
Jetzt weiss ich aber immer noch nicht, wie ich über den proxie etwas über den Client erfahre.
Es kommt darauf an daß er, der Client, den Proxy benutzt. Und da wird z.B. ICAP konfiguriert was für bestimmte REQUEST_URI die Bilder austauscht. Kein Proxy, kein ICAP.
Oder auf deinem Server: Da ist ein HTTP_VIA die Information daß ein Proxy den Request vermittelt.
Es gibt also mehrere Möglichkeiten. Und die Idee mit dem Proxy+ICAP ist ja so neu nun auch wieder nicht.
MfG
hallo
Jetzt weiss ich aber immer noch nicht, wie ich über den proxie etwas über den Client erfahre.
Nochwas. Clients von Hotspots sind i.d.R. Geräte die mit geringer Bandbreite auskommen müssen und kleine Bildschirms haben. Sie sind sozusagen des Proxies Clienteél. Von daher bedarf es keiner weiterer Bestimmung.
Die ganze Idee ist weder neu noch von mich. Wenn wir bessere Proxies hätten…
MfG
Hallo Beat,
bei Bildern etc. in Webseiten sollte man an drei Dinge denken:
Gruß
Jürgen
hallo
Hallo Beat,
bei Bildern etc. in Webseiten sollte man an drei Dinge denken:
- Wie groß in Pixeln muss das Bild wirklich sein? Hier können Mediaqueries oder srcset helfen.
Ja klar kann ich mindestens einen Deckel schaffen. Das ist schon klar. Nur sagen media-queries absolut nichts zu den anderen viel wichtigeren Faktoren.
Kommt hinzu, dreht jemand sein Mobile wird er eventuell dafür bestraft!
- Das Bild sollte im richtigen Datenformat ausgeliefert werden. jpeg passt nicht auf alles, gerade komprimiert ausgeliefertes svg kann da gute Qualität bei kleinen Dateien liefern.
SVG ist nur gut für Animationen. Ich habe aber bisher noch immer Grund gefunden, png svg vorzuziehen.
- Die Bilder sollten ordentlich komprimiert werden. Das Komprimieren belastet die CPU des Kompressors einmal.
Du meinst, SVG sollte ordentlich komprimiert werden.
Ich will die Dinger mal endlich kleiner als meine pngs bekommen. Aber da muss ich mich wohl auf das zeichnen von Quadraten beschränken.
Um SVG klein zu bekommen, musst du auf das Koordinatensystem achten! Und das kann ein Mordsaufwand werden.
Hallo beatovich,
- Das Bild sollte im richtigen Datenformat ausgeliefert werden. jpeg passt nicht auf alles, gerade komprimiert ausgeliefertes svg kann da gute Qualität bei kleinen Dateien liefern.
SVG ist nur gut für Animationen. Ich habe aber bisher noch immer Grund gefunden, png svg vorzuziehen.
????
LG,
CK
hallo
Hallo beatovich,
- Das Bild sollte im richtigen Datenformat ausgeliefert werden. jpeg passt nicht auf alles, gerade komprimiert ausgeliefertes svg kann da gute Qualität bei kleinen Dateien liefern.
SVG ist nur gut für Animationen. Ich habe aber bisher noch immer Grund gefunden, png svg vorzuziehen.
????
- Skalierbarkeit ohne Qualitätsverluste
Auf dem Retina-display hast du da gegenüber Pixel-Grafiken sicher einen Vorteil.
Hej beatovich,
SVG
- Skalierbarkeit ohne Qualitätsverluste
Auf dem Retina-display hast du da gegenüber Pixel-Grafiken sicher einen Vorteil.
Nein. Wenn die Pixel-Grafik groß genug ist (bei Retina-Displays sollte die Auflösung das Vierfache der in CSS-Pixeln angegebenen Größe entsprechen), ist das kein Vorteil. Aber die anderen Vorteile von SVGs reichen ja aus!
Um das mal anschaulich zu machen:
Bild mit Vier Pixeln (2x2) auf einem Retina-Display:
CSS:
img {
width: 1px;
height: 1px;
}
Darstellung auf dem Handy: 2x2 Hardware-Pixel. Grund: würde ein CSS-Pixel einem Hardware-Pixel entsprechen, dann wären alle Schriften unlesbar klein.
Das CSS oben führt dazu, dass Höhe und Breite des Bildes einem sechzehntel em entspricht, wenn 1em mit 16px festgelegt ist.
Marc
hallo
Hej beatovich,
SVG
- Skalierbarkeit ohne Qualitätsverluste
Auf dem Retina-display hast du da gegenüber Pixel-Grafiken sicher einen Vorteil.
Nein. Wenn die Pixel-Grafik groß genug ist (bei Retina-Displays sollte die Auflösung das Vierfache der in CSS-Pixeln angegebenen Größe entsprechen), ist das kein Vorteil. Aber die anderen Vorteile von SVGs reichen ja aus!
Um das mal anschaulich zu machen:
Bild mit Vier Pixeln (2x2) auf einem Retina-Display:
CSS:
img { width: 1px; height: 1px; }
Ich sehe keinen Sinn darin einem Samsung Galaxi S7 die 16fache Pixelmenge zu füttern, nur weil es das darstellen kann. (ja ich weiss, das heisst nicht 16-fache Datenmenge)
Was ich hingegen akzeptiere ist, dass durch die einsetzende Verkleinerung von Bildern (max-width:100%) die Information pro Screen-Pixel erhöht wird, manchmal bis zum Faktor 2.
Hej beatovich,
Bild mit Vier Pixeln (2x2) auf einem Retina-Display:
CSS:
img { width: 1px; height: 1px; }Ich sehe keinen Sinn darin einem Samsung Galaxi S7 die 16fache Pixelmenge zu füttern, nur weil es das darstellen kann. (ja ich weiss, das heisst nicht 16-fache Datenmenge)
16fach - was für eine physikalische Auflösung hat ein S7 denn?
Und wenn du keinen Sinn darin siehst, kann dir dein Designer vielleicht erklären, warum man neben Text mit 458 ppi (iPhone X) kein Bild mit 72dpi setzen sollte…
Oder du liest den Retina Revolution Artikel…
Marc
hallo
Hej beatovich,
Bild mit Vier Pixeln (2x2) auf einem Retina-Display:
CSS:
img { width: 1px; height: 1px; }Ich sehe keinen Sinn darin einem Samsung Galaxi S7 die 16fache Pixelmenge zu füttern, nur weil es das darstellen kann. (ja ich weiss, das heisst nicht 16-fache Datenmenge)
16fach - was für eine physikalische Auflösung hat ein S7 denn?
Faktor 4 in einer Dimension laut Firefox bildschirmsmulation
Und wenn du keinen Sinn darin siehst, kann dir dein Designer vielleicht erklären, warum man neben Text mit 458 ppi (iPhone X) kein Bild mit 72dpi setzen sollte…
96dpi
Ja ich sehe das Argument ein, wenn das Bild eine hohe Informationsdichte haben soll. Aber da suche ich zuerst nach geeigneten Unicode Glyphen.
Hej beatovich,
Ja ich sehe das Argument ein, wenn das Bild eine hohe Informationsdichte haben soll. Aber da suche ich zuerst nach geeigneten Unicode Glyphen.
Die ja auch nichts anderes sind als skalierbare Grafiken - insofern tun es auch die SVGs aus einer der (oft kostenlos verfügbaren) Bibliotheken. Dann hat man noch mehr Auswahl und noch mehr Gestaltungsmöglichkeiten (per CSS) — und muss sich um die Probleme von SR-Nutzern nicht kümmern, bzw. kann sich darum weit detaillierter kümmern, als mit Unicode-Glyphen.
Ansonsten: Hier ging es mir nur um Bilder (beispielsweise Fotos), für die Unicode-Glyphen oder SVGs ungeeignet sind.
Denn wenn die geeignet sind, ist SVGs immer Vorfahrt einzuräumen. 😉
Marc
Hallo Beat,
Um SVG klein zu bekommen, musst du auf das Koordinatensystem achten! Und das kann ein Mordsaufwand werden.
mit Komprimieren meine ich GZIP o.Ä. vor/bei der Auslieferung, wie bei html etc..
Gruß
Jürgen
@@JürgenB
Ich habe mal für den MAC ein freies Programm gefunden (leider habe den Namen vergessen), dass für ein jpeg über eine Sekunde auf einem I5 benötigt und die Dateigröße auf ein zehntel verringert ohne sichtbare Qualitätseinbuße.
Meinst du ImageOptim?
LLAP 🖖
@@beatovich
Ich würde lieber auf folgende Informationen reagieren können:
- Ich hänge an einem mobile net und mein Download-Volumen ist beschränkt.
Was zwei völlig verschiedene Dinge sind. Manche haben ein Mobilfunkvertrag mit Flatrate so großem Datenvolumen, dass sie kaum an die Grenze stoßen. Andere haben Festnetzverträge mit beschränktem Datenvolumen.
- Ich bin mit einer leistungsschwanchen CPU ausgestattet.
Woraus sich wieder völlig andere Konsequenzen ergeben. Bei leistungsschwacher CPU möchte man Texte und Bilder nicht dekomprimieren müssen, sondern Texte unkomprimiert und Bilder als Bitmap übertragen, was Bandbreite und Datenvolumen entgegensteht.
Auf das alles reagieren zu wollen heißt, brauchbare Kompromisse zu finden.
LLAP 🖖
hallo
@@beatovich
Ich würde lieber auf folgende Informationen reagieren können:
- Ich hänge an einem mobile net und mein Download-Volumen ist beschränkt.
Was zwei völlig verschiedene Dinge sind. Manche haben ein Mobilfunkvertrag mit
Flatrateso großem Datenvolumen, dass sie kaum an die Grenze stoßen. Andere haben Festnetzverträge mit beschränktem Datenvolumen.
Sicher. Die entscheidende Angabe vom Browser via http header wäre eben so was
Ideal-response-max: 200kb
- Ich bin mit einer leistungsschwanchen CPU ausgestattet.
Woraus sich wieder völlig andere Konsequenzen ergeben. Bei leistungsschwacher CPU möchte man Texte und Bilder nicht dekomprimieren müssen, sondern Texte unkomprimiert und Bilder als Bitmap übertragen, was Bandbreite und Datenvolumen entgegensteht.
und vor allem vermeidbare JS-Komponenten weglassen. Auch hier gilt, was ich erst gar nicht downloade, muss auch nicht dekomprimiert werden.
Hallo
- Ich hänge an einem mobile net und mein Download-Volumen ist beschränkt.
Was zwei völlig verschiedene Dinge sind. Manche haben ein Mobilfunkvertrag mit
Flatrateso großem Datenvolumen, dass sie kaum an die Grenze stoßen. Andere haben Festnetzverträge mit beschränktem Datenvolumen.Sicher. Die entscheidende Angabe vom Browser via http header wäre eben so was
Ideal-response-max: 200kb
Und woher weiß der Browser das? Der kann aktuell ja bestenfalls feststellen, ob die Internetverbindung über LAN, WLAN oder Mobilfunk besteht (wenn überhaupt). Kann der aber die Geschwindigkeit der aktuellen Verbindung messen/beurteilen? Kann der die statischen oder zeit- oder volumenabhängigen Preise der Verbindung messen/beurteilen?
Wollte ich, wenn sowas im Browser implementiert würde, dem diese Infos, die er notwendigerweise in alle Welt hinausposaunen würde, zugänglich machen?
- Ich bin mit einer leistungsschwanchen CPU ausgestattet.
Woraus sich wieder völlig andere Konsequenzen ergeben. Bei leistungsschwacher CPU möchte man Texte und Bilder nicht dekomprimieren müssen, sondern Texte unkomprimiert und Bilder als Bitmap übertragen, was Bandbreite und Datenvolumen entgegensteht.
und vor allem vermeidbare JS-Komponenten weglassen. Auch hier gilt, was ich erst gar nicht downloade, muss auch nicht dekomprimiert werden.
… und, was aktive Inhalte betrifft, auch nicht ausgeführt werden.
Tschö, Auge
hallo
Hallo
- Ich hänge an einem mobile net und mein Download-Volumen ist beschränkt.
Was zwei völlig verschiedene Dinge sind. Manche haben ein Mobilfunkvertrag mit
Flatrateso großem Datenvolumen, dass sie kaum an die Grenze stoßen. Andere haben Festnetzverträge mit beschränktem Datenvolumen.Sicher. Die entscheidende Angabe vom Browser via http header wäre eben so was
Ideal-response-max: 200kb
Und woher weiß der Browser das? Der kann aktuell ja bestenfalls feststellen, ob die Internetverbindung über LAN, WLAN oder Mobilfunk besteht (wenn überhaupt). Kann der aber die Geschwindigkeit der aktuellen Verbindung messen/beurteilen? Kann der die statischen oder zeit- oder Volumenabhänigen Preise der Verbindung messen/beurteilen?
Das müsste schon der Browseruser selber entscheiden.
Wollte ich, wenn sowas im Browser implementiert würde, dem diese Infos, die er notwendigerweise in alle Welt hinausposaunen würde, zugänglich machen?
Wenn die information so geartet ist, dass sie wenig nutzbare Daten für's Profiling bietet, ist da kein Problem.
Aber deinem Argument nach folgere ich, dass du keine Plugins benutzt. Die eigenen sich nämlich wunderbar fürs Profiling.
Hallo
Die entscheidende Angabe vom Browser via http header wäre eben so was
Ideal-response-max: 200kb
Und woher weiß der Browser das? Der kann aktuell ja bestenfalls feststellen, ob die Internetverbindung über LAN, WLAN oder Mobilfunk besteht (wenn überhaupt). Kann der aber die Geschwindigkeit der aktuellen Verbindung messen/beurteilen? Kann der die statischen oder zeit- oder Volumenabhänigen Preise der Verbindung messen/beurteilen?
Das müsste schon der Browseruser selber entscheiden.
Nun ja, dem würde ich nur ein „vergiss es“ entgegnen wollen. Nur die allerwenigsten Benutzer würden das konfigurieren, also würde spätestens die Frage nach zeit- oder volumenbasierten Abrechnungen meist ins Leere laufen.
Wollte ich, wenn sowas im Browser implementiert würde, dem diese Infos, die er notwendigerweise in alle Welt hinausposaunen würde, zugänglich machen?
Wenn die information so geartet ist, dass sie wenig nutzbare Daten für's Profiling bietet, ist da kein Problem.
Gehst du davon aus, dass eine solche Funktion datensparsam implementiert würde? Ich nicht.
Aber deinem Argument nach folgere ich, dass du keine Plugins benutzt. Die eigenen sich nämlich wunderbar fürs Profiling.
Das kommt auf die PlugIns/AddOns an.
Tschö, Auge
hallo
Nun ja, dem würde ich nur ein „vergiss es“ entgegnen wollen. Nur die allerwenigsten Benutzer würden das konfigurieren, also würde spätestens die Frage nach zeit- oder volumenbasierten Abrechnungen meist ins Leere laufen.
Erst mal müssten wir uns einigen, in welcher Stufe eine Kontrolle überhaupt sinnvoll ist.
uMatrix unterdrückt requests. Aber uMatrix hat keine Information über die Bildgrösse, kann also nicht entscheiden.
Die nächste Stufe ist der Server. Dieser kann optional auf einen Header reagieren.
Gehst du davon aus, dass eine solche Funktion datensparsam implementiert würde? Ich nicht.
Tja, wir haben da notorische Erfahrung, aber ja, ich denke, es kann eine datensparsame Information beschrieben werden. Der header ist ja nicht verpflichtend sondern beratend, so wie das auch für language Negotiation gilt. In diesem Fall ist die Information noch viel einfacher.
Hallo
Nun ja, dem würde ich nur ein „vergiss es“ entgegnen wollen. Nur die allerwenigsten Benutzer würden das konfigurieren, also würde spätestens die Frage nach zeit- oder volumenbasierten Abrechnungen meist ins Leere laufen.
Erst mal müssten wir uns einigen, in welcher Stufe eine Kontrolle überhaupt sinnvoll ist.
…
Die nächste Stufe ist der Server. Dieser kann optional auf einen Header reagieren.
Hier geht's ja darum, auf Basis welcher Daten ein Browser einen solcher Header generieren sollte. Aus Messungen der Geschwindigkeit von Antworten auf Anfragen in der nahen Vergangenheit auf die vermutliche aktuelle Verbindungsgeschwindigkeit zu schließen, geht. Die Punkte Verbindungsart (LAN, WLAN, Mobilfunk (mit seinen sehr unterschiedlichen Geschwindigkeiten je naqch System)) und Tarife, sind aktuell nicht ermittelbar. Die Informationen für den Browser lesbar zu hinterlegen, ließe sich wohl für den Punkt Netzwerk automatisieren, für den Punkt Tarife wohl nicht. Da in meinem Szenario nur die wenigsten Benutzer soetwas selbst konfigurieren, bliebe diese Informationsquelle auf der Strecke.
Gehst du davon aus, dass eine solche Funktion datensparsam implementiert würde? Ich nicht.
Tja, wir haben da notorische Erfahrung, aber ja, ich denke, es kann eine datensparsame Information beschrieben werden. Der header ist ja nicht verpflichtend sondern beratend, so wie das auch für language Negotiation gilt. In diesem Fall ist die Information noch viel einfacher.
Wenn du von deinem ursprünglichen Ideal-response-max: 200kb ausgehst, ja. Wie gut das funktionieren würde, wäre herauszufinden.
Tschö, Auge
@@Auge
Kann der aber die Geschwindigkeit der aktuellen Verbindung messen/beurteilen?
Der aktuellen nicht; aber der in den letzten paar Minuten – und daraus auf die aktuelle Verbindung schließen.
Er kann sich dabei irren, aber oft ist eine Schätzung besser als gar kein Wert. “Nobody’s perfect.”
LLAP 🖖
hallo
Dieser Thread hat dazu geführt, dass ich meine bisherige png-Spritemap zu einer SVG konvertiert habe.
Dabei konnte ich noch ein paar Features einbauen.
Die Dateigrösse wird wohl nicht besonders profitieren. Entscheidend aber ist die Skalierbarkeit. Die Unterschiede in der Anzeigeschärfe kann man hier vergleichen:
https://beat-stoecklin.ch/pub/website-docu.html
Bedeutsam ist auch, dass ich mir in einer SVG einfach Platz für zukünftige Icons freihalten kann.
Als Bonus habe ich mit Kombination von Background und ::before{content:""} experimentiert, was natürlich die Zahl der verfügbaren Icons explodieren lässt.
Stolz bin ich auch auf den Umgang mit den Dimensionen. Einzelne Icons holt man über ganze em Schritte.
Zur Experimentier-Bastelbude geht's hier:
https://beat-stoecklin.ch/pub/webdesign_responsive_bilder.html
hallo
Kleiner Anhang
SVG kann auch Spass machen. Ich habe nun über mehrere Tage immer wieder kleine Details an der Spritemap geändert oder ergänzt, oder Icons in symbol Elmente konvertiert und sie mehrfach wiederverwendet.
Eine SVG Spritemap ist, verglichen zur Pixelkonkurrenz, viel mehr Work in Prozess.
Voraussetzung ist aber, dass man im CSS alle background-position Werte mit negativen Koordinaten angibt. So lassen sich viewboxen einfach erweitern, ohne dass man bisherige CSS Koordinaten korrigieren muss.
nur eines macht mir im Moment Kopfzerbrechen.
<span class="icon arrow"></span>
ist eigentlich der übliche Ansatz.
<ul class="icon anyicon">
<li>item</li>
</ul>
Wie schaffe ich es, dass die Eigenschaften nun nicht auf ul angewendet werden, sondern li::before, ohne dass ich für jedes icon einen eigenen Selektor definieren muss?
Das bisherige CSS ist
.icon::before {
font-size:1.25em; font-size-adjust:0.3; line-height:1;
content: "";
width: 1em; height: 1em;
margin:-0.2em 0.2em;
display: inline-block;
text-align:center;
text-indent:0;
background-image: url("'+_.guiSpritemapUri+'");
background-size: 12em;
transition:all 0.4s ease;
background-position: 1em 0em;
}
a[href^="kontakt.html"]::before,
.icon.at::before { background-position: 0em 0em; }
.icon.menu::before { background-position: -1em 0em; }
/* sehr viele icons mit Koordinaten */
/* ... */
.icon[data-before]::before { content:attr(data-before); }
.icon[data-content]::before { content:attr(data-content); }
a:hover::before, a:focus::before,\
.icon:hover::before, .icon:focus::before { transform:scale(1.4); }
Wer weiss Rat?
Hallo beatovich,
<span class="icon arrow"></span>
So ist es jetzt?
<ul class="icon anyicon"> <li>item</li> </ul>
So soll es werden?
Wie schaffe ich es, dass die Eigenschaften nun nicht auf ul angewendet werden, sondern li::before, ohne dass ich für jedes icon einen eigenen Selektor definieren muss?
ul.icon > li::before {
/* was allen gemeinsam ist */
}
ul.thisicon > li::before {
background-position: -1em -1em;
}
ul.othericon > li::before {
background-position: -2em -1em;
}
Oder habe ich dich falsch verstanden?
Bis demnächst
Matthias
hallo
Hallo beatovich,
<span class="icon arrow"></span>So ist es jetzt?
<ul class="icon anyicon"> <li>item</li> </ul>So soll es werden?
Wie schaffe ich es, dass die Eigenschaften nun nicht auf ul angewendet werden, sondern li::before, ohne dass ich für jedes icon einen eigenen Selektor definieren muss?
ul.icon > li::before { /* was allen gemeinsam ist */ } ul.thisicon > li::before { background-position: -1em -1em; } ul.othericon > li::before { background-position: -2em -1em; }Oder habe ich dich falsch verstanden?
Ganz und gar nicht...
Ich habe nur mein Anliegen zuwenig klar ausgedrückt 😉
Ich möchte jetzt nicht für jedes Icon (ide spritemap position) einen neuen Selektor definieren, sondern eine Art catch all finden
Eine Icon-Klasse besteht immer aus "icon some other keywords".
Ich habe da mit inherit experimentiert, finde aber, dass das bei ::before nicht mehr so funzt. Geerbt wird ja vom eigenen Element.
hallo
ich habe das Problem erkannt!
ul.icon li,
ul.icon li::before{
background-position-x: inherit;
background-position-y: inherit;
}
Damit erbe ich zwar die Koordinaten, aber die font-size Angabe macht mir einen Strich durch die Rechnung da
.icon::before {font-size:1.25em}
eine Verzerrung einführt. Bei font-size:1em gibts kein Problem.
Ich möchte aber diese Angabe variabel behalten.
Hallo beatovich,
Damit erbe ich zwar die Koordinaten, aber die font-size Angabe macht mir einen Strich durch die Rechnung da
.icon::before {font-size:1.25em}eine Verzerrung einführt.
Ich möchte aber diese Angabe variabel behalten.
Hast du schon versucht, mit background-size das Hintergrundbild entsprechend anzupassen?
Bis demnächst
Matthias
hallo
Hallo beatovich,
Damit erbe ich zwar die Koordinaten, aber die font-size Angabe macht mir einen Strich durch die Rechnung da
.icon::before {font-size:1.25em}eine Verzerrung einführt.Ich möchte aber diese Angabe variabel behalten.
Hast du schon versucht, mit
background-sizedas Hintergrundbild entsprechend anzupassen?
Kann ich machen, aber dann sind die Endergebnisse nicht mehr berechenbar.
Derzeit habe ich ein konsistentes Icon-Grössenverhalten nur auf der Basis der font-size, das ich auch einfach auf Bedarf anpassen kann.
Hallo beatovich,
Hast du schon versucht, mit
background-sizedas Hintergrundbild entsprechend anzupassen?Kann ich machen, aber dann sind die Endergebnisse nicht mehr berechenbar.
Sollte es nicht reichen, das Hintergrundbild um denselben Faktor zu vergrößern wie die Schriftgröße?
Bis demnächst
Matthias
hallo
Hallo beatovich,
Hast du schon versucht, mit
background-sizedas Hintergrundbild entsprechend anzupassen?Kann ich machen, aber dann sind die Endergebnisse nicht mehr berechenbar.
Sollte es nicht reichen, das Hintergrundbild um denselben Faktor zu vergrößern wie die Schriftgröße?
Ich muss derzeit gar keine background-size Änderung vornehmen, auch wenn ich font-size ändere. width und height von ::before sind direkt von font-size abgeleitet.
Und nein, für einen User ist es nicht sinnvoll, mehr als eine Eigenschaft anzufassen, wenn er ein Icon vergrössern will.
Nochmals das CSS mit Kommentaren
.icon::before {\
font-size:1.25em; font-size-adjust:0.3; line-height:1;\
content: "";\
width: 1em; height: 1em;\
margin:-0.2em 0.2em;\
display: inline-block;\
text-align:center;\
text-indent:0;\
background-image: url("'+_.guiSpritemapUri+'");\
background-size: 12em;\ /* 12 icons pro Rasterzeile */
transition:all 0.4s ease;\
background-position: 1em 0em; /* icons werden über ganzahlige em Werte ausgewält */
}\
Hej beatovich,
an deiner Stelle würde ich nicht versuchen, das Rad neu zu erfinden. Es gibt doch allerhand Ansätze und beispielsweise auch css-Tricks ein ganzes Dutzend Artikel dazu.
Ich habe das mal auf deutsch in eigenen Worten zusammengefasst. Die ganzen Links gehen dann auf englischsprachige Artkel.
Vielleicht hilft es ja.
Falls das zu lang ist: wenn es nicht zu viele icons werden setze ich die inline ein, dann kann hat man die meisten Gestaltungsmöglichkeiten per css und es werden keine zusätzlichen http-requests benötigt. Bei dateigrößen unter 1kbyte üblicher icons geht das schneller als caching.
Hier der Artikel:
SVG – einfach, flexibel, schnell und robust!
Über gefundene Fehler freue mich, werde die gern korrigieren!
Marc
hallo
Hej beatovich,
Hier der Artikel:
SVG – einfach, flexibel, schnell und robust!
Über gefundene Fehler freue mich, werde die gern korrigieren!
hmm ich habe ein
<element class="icon some other class names">
Das soll auf jedwelche Form von Icons passen, nicht bloss auf svg.
Gerade icon-libs sollen ja austauschbar bleiben.
Hej beatovich,
Hier der Artikel:
SVG – einfach, flexibel, schnell und robust!
Über gefundene Fehler freue mich, werde die gern korrigieren!
hmm ich habe ein
<element class="icon some other class names">
Das soll auf jedwelche Form von Icons passen, nicht bloss auf svg.
Wozu würde man heute noch etwas anderes als SVGs für icons verwenden?
Gerade icon-libs sollen ja austauschbar bleiben.
Wenn du semantische Klassen hast, ist das kein Problem.
Für eine eventuelle Abstraktionsebene könnte man vielleicht einen präprozessor bemühen. Wenn man das denn will (ich eher nicht).
Marc
hallo
Wozu würde man heute noch etwas anderes als SVGs für icons verwenden?
Weil so und soviele Spritemaps noch eingesetzt werden?
Gerade icon-libs sollen ja austauschbar bleiben.
Wenn du semantische Klassen hast, ist das kein Problem.
Kannst du hier nachschauen, wie das aktuell umgesetzt ist.
https://beat-stoecklin.ch/pub/website-docu.html
Für eine eventuelle Abstraktionsebene könnte man vielleicht einen präprozessor bemühen. Wenn man das denn will (ich eher nicht).
Kommt nicht in Frage KISS
Hej beatovich,
Wozu würde man heute noch etwas anderes als SVGs für icons verwenden?
Weil so und soviele Spritemaps noch eingesetzt werden?
SVG ist ein Dateiformat, Sprites sind ein Konzept, das als SVG abgespeichert werden kann.
Wieso tust du, als ob sich die beiden ausschließen?
Gerade icon-libs sollen ja austauschbar bleiben.
Wenn du semantische Klassen hast, ist das kein Problem.
Kannst du hier nachschauen, wie das aktuell umgesetzt ist.
Das hast du doch schon gepostet…
Für eine eventuelle Abstraktionsebene könnte man vielleicht einen präprozessor bemühen. Wenn man das denn will (ich eher nicht).
Kommt nicht in Frage KISS
Und Präprozessoren widersprechen dem?
Marc
hallo
KISS
Und Präprozessoren widersprechen dem?
Welchen hast du im Sinn?
Hej beatovich,
KISS
Und Präprozessoren widersprechen dem?
Welchen hast du im Sinn?
Du bist unhöflich, denn das ist keine Antwort.
Quid pro quo. 😉
Darüberhinaus liegt es mir fern, dir ein bestimmtes Werkzeug vorzuschreiben.
Marc
@@beatovich
Dieser Thread hat dazu geführt, dass ich meine bisherige png-Spritemap zu einer SVG konvertiert habe.
Und das hast du wie gemacht? Die Sprites nebeneinander gepackt und ausgewählt werden sie über jeweils über ihre background-position? Kann man so machen, das ist dann halt Kac führt dann halt zu Problemen.
Wie man SVG-Icons verwendet, hatte ich doch kürzlich erst lang und breit erklärt:
LLAP 🖖
hallo
@@beatovich
Dieser Thread hat dazu geführt, dass ich meine bisherige png-Spritemap zu einer SVG konvertiert habe.
Und das hast du wie gemacht? Die Sprites nebeneinander gepackt und ausgewählt werden sie über jeweils über ihre
background-position? Kann man so machen, dasist dann halt Kacführt dann halt zu Problemen.
background-positioning hat erstmal nichts mit dem verwendeten Grafik-Format zu tun.
Wie man SVG-Icons verwendet, hatte ich doch kürzlich erst lang und breit erklärt:
Ich stehe also vor der Wahl..
<element class="icon kacke">...</element>
oder
<element><svg><use xlink:href="icons.svg#kacke"></svg>...</element>
Für Einzelbilder, die gleichzeitig Content darstellen, habe ich kein Problem mit Variante 2.
Hej @@beatovich
Ich stehe also vor der Wahl..
<element class="icon kacke">...</element> oder <element><svg><use xlink:href="icons.svg#kacke"></svg>...</element>
Oder inline-SVGs
Für Einzelbilder, die gleichzeitig Content darstellen, habe ich kein Problem mit Variante 2.
Damit macht man sicherlich am wenigsten falsch, wenn man darauf achtet, dass alle durch das Bild transportierten Informationen auch ohne zugänglich sind. — @@Gunnar Bittersmann - erlaubt die use-Variante eigentlich das title-Element (kann für Screenreader-Ausgabe genutzt werden).
Marc
@@marctrix
erlaubt die use-Variante eigentlich das
title-Element
Ja. Im Prizip schon.
<svg style="display: none">
<symbol id="circle" viewBox="-1 -1 2 2">
<circle r="1"/>
</symbol>
<symbol id="circle-with-title" viewBox="-1 -1 2 2">
<title>symbol title</title>
<circle r="1"/>
</symbol>
</svg>
<a href="">
<svg fill="var(--red, red)"><use href="#circle-with-title"/></svg>
</a>
<a href="" title="link title">
<svg fill="var(--yellow, yellow)"><use href="#circle"/></svg>
</a>
<a href="" title="link title">
<svg fill="var(--green, green)"><use href="#circle-with-title"/></svg>
</a>
Chrome zeigt beim roten Licht „symbol title“ als Tooltip an; beim gelben „link title“ und beim grünen gewinnt „symbol title“.
Firefox zeigt beim roten Licht keinen Tooltip an, beim gelben „link title“ und beim grünen dann natürlich auch „link title“.
Safari zeigt keine Lichter‽ WTF‽
Zum Ausprobieren: Codepen
(kann für Screenreader-Ausgabe genutzt werden).
Mag da mal jemand in Screenreadern testen, ob die titles vorgelesen werden? Inbesondere das aus dem symbol-Element, welches nicht als Tooltip angezeigt wird?
LLAP 🖖
@@Gunnar Bittersmann
Safari zeigt keine Lichter‽ WTF‽
Safari, du Drecksbrowser!
Was in Safari nicht geht: <svg><use href="#foo"/></svg>
Was geht: <svg><use xlink:href="#foo"/></svg> Das Attribut muss für Safari einfach mal xlink:href heißen.
Und das hat rein gar nichts mit XML-Namensräumen zu tun. Browser verarbeiten HTML nicht mit XML-Parser; so etwas wie Namensräume gibt es nicht. Ansonsten müsste es ja auch so gehen:
<svg xmlns:x="http://www.w3.org/1999/xlink"><use x:href="#foo"/></svg> (Namensräume kann man in XML ja schließlich benennen wie mal will.)
Geht aber nicht. Safari besteht auf xlink:.
LLAP 🖖
Was in Safari nicht geht:
<svg><use href="#foo"/></svg>
Hier kommt wohl noch was anderes zusammen: SVG 2 hat die xlink-Attribute durch namensraumlose Attribute ersetzt. Safari jedoch ist noch nicht soweit. Insofern kommt da noch SVG 1.1 zum Tragen oder aber der Backwards-Compability-Modus.
Was geht:
<svg><use xlink:href="#foo"/></svg>Das Attribut muss für Safari einfach malxlink:hrefheißen. Und das hat rein gar nichts mit XML-Namensräumen zu tun. Browser verarbeiten HTML nicht mit XML-Parser; so etwas wie Namensräume gibt es nicht.
Das DOM jedoch kennt Namensräume.
Die Erklärung dürfte eher im WHATWG-HTML-Parsing-Algorithmus liegen. Dieser beinhaltet ja auch MathML und SVG und muss sich daher um deren Eigenheiten kümmern. Insofern gibt es im HTML5-Algorithmus den Punkt „Adjust Foreign Attributes“, der die Textform eines Attributes wie xlink:href in das DOM-Attribut ("http://www.w3.org/1999/xlink", "href") umwandelt.
(Namensräume kann man in XML ja schließlich benennen wie mal will.)
Das Resultat dieser Hixie‘schen Erfindung führt jedoch dazu, dass nur noch das Präfix xlink: erlaubt ist, es in der Spec hardkodiert ist. Der ganze XMLNS-Prozess der Präfixe und qualifizierten Namen ist damit tot. Weil ... die WHATWG-Jungs hassen anscheinend diese Indirektion. (Siehe auch RDFa und CURIEs und bla)
Ich vermisse manchmal wirklich die Zukunft des Webs, wie es vor zehn Jahren existierte. We were promised XHTML 2!
@@Gunnar Bittersmann
Chrome zeigt beim roten Licht „symbol title“ als Tooltip an; beim gelben „link title“ und beim grünen gewinnt „symbol title“.
Firefox zeigt beim roten Licht keinen Tooltip an, beim gelben „link title“ und beim grünen dann natürlich auch „link title“.
Mit der Änderung href → xlink:href verhält sich Safari so wie Firefox: title von symbol wird nicht als Tooltip angezeigt.
LLAP 🖖
hallo
@@Gunnar Bittersmann
Chrome zeigt beim roten Licht „symbol title“ als Tooltip an; beim gelben „link title“ und beim grünen gewinnt „symbol title“.
Firefox zeigt beim roten Licht keinen Tooltip an, beim gelben „link title“ und beim grünen dann natürlich auch „link title“.
Mit der Änderung
href→xlink:hrefverhält sich Safari so wie Firefox:titlevonsymbolwird nicht als Tooltip angezeigt.
Jetzt müssen wir nur noch wissen, welcher Safari...
Gehts um Betriebssicherheit, so fällt die Wahl auf semantische Klassen, nicht Fragment-IDs
@@beatovich
Jetzt müssen wir nur noch wissen, welcher Safari...
11.1.2.
Gehts um Betriebssicherheit, so fällt die Wahl auf semantische Klassen, nicht Fragment-IDs
??
LLAP 🖖
@@Gunnar Bittersmann
@@Gunnar Bittersmann
Chrome zeigt beim roten Licht „symbol title“ als Tooltip an; beim gelben „link title“ und beim grünen gewinnt „symbol title“.
Firefox zeigt beim roten Licht keinen Tooltip an, beim gelben „link title“ und beim grünen dann natürlich auch „link title“.
Mit der Änderung
href→xlink:hrefverhält sich Safari so wie Firefox:titlevonsymbolwird nicht als Tooltip angezeigt.
Edge ebenso.
LLAP 🖖
Hej Gunnar,
@@marctrix
Mag da mal jemand in Screenreadern testen, ob die
titles vorgelesen werden? Inbesondere das aus demsymbol-Element, welches nicht als Tooltip angezeigt wird?
Sitze am Windows-Rechner, daher habe ich gerade kein VoiceOver. Aber Leonie hat da mal was zu geschrieben. aria-describedby sollte unbedingt noch mit rein! Dafür braucht der title natürlich noch eine id, auf die verwiesen werden kann…
Marc
Hej Gunnar,
@@marctrix
Mag da mal jemand in Screenreadern testen, ob die
titles vorgelesen werden? Inbesondere das aus demsymbol-Element, welches nicht als Tooltip angezeigt wird?
Auf dem iPhone werden nur die link title ausgegeben.
Marc
Hej marctrix,
@@Gunnar Bittersmann
Mag da mal jemand in Screenreadern testen, ob dietitles vorgelesen werden? Inbesondere das aus demsymbol-Element, welches nicht als Tooltip angezeigt wird?Auf dem iPhone werden nur die link title ausgegeben.
Nehme ich den Link weg und füge aria-describedby hinzu, gibt es so ein kurzes Rauschen, als ob Siri da was vorlesen wollte, es kommt aber nichts…
Bekomm gerade Augenkrebs und krumme Finger vom codepennen auf dem iphone. Könntest du mal ein Beispiel mit inline-SVGs bereit stellen? - Dann teste ich das gerne später auf Mac und iphone…
Marc
PS: Nächste Woche kannst du diese Frage Domingos live stellen. - Kannst gerne so was sammeln! 😉
@@marctrix
Bekomm gerade Augenkrebs und krumme Finger vom codepennen auf dem iphone. Könntest du mal ein Beispiel mit inline-SVGs bereit stellen? - Dann teste ich das gerne später auf Mac und iphone…
Das Markup hatte ich doch schon in diesem Thread gepostet; das bisschen CSS ist hier wirklich nur zum Hübschmachen und sollte einen Screenreader nicht interessieren.
Aber bitte: https://bittersmann.de/test/svg-icons/title-test
LLAP 🖖