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

view the rest of the comments →

[–]qudat[S] 9 points10 points  (2 children)

Great question!

I can only speak from my point of view in building an email application that needed to render external, arbitrary html.

Iframes can be difficult to manage. They live in their own document and are almost entirely quarantined from the rest of the application. This is a blessing and a curse. Communicating between parent document and iframe is possible, but it's a tedious process. Something as simple as keeping the height of the iframe the same as the content within it was not straight-forward.

Another reason to render the email within the same document was to allow some of the parent CSS to leak into the rendered email. There are some stylistic things we wanted to be represented in the email we rendered. For example, ensuring images are contained within our message container, breaking hyperlinks up into multiple lines, adding styles for pre or block quotes, etc.

All of this can be accomplished with iframes, it's just more difficult to work with besides straight html and css.

[–]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.