Performance-Optimized Video Embeds with Zero JavaScript – Frontend Masters Blog
This is a clever technique for a CSS/HTML only way of just-in-time loading of iframes using details and summary.
This is a clever technique for a CSS/HTML only way of just-in-time loading of iframes using details and summary.
I like the look of this proposal that would allow authors to have more control over network priorities for third-party iframes—I’ve already documented how I had to use a third-party library to fix this problem on the Salter Cane site.
Adrian brings an excellent historical perspective to the horrifying behaviour of Facebook’s in-app browsers:
Somewhere along the way, despite a reasonably strong anti-framing culture, framing moved from being a huge no-no to a huge shrug. In a web context, it’s maligned; in a native app context, it’s totally ignored.
Yup, frames are back—but this time they’re in native apps—with all their shocking security implications:
The more I think about it, the more I cannot believe webviews with unfettered JavaScript access to third-party websites ever became a legitimate, accepted technology. It’s bad for users, and it’s bad for websites.
By the way, this also explains that when you try browsing the web in an actual web browser on your mobile device, every second website shoves a banner in your face saying “download our app.” Browsers offer users some protection. In-app webviews offer users nothing but exploitation.
It’s official. The extremely niche browser behaviour I documented is a bug.
Remy has an excellent improvement on that article I linked to yesterday on using srcdoc with iframes. Rather than using srcdoc instead of src, you can use srcdoc as well as src. That way you can support older browsers too!
This is a clever use of the srcdoc attribute on iframes.
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.
Chris succinctly describes the multiple-iframes-with-multiple-codebases approach to web development, AKA “micro frontends”:
The idea really is that you might build a React app and I build a Vue app and we’ll slap ‘em together on the same page. I definitely come from an era where we laughed-then-winced when we found sites that used multiple versions of jQuery on the same page, plus one thing that loaded all of MooTools and Prototype thrown on there seemingly by accident. We winced because that was a bucket full of JavaScript, mostly duplicated for no reason, causing bugs and slowing down the page. This doesn’t seem all that much different.
Chris looks at all the different ways of working around the fact that HTML doesn’t do transclusion. Those ways include (hah!) Scott’s super clever technique and Trys’s little Sergey.
The loading attribute for images and iframes is coming to Chrome. The best part:
You can also use
loadingas a progressive enhancement. Browsers that support the attribute can get the new lazy-loading behavior withloading=lazyand those that don’t will still have images load.
I love this use of e-ink to play a film at 24 frames per day instead of 24 frames per minute.
Feedbin has removed third-party iframes and JavaScript (oEmbed provides a nice alternative), as well as stripping out Google Analytics, and even web fonts that aren’t self-hosted. This is excellent!
First of all, don’t panic—this browser vulnerability has been fixed, so the headline is completely out of proportion to the reality. But my goodness, this was a clever technique!
The technique relies on luring users to a malicious site where the attacker embeds iframes to other sites. In their example, the two embedded iframes for one of Facebook’s social widgets, but other sites are also susceptible to this issue.
The attack consists of overlaying a huge stack of DIV layers with different blend modes on top of the iframe. These layers are all 1x1 pixel-sized, meaning they cover just one pixel of the iframe.
Habalov and Weißer say that depending on the time needed to render the entire stack of DIVs, an attacker can determine the color of that pixel shown on the user’s screen.
The researchers say that by gradually moving this DIV “scan” stack across the iframe, “it is possible to determine the iframe’s content.”
It really, really bothers me that wireframes have evolved from being a prioritisation tool into a layout tool (disempowering UI designers in the process), so I’m happy to see an alternative like this—somewhat like Dan Brown’s Page Description Diagrams.
Eric uses some super-clever CSS to “wireframe up” a web page.
I wonder if this could be turned into a little bookmarklet?
Less wireframing, more prototyping.
—Leisa
A browser-based tool for creating HTML prototypes.
There is something utterly hypnotic and disturbing about these three-frame looping animations.
John Gruber provides a PHP-based way of busting out of Digg's 90s-style framing. I shall be implementing this forthwith.