Hacker News Reader

Comment by OptionX | Hacker News Reader

I think this is the first time I've ever heard someone make a case FOR the use use of iframes. I have no opinion on it personally, but I remember reading more than a few articles treating them like the plague.

View on HN

Invisible iframes are fantastic for sandboxing third-party code, or perhaps modularising work from another team.

Avoiding cookies in iframes is important because browsers are getting more restrictive, so security for iframes is difficult to manage. We passed a unique session token to the iframes from the owning page using postMessage(), and the two servers (we controlled both) communicated directly for authentication (avoid putting authentication into the browser since your enemy controls it completely).

I have always found trying to use iframes as a visible section of your UI is really crappy. Troubles with keyboard focus, resizing, modal dialogs, scrolling, Mobile Safari quirks, detecting loading or other failures, yada yada yada.

I recently had to deal with the headaches of cookies and iframes. In my case, it was learning management software that used our external tool loaded in an iframe via LTI. I was specifically dealing with Safari but understood other browsers could become as strict as Safari for cookies in iframes.

After pursuing methods of getting user consent to use 3rd party cookies via the storage API, the end result was the user jumping through hoops by repeatedly clicking buttons to invoke user interaction in different contexts to eventually get a prompt to allow cookies. It did work, but there were strange bugs with it on mobile Safari... e.g., the prompt to allow cookies never appeared after clicking the button but after putting Safari in the background and going back to it, it did appear.

The UX of all this was pretty undesirable so we just gave up and had the tool open in a full window and wondered why we didn't think to do that from the beginning.

I’m using them in a css-based design tool I’m working on. The “canvas” is inside of an iframe so that I can completely control the styling irrespective of the application itself.

There are definitely a few scenarios where they are useful.

Is there any reason you're not just using shadow DOM?

Afaik that doesn’t solve the problem of global CSS. Whatever framework I use to build the application itself (right now I’m using Tailwind), I don’t want to risk it polluting the canvas itself.

edit: I'd never spent much time looking at shadow dom, but it does appear that you can encapsulate styles with a shadow root. Had no idea - that's really interesting, thanks!

Our entire internal site [let us call it a CMS] is made using iframes. We are about to move toward something different because mobile. Suggestions welcome. We're a php shop.

PHP shop moving away from iframes because of responsiveness in 2021 is quite interesting to me for some reason. I can't quite put my finger on it...

PHP has been able to move on, and since it's server side language things are easier to change on a per-site basis. Iframes must remain fully backwards compatible or they break the web as a whole, same with anything else being rendered by the browser.

In a way PHP is one of the tools which helped to move away from iframes.

With "static" web pages people used iframes, so they didn't have to update navigation on all pages. With PHP you cod simply do <?php include ('menu.php');?> and had a single source of truth.

This makes about 90% of early PHP scripts :)

iframes are a great tool while transitioning between platforms. I've used them to transition to new frontends without requiring a rewrite of 100% of the components. If there's a lesser-used-but-complicated piece of the site, you can slap it in an iframe. Spend a few hours sewing them together with JS message posting and it works fine.

It's not amazing, but it works.

there is a use for them. I think I've used them three or four times in my career in the last 15 years and they worked great.

Reply on news.ycombinator.com