Chrome 75 unterstützt natives Lazy-Loading

[marctrix]

Hej alle,

eben bei CSS-Tricks gelesen, aber der Link weist auf eine deutsche Seite.

Ab Version 75 ist im Chrome die (schon früher verfügbare) lazy loading-Funktion standardmäßig aktiv.

So funktioniert es.

<!-- Das Bild wird erst bei Bedarf geladen -->
<img src="bild.jpg" loading="lazy" alt="Bild XYZ"/>

<!-- Das Bild wird direkt beim Seitenaufruf geladen -->
<img src="bild.jpg" loading="eager" alt="Bild XYZ"/>

<!-- Der Browser entscheidet, ob Lazy-Load zum Einsatz kommt -->
<img src="bild.jpg" loading="auto" alt="Bild XYZ"/>

Hoffen wir, dass andere Browser nachziehen. Als progressive enhancement bereits geeignet.

Marc

[Der Martin]

Hallo Marc,

Ab Version 75 ist im Chrome die (schon früher verfügbare) lazy loading-Funktion standardmäßig aktiv.

das bedeutet also:

<!-- Das Bild wird erst bei Bedarf geladen -->

Okay. Wann besteht dieser Bedarf?

Hoffen wir, dass andere Browser nachziehen. Als progressive enhancement bereits geeignet.

Ich kann es nicht belegen, aber ich hatte auch beim Firefox schon einige Male den Eindruck, dass er das schon praktiziert. Mehrmals schon habe ich beobachtet, dass er zwar signalisiert, die Seite sei fertig geladen, und erst wenn ich ein Stück nach unten scrolle, fällt ihm ein: Ah, Moment, da fehlt noch ein Bild, ich hol's dir.

Ciao,
 Martin

[Christian Kruse]

Hallo Martin,

Ab Version 75 ist im Chrome die (schon früher verfügbare) lazy loading-Funktion standardmäßig aktiv.

das bedeutet also:

<!-- Das Bild wird erst bei Bedarf geladen -->

Okay. Wann besteht dieser Bedarf?

Steht doch im Artikel. Wenn das Bild in den Viewport gescrollt wird.

Hoffen wir, dass andere Browser nachziehen. Als progressive enhancement bereits geeignet.

Ich kann es nicht belegen, aber ich hatte auch beim Firefox schon einige Male den Eindruck, dass er das schon praktiziert.

Nein, Firefox kann das noch nicht. Es gibt aber diverse JS-Implementationen, die das nachbauen.

LG,
CK

[marctrix]

Hej Der Martin,

<!-- Das Bild wird erst bei Bedarf geladen -->

Okay. Wann besteht dieser Bedarf?

Wenn man in die Nähe des Bildes scrollt.

Was mir an dieser Art der Optimierung schwer missfällt: dabei wird nur das Bedürfnis der Seitenbetreiber bedacht: Nutzer so lange wie möglich auf einer Seite zu halten.

Klar Nutzer sind weg, wenn sie zu lange warten müssen, wollen also selber auch, dass etwas schnell erscheint.

Aber: lazy loading macht große Datenmengen schwerer identifizierbar.

Bedeutet: man hat das Gefühl, dass man auf einer leichten (weil flotten) Seite untergwes ist und dabei wird im Hintergrund ständig fleißig teures Datenvolumen verbraten.

Auch dient das cniht dazu, den Ausstoß von Treibhausgasen auf 40% des Standes von 1990 zu senken. Es wird dadurch eher mehr Strom verbraucht!

Marc

[Auge]

Hallo

Was mir an dieser Art der Optimierung schwer missfällt: dabei wird nur das Bedürfnis der Seitenbetreiber bedacht: Nutzer so lange wie möglich auf einer Seite zu halten.

Klar Nutzer sind weg, wenn sie zu lange warten müssen, wollen also selber auch, dass etwas schnell erscheint.

Aber: lazy loading macht große Datenmengen schwerer identifizierbar.

Bedeutet: man hat das Gefühl, dass man auf einer leichten (weil flotten) Seite untergwes ist und dabei wird im Hintergrund ständig fleißig teures Datenvolumen verbraten.

