Native lazy-loading for the web  |  web.dev

The title is somewhat misleading—currently it’s about native lazy-loading for Chrome, which is not (yet) the web.

I’ve just been adding loading="lazy" to most of the iframes and many of the images on adactio.com, and it’s working a treat …in Chrome.

Native lazy-loading for the web  |  web.dev

Tagged with

Related links

Intent to Ship: View Transitions Same-Origin Navigation

Finally! View transitions for multi-page apps (AKA websites) will be landing in Chrome soon—here’s hoping other browsers follow suit. Mozilla are up for it. Apple are, as usual, silent on their intentions.

Nice to see a blog post of mine referenced to show that this is a highly-requested feature. Blogging gets results, folks!

Tagged with

Bugs I’ve filed on browsers | Read the Tea Leaves

I think filing bugs on browsers is one of the most useful things a web developer can do.

Agreed!

Tagged with

Chrome 108 beta - Chrome Developers

I think this might be the most excited I’ve been in quite some time about an update to browser support, which probably says a lot about my priorities:

Support for the avoid value of the CSS fragmentation properties break-before, break-after, and break-inside when printing.

Finally!

Tagged with

Why Safari does not need any protection from Chromium – Niels Leenheer

Safari is very opinionated about which features they will support and which they won’t. And that is fine for their browser. But I don’t want the Safari team to choose for all browsers on the iOS platform.

A terrific piece from Niels pushing back on the ridiculous assertion that Apple’s ban on rival rendering engines in iOS is somehow a noble battle against a monopoly (rather than the abuse of monopoly power it actually is). If there were any truth to the idea that Apple’s browser ban is the only thing stopping everyone from switching to Chrome, then nobody would be using Safari on MacOS where users are free to choose whichever rendering engine they want.

The Safari team is capable enough not to let their browser become irrelevant. And Apple has enough money to support the Safari team to take on other browsers. It does not need some artificial App Store rule to protect it from the competition.

WebKit-only proponents are worried about losing control and Google becoming too powerful. And they feel preventing Google from controlling the web is more important than giving more power to users. They believe they are protecting users against themselves. But that is misguided.

Users need to be in control because if you take power away from users, you are creating the future you want to prevent, where one company sets the rules for everybody else. It is just somebody else who is pulling the strings.

Tagged with

The monoculture web

Firefox as the asphyxiating canary in the coalmine of the web.

Tagged with

Related posts

Writing on web.dev

A new free course on responsive web design.

Upgrade paths

If you’re going to deprecate a feature on the web, at least give us an alternative.

Browsers

Something about a browser that grinds your gears? Share it!

Foundations

This is for everyone.

Service worker weirdness in Chrome

Debugging an error message.