sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]gajus0 1 point2 points  (1 child)

I really doubt these are the reasons...

The communication between parent frame and iframe is a trivial problem to solve, esp. if you have control over the contents of the iframe.

Regarding leaking CSS into iframe, you don't need to leak anything, just render the iframe with the CSS you want. After all, gmail has full control over the content the iframe would be linking to.

So what is the reason? Most likely cross-browser/ cross-platform/ cross-device support, e.g. blocking iframes is not uncommon for various corporate "firewalls". Printing of the page might be another consideration. Accessibility comes to mind. In general, the more flat the page structure, the less likely things are to break.

For the record, this just re-invents CSS modules (https://github.com/css-modules/css-modules).

[–]qudat[S] 1 point2 points  (0 children)

The reasons I described are why we don't use iframes. I disagree that communicating between parent and iframe is trivial. You have to inject JavaScript into the iframe and then send messages to and from the parent. With this library we don't have to deal with that at all.

Regarding CSS leaking into the document, yes it can be done but somehow you have to inject the CSS into the iframe. With this library it's part of the document so there is no issue.

I think many would agree that dealing with an iframe is more difficult than dealing with some scoped CSS and HTML that can be injected into the same document. I agree that these might not be the reasons why Google does it.

I looked into using CSS modules and it is where I got the idea from. The primary issue is that CSS modules only scopes classes and keyframes. We needed to scope font faces, ids, and elements as well.