Die Begründung für das Attribut, das im web.dev-Artikel, transportiert über die Frage „Why native lazy-loading?“, geliefert wird, erscheint mir in dieser Hinsicht auch recht blauäugig.

„According to HTTPArchive, images are the most requested asset type for most websites and usually take up more bandwidth than any other resource. At the 90th percentile, sites send about 4.7 MB of images on desktop and mobile. That's a lot of cat pictures.

Embedded iframes also use a lot of data and can harm page performance. Only loading non-critical, below-the-fold images and iframes when the user is likely to see them improves page load times, minimizes user bandwidth, and reduces memory usage.“

Was ändert sich mit Lazy Loading am Datenvolumen? Nichts! ob ich 4.7 MB an Bildern sofort während des Seitenaufbaus lade oder verteilt über die nächsten Minuten, in denen ich auf der betreffenden Seite scrolle, es sind und bleiben 4.7 MB. Damit wird meiner Meinung nach auch das Argument „minimizes user bandwidth“ wackelig. Der einzige Unterschied ist die Zeit, die bis zur Benutzbarzeit der Seite verstreicht, weil eben nicht alle Bilder/Iframes sofort bei Seitenaufruf geladen werden (müssen).

Tschö, Auge

[Gunnar Bittersmann]

@@Auge

Was ändert sich mit Lazy Loading am Datenvolumen? Nichts!

Wenn der Nutzer die Seite gar nicht bis zum Ende liest, ändert sich schon was.

LLAP 🖖

[MudGuard]

Hi,

Was ändert sich mit Lazy Loading am Datenvolumen? Nichts!

wenn man die ganze Seite anguckt.

Oft ist es aber doch so: man sucht in der Suchmaschine des geringsten Mißtrauens und ruft einen der Treffer auf. Und erkennt dann schon beim Betrachten der ersten Viewport-Füllung, daß das nicht das richtige ist und macht die Seite zu.

Und hat damit das Laden der Bilder weiter unten gespart.

cu,
Andreas a/k/a MudGuard

[Auge]

Hallo

Was ändert sich mit Lazy Loading am Datenvolumen? Nichts!

wenn man die ganze Seite anguckt.

Zweie binnen kurzem mit einem Gedanken.

Oft ist es aber doch so: man sucht in der Suchmaschine des geringsten Mißtrauens und ruft einen der Treffer auf. Und erkennt dann schon beim Betrachten der ersten Viewport-Füllung, daß das nicht das richtige ist und macht die Seite zu.

Und hat damit das Laden der Bilder weiter unten gespart.

ACK.

Das sehe ich als einen sehr oft auftretenden Spezialfall. In der Realität wird man also Datenvolumen sparen, weil man sich verirrt hat oder etwas nicht gefällt. Dort jedoch, wo man interessiert bis zum Ende liest und schaut, bleibt das zu ladende Datenvolumen gleich und „nur“ die Schwuppdizität der Seite ändert sich (nicht, dass das nicht auch ein valides Pro-Argument sei).

Tschö, Auge

[marctrix]

Hej MudGuard,

Oft ist es aber doch so: man sucht in der Suchmaschine des geringsten Mißtrauens und ruft einen der Treffer auf. Und erkennt dann schon beim Betrachten der ersten Viewport-Füllung, daß das nicht das richtige ist und macht die Seite zu.

Und hat damit das Laden der Bilder weiter unten gespart.

Man schließt freilich oft von sich auf andere. Die Seiten, die ich meistens besuche, will ich mir auch anschauen.

Und um mir einen Überblick zu verschaffen scrolle ich gerade bei unbekannten Seiten auch oft mal bis nach unten.

Mag sein, dass ich einer Minderheit angehöre…

Marc

[MudGuard]

Hi,

Man schließt freilich oft von sich auf andere. Die Seiten, die ich meistens besuche, will ich mir auch anschauen.

ich schrieb absichtlich "Oft" und nicht "Immer".

cu,
Andreas a/k/a MudGuard

[marctrix]

Hej MudGuard,

Man schließt freilich oft von sich auf andere. Die Seiten, die ich meistens besuche, will ich mir auch anschauen.

ich schrieb absichtlich "Oft" und nicht "Immer".

Nur zur klarstellung: mit "man" meinte ich mich…

Marc

[marctrix]

Hej MudGuard,

Man schließt freilich oft von sich auf andere. Die Seiten, die ich meistens besuche, will ich mir auch anschauen.

ich schrieb absichtlich "Oft" und nicht "Immer".

Nur zur klarstellung: mit "man" meinte ich mich…

Dennoch wird diese Technik auch bei mir zur Einsparung von Daten beitragen.

Aber das war nciht mein Thema. Mir geht es darum, dass schlechtes Verhalten von Entwicklern auf diese Weise gefördert wird.

Den Geldgeber interessiert nur, ob die Nutzer bleiben und wie hoch die conversion rate ist, den Entwickler interessiert nur wie schnell er möglichst viel Geld verdienen kann (und er lernt dazu haufenweise widerliche Techniken, um Nutzer zu verfolgen, Daten zu sammeln und anders mehr, um die conversion rate zu erhöhen).

Diese Art von Entwicklern haben kein Gewissen und sie werden uns ab sofort (weil ja "jeder" Chrome benutzt und dank solcher Implementation Chrome noch beliebter werden dürfte) noch mehr JavaScript-Code aufbürden, weil sie ja so toll viel an Bildern sparen. Die dürfen dann - vor allem nach dem Fold, wenn der ganze Müll erst mal geladen ist, dann auch gerne noch größer sein…

Bin ich zu skeptisch? Leider habe ich viele Entwickler kennen gelernt, die von Technik viel und von Ethik nichts verstehen. - Eine gefährliche Mischung.

Sie haben nur ein konkretes (vorgegebnes) Ziel im Auge, das sie nicht hinterfragen und sind auch noch noch stolz darauf, wenn sie es erreichen.

Dass sie damit gegen jede ethisch-moralische gessellschaftliche Konvention verstoßen, stört sie nicht. Was ich nciht weiß, macht mich nicht heiß. Mit so was am besten gar nciht beschäftigen.

Der Self-Raum ist anders, aber Entwickler mit Ansichtne wie Bernd scheinen mir die Mehrheit zu bilden - andere würden ohne Fachkräfte-Mangel auch kaum angestellt werden…

Marc

[Christian Kruse]

Hallo marctrix,

Bin ich zu skeptisch? Leider habe ich viele Entwickler kennen gelernt, die von Technik viel und von Ethik nichts verstehen. - Eine gefährliche Mischung.

Sie haben nur ein konkretes (vorgegebnes) Ziel im Auge, das sie nicht hinterfragen und sind auch noch noch stolz darauf, wenn sie es erreichen.

Dass sie damit gegen jede ethisch-moralische gessellschaftliche Konvention verstoßen, stört sie nicht. Was ich nciht weiß, macht mich nicht heiß. Mit so was am besten gar nciht beschäftigen.

Siehe auch:

• „That's not my department“
• wegen Aktualität weil von gestern: Software ermöglicht Deep Fakes in Echtzeit
• Not my department vom 29C3
• Edit: auch wegen Aktualität weil von heute: US-Wahl: Wahlsicherheit wird bewusst missachtet

LG,
CK

[marctrix]

Hej Christian,

• Edit: auch wegen Aktualität weil von heute: US-Wahl: Wahlsicherheit wird bewusst missachtet

Ist in dem Artikel ein Fehler? Allein Texas hat knapp 30 Millionen Einwohner, Louisiana, Tennessee, Mississippi, Kansas, Kentucky und Indiana kommen zusammen auf über 30 Millionen, zusammen also über 60 Millionen. Wieso dürfen da nur 16 Millionen wählen?

Schon "lustig", dass ich Bundesstaaten (Mississippi, Kansas, Louisiana) in einem tausende Kilometer entfernten Land kenne, die so viele Einwohner haben wie Berlin und dafür Natinalstaaten mit mehr Einwohnern nicht aus dem Kopf nennen könnte. Brainwashed…

Marc

[Christian Kruse]

Hallo marctrix,

• Edit: auch wegen Aktualität weil von heute: US-Wahl: Wahlsicherheit wird bewusst missachtet

Ist in dem Artikel ein Fehler? Allein Texas hat knapp 30 Millionen Einwohner, Louisiana, Tennessee, Mississippi, Kansas, Kentucky und Indiana kommen zusammen auf über 30 Millionen, zusammen also über 60 Millionen. Wieso dürfen da nur 16 Millionen wählen?

Von „dürfen“ steht da nichts. Von „tun“ ist die Rede.

Die Meldung geht auf diesen Artikel zurück. Und dort steht: „The Brennan Center estimates that compared to 2016, when approximately 27.5 million voters cast their ballots on paperless machines, a little over half, or as many as 16 million, will do so in 2020“ – es ist also eine Abschätzung auf Basis der Wahlbeteiligung aus der Wahl 2016.

LG,
CK

[Der Martin]

Hallo,

Leider habe ich viele Entwickler kennen gelernt, die von Technik viel und von Ethik nichts verstehen. - Eine gefährliche Mischung.

ich kenne auch welche, die von Ethik viel und von Technik recht wenig verstehen. Das ist auch nicht wirklich besser.

So long,
 Martin

[marctrix]

Hej Der Martin,

Leider habe ich viele Entwickler kennen gelernt, die von Technik viel und von Ethik nichts verstehen. - Eine gefährliche Mischung.

ich kenne auch welche, die von Ethik viel und von Technik recht wenig verstehen. Das ist auch nicht wirklich besser.

Aus den Bauch raus würde ich sagen, dass dadurch wesentlich weniger Schaden angerichtet wird. Dennoch gibt es natürlich Schäden durch gut gemeint, aber nicht gekonnt.

Insofern sollte man erstens sein Fach beherrschen und dann auch Wissen über die Konsequenzen bestimmter Designs kennen.

Auch fände ich es wichtig, dass unethisches Verhalten rechtlich bedacht wird. Es geht darum ein Unrechtsbewusstsein zu etablieren und dauerhaft zu erhalten.

Und mit Design meine ich Programmier-Konzepte und nicht die Größe von Buttons.

Marc

[Gunnar Bittersmann]

@@marctrix

Auch fände ich es wichtig, dass unethisches Verhalten rechtlich bedacht wird.

Google und Facebook kriegen desöfteren mal Strafen aufgebrummt – in Höhen, die sie aus der Klingelkasse bezahlen. 😠

LLAP 🖖

[marctrix]

Hej Gunnar,

Auch fände ich es wichtig, dass unethisches Verhalten rechtlich bedacht wird.

Google und Facebook kriegen desöfteren mal Strafen aufgebrummt – in Höhen, die sie aus der Klingelkasse bezahlen. 😠

Ich dachte auch eher daran echte Menschen für ihre Entscheidungen und Weisungen anzuklagen, keine juristische Personen…

Marc

[Gunnar Bittersmann]

@@marctrix

Ich dachte auch eher daran echte Menschen für ihre Entscheidungen und Weisungen anzuklagen, keine juristische Personen…

Dachtest du da an Zuckerberg oder an alle Facebook-Mitarbeiter?

Am Ende liefe das wohl darauf hinaus, einen Stacheldrahtzaun ums Silicon Valley zu ziehen.

LLAP 🖖

[marctrix]

Hej Gunnar,

Ich dachte auch eher daran echte Menschen für ihre Entscheidungen und Weisungen anzuklagen, keine juristische Personen…

Dachtest du da an Zuckerberg oder an alle Facebook-Mitarbeiter?

Am Ende liefe das wohl darauf hinaus, einen Stacheldrahtzaun ums Silicon Valley zu ziehen.

Der Fisch fängt am Kopf an zu stinken. Also sollte man dort beginnen.

Aber ja, wer etwas zu verantworten hat, sollte auch zur Verantwortung gezogen werden. Anders lassen sich Regeln nicht durchsetzen.

Marc

[Der Martin]

Moin,

Was ändert sich mit Lazy Loading am Datenvolumen? Nichts!

kommt drauf an. ;-)

ob ich 4.7 MB an Bildern sofort während des Seitenaufbaus lade oder verteilt über die nächsten Minuten, in denen ich auf der betreffenden Seite scrolle, es sind und bleiben 4.7 MB.

Für den wirklich Interessierten schon. Aber passiert es dir nicht auch oft, dass du eine verlinkte Seite aufrufst und schon beim ersten Anschauen merkst, "Oh, das ist doch nicht, was ich suche", und schließt die Seite wieder?
Bei mir ist das sehr häufig der Fall, und dann kann der Spareffekt durchaus erwähnenswert sein.

Der einzige Unterschied ist die Zeit, die bis zur Benutzbarzeit der Seite verstreicht, weil eben nicht alle Bilder/Iframes sofort bei Seitenaufruf geladen werden (müssen).

Auch nicht unbedingt. Denn benutzbar ist die Seite ja meistens auch schon, während noch Bilder geladen werden (also in der Zeitspanne von DOMContentLoaded bis zum load-Event).

Ciao,
 Martin

[dedlfix]

Tach!

Aber: lazy loading macht große Datenmengen schwerer identifizierbar.

Bedeutet: man hat das Gefühl, dass man auf einer leichten (weil flotten) Seite untergwes ist und dabei wird im Hintergrund ständig fleißig teures Datenvolumen verbraten.

Wie meinst du dieses "ständig"? Als andauernder Stream oder als unabdingbares Vorabladen im Hintergrund?

Wenn man nicht hinscrollt passiert nichts. Wenn man Module einer Webanwendung mit Lazy Loading nicht betritt, werden die nicht geladen. Lazy Loading hat erstmal nichts mit Vorabladen zu tun. Das kommt in einigen Fälle sicherlich hinzu. Ich würde mich aber hüten, das pauschal als Eigenschaft von Lazy Loading anzusehen. Wenn man mit Lazy Loading Probleme beim Laden unnötiger Datenmengen zu kaschieren versucht, ist das ein Problem der Anwendung, nicht der Technik von Lazy Loading.

dedlfix.

[marctrix]

Hej dedlfix,

Wenn man mit Lazy Loading Probleme beim Laden unnötiger Datenmengen zu kaschieren versucht, ist das ein Problem der Anwendung, nicht der Technik von Lazy Loading.

Nein. Nicht die Anwendung ist das Problem. Der Entwickler ist es.

Marc

[encoder]

und erst wenn ich ein Stück nach unten scrolle, fällt ihm ein: Ah, Moment, da fehlt noch ein Bild, ich hol's dir.

Ich hoffe dieses Attribut ist wirklich gescheit mit einer zwingend geforderten Größenangabe des Bilds verknüpft, die Momente wie diesen sicher verhindert - kennt sicher jeder.

Ah da steht der Text den ich will
nein jetzt kommt noch ein Bild dazwischen gerutscht, also nochmal runter scrollen
oh 💩 noch ein Bild, also noch weiter runter ...
ach komm jetzt leckst mich am @$% ... weißte was, lad jetzt in Ruhe diese scheiß Seite fertig und dann schau ich sie mir an - oder gibts andere Seiten zum Thema die nicht von Pfuschern gemacht sind?

[marctrix]

Hej encoder,

und erst wenn ich ein Stück nach unten scrolle, fällt ihm ein: Ah, Moment, da fehlt noch ein Bild, ich hol's dir.

Ich hoffe dieses Attribut ist wirklich gescheit mit einer zwingend geforderten Größenangabe des Bilds verknüpft, die Momente wie diesen sicher verhindert - kennt sicher jeder.

Nur auf schlechten Websites, wo Bilder keine Größenangaben haben. Und selbst da sollte Chrome kein Problem mit haben, weil in den ersten KByte der Bilder diese Größenangabe steckt. Laut dem verlinkten Artikel lädt Chrome erst mal nur die Dateianfänge, um dieses Problem zu vermeiden. Um noch mehr Daten zu sparen, soll das in Zukunft nur noch passieren, wenn keine Größe angegeben wurde (ebenda).

Bedeutet: wenn du dieses Problem hast, nutzt du keinen Chrom(ium). So wie die Leute, die dir ein Plus gegeben haben (und ich).

Marc

[Auge]

Hallo

Als Ergänzung:

<!-- Der Browser entscheidet, ob Lazy-Load zum Einsatz kommt -->
<img src="bild.jpg" loading="auto" alt="Bild XYZ"/>

Der Default-Wert ist auto. Chrome wird zukünftig also selbst entscheiden, wann er Bilder außerhalb des Viewports lädt.

---

Auch wenn ich das Feature grundsätzlich interessant finde, bedeutet es aber eine Verhaltensänderung, die zu Verwirrung führen kann und die man als Autor kennen muss. Lade ich einen längeren Artikel mit verstreut eingesetzten Bildern und kappe dann (gewollt oder ungewollt) die Internetverbindung, werden Bilder, die anfangs außerhalb des Viewports sind, zwangsläufig nicht geladen. Das führt zu unschönen Effekten auf der Seite und kann zu Beschwerden von Seiten der Leserschaft über unprofessionell erstellte Seiten führen.

Tschö, Auge

[edit] Typo, Trennlinie zwischen Ergänzung und Meinungsäußerung

[Gunnar Bittersmann]

@@marctrix

Hoffen wir, dass andere Browser nachziehen. Als progressive enhancement bereits geeignet.

Willkommen im Browserkrieg!

Google/Chrome tut alles, wofür wir Microsoft/Internet Explorer damals „geliebt“ haben:

• schert sich einen Dreck um Standards
• will seine implementierten Features als Standard durchdrücken
• strebt die alleinige Weltherrschaft an

Nur dass so manche Google/Chrome tatsächlich noch lieben. 🙈

LLAP 🖖

[marctrix]

Hej Gunnar,

Hoffen wir, dass andere Browser nachziehen. Als progressive enhancement bereits geeignet.

Willkommen im Browserkrieg!

Der tobt doch schon lange.

Google/Chrome tut alles, wofür wir Microsoft/Internet Explorer damals „geliebt“ haben:

• schert sich einen Dreck um Standards

Oh, wusste ich noch nicht. Google-Produkte nutze ich ausschließlich zu Testzwecken - und dann auch nur, wenn es sich nciht vermeiden lässt.

• will seine implementierten Features als Standard durchdrücken

Na ja, so ensteht doch neues.

Zum Beispiel CSS-Grid. Ich dachte, das ist jetzt die Methode, Standards zu entwickeln: in einem Browser implementieren und dann besprechen und ggfs. standardisiert in alle Browser zu übernehmen.

Aber ja

• strebt die alleinige Weltherrschaft an

zumindest im Web. Und damit ist in unserer Zeit viel erreicht… 😟

Nur dass so manche Google/Chrome tatsächlich noch lieben. 🙈

🔇 Ich sage dazu leiber nichts…

Marc

[Gunnar Bittersmann]

@@marctrix

• will seine implementierten Features als Standard durchdrücken

Na ja, so ensteht doch neues.

Njein.

Meine Kritik richtete sich nicht gegen das Feature. Das ist sicher nützlich: zum einen spart das einen Haufen JavaScript-Code, und wenn das Lazyload browserintern implementiert wird, läuft das sicher auch performanter als jede JavaScript-Impementierung.

Meine Kritik richtete sich gegen die Art, wie Google/Chrome das Feature durchdrückt.

Zum Beispiel CSS-Grid. Ich dachte, das ist jetzt die Methode, Standards zu entwickeln: in einem Browser implementieren und dann besprechen und ggfs. standardisiert in alle Browser zu übernehmen.

So lief es bei Grid: Microsoft hat das im Internet Explorer implementiert – hinter dem -ms--Präfix (heutzutage würde man das hinter einem Flag tun) –, dann wurde besprochen, die Spec erfuhr noch einige Verbesserungen, bevor Grid standardisiert wurde. Die jetzige Spec ist von der ursprünglichen so weit entfernt, dass manche denken, IE könne kein Grid.

Beim loading-Attribut scheint Google/Chrome den Teil mit dem Besprechen einfach mal übersprungen zu haben und das Feature im Alleingang rausgehauen zu haben. Ausnutzung der Machtposition, andere müssen nachziehen. Browserkrieg.

Nein Google/Chrome, ihr seid nicht die Guten, ihr seid die Arroganten.

LLAP 🖖

[1unitedpower]

Beim loading-Attribut scheint Google/Chrome den Teil mit dem Besprechen einfach mal übersprungen zu haben und das Feature im Alleingang rausgehauen zu haben.

Haben Sie das? Das Feature wurde mindestens seit Juli 2017 bei GitHub diskutiert. Ein Feature Proposal liegt seit Juni 2018 vor. Google hat das Feature dann hinter einem Flag implementiert und im April diesen Jahres die W3C Technical Architecture Group um einen Review gebeten.

Ich habe jetzt nicht überprüft für wen die Leute arbeiten, die sich an der Diskussion beteiligt haben, aber das scheint mir insgesamt ein fairer Zeitrahmen zu sein, um viele Stimmen zu Wort kommen zu lassen. Es scheint ja auch eine rege Beteiligung gegeben zu haben.

[Gunnar Bittersmann]

@@1unitedpower

Beim loading-Attribut scheint Google/Chrome den Teil mit dem Besprechen einfach mal übersprungen zu haben und das Feature im Alleingang rausgehauen zu haben.

Haben Sie das? Das Feature wurde mindestens seit Juli 2017 bei GitHub diskutiert. Ein Feature Proposal liegt seit Juni 2018 vor. Google hat das Feature dann hinter einem Flag implementiert und im April diesen Jahres die W3C Technical Architecture Group um einen Review gebeten.

Wenn das so ist, warum steht davon nichts in der Spec, die ja ein living standard sein will?

LLAP 🖖

[1unitedpower]

Wenn das so ist, warum steht davon nichts in der Spec, die ja ein living standard sein will?

Vermutlich weil es laut dem WHATWG Prozess zwei Implementierungen geben muss. Bisher scheint Chrome die einzige zu haben.

Ich sehe es übrigens auch kritisch, dass Chrome das Feature ausgerollt hat bevor es offiziell in den Standard aufgenommen wurde. Ich wollte lediglich die Aussage relativieren, dass Chrome das Feature im Alleingang verabschiedet hat. Es hat ja offenbar Diskussion gegeben und es existiert ein Working Draft von einem WHATWG Editor.

[Gunnar Bittersmann]

@@marctrix

Google/Chrome […] schert sich einen Dreck um Standards

Oh, wusste ich noch nicht.

Beispiel: die gap-Eigenschaft – dafür gedacht, auch Zwischenräume zwischen Flexitems genauso wie für Griditems angeben zu können, und dann die grid-gap-Eigenschaft obsolet zu machen.

Implementiert in Firefox: Codepen.

Doch was machen Chromia (und WebKits) anstatt das zu implementieren?? Sie setzen gap als Alias für grid-gap. What? The? Fuck?

Dass gap bei Flexbox in diesen Browsern nicht funktioniert, ist nicht tragisch; darauf könnte man ja reagieren …

… wenn nicht @supports (gap: 1em) lügen würde. Obwohl die Eigenschaft nicht implementiert ist, gibt die feature detection an, sie wäre es. Und das ist tragisch.

Denn dadurch lässt sich gap für Flexitems überhaupt nicht nutzen. Danke für nichts, Chromia und WebKits.

LLAP 🖖

[Henry]

Hallo marctrix,

Hoffen wir, dass andere Browser nachziehen.

Hoffe ich auch, weil Chrome nutze ich nicht. Ich mag auch dieses Lazy-loading nicht, aber wenn es standardisiert wird durch ein kleines Attribut, ist es natürlich wesentlich leichter sich dem zu entziehen, indem Produkte wie uBlock das als Feature aufnehmen könnten oder sogar noch besser als Browsereinstellung und so dem User die Wahl lassen, anstatt der bisherigen vielen individuellen asynchronen Lösungen, die ein optionales Betrachten nahezu unmöglich machen.

Gruss
Henry