Html: Remove `<iframe seamless>`

[annevk]

This seems like a good candidate for direct removal since per http://caniuse.com/#search=seamless nobody is doing this.

[foolip]

Are the use cases for this simply left unsolved, or is it being done cooperatively with postMessage between the embedder and embedded frame?

[annevk]

I don't think that solves all equally well, but it seems like shadow DOM solves most of them pretty well.

[foolip]

Support was removed from Blink in January 2014, and from the blink-dev discussion I take the sentiment to be more disinterest than disapproval.

It would be interesting to hear if there are fundamental problems with the feature, but it would take active implementor interest to save it.

[sideshowbarker]

It would be interesting to hear if there are fundamental problems with the feature, but it would take active implementor interest to save it.

I notice that in one of Adam Barth’s comments in the thread you cited, he says:

We're considering removing the feature because it's adding complexity to the style recalculation engine. Specifically, when working to improve style recalculation performance, we've often run into code and complexity that exists only to serve iframe@seamless. Removing that code and complexity will let us improve style recalculation performance faster.

As far as web-developer feedback on the feature, some comments from Ben Vinegar from last year are worth reading; among other things he says:

But while we’re not interested in the style component of the seamless
attribute, we – and probably all developers that hack on iframes – are
interested in the resizing behaviour it introduces. Right now we deploy
fairly complex code, both inside the iframed document, and on the parent
document, to resize the iframe element when the iframed content changes
size [2]. Every iframed application with dynamically-sized content does the
same.

To me, it’s crazy that it’s 2013 and there’s still no native way to have
the browser automatically resize an iframe. And yet we have seamless. But
it not only resizes: it adds all this other bundled behaviour, and strictly
serves a fringe use case where somebody is distributing iframes on the same
origin.

My suggestion is to split seamless into its three major parts: style
inheritance, iframe resizing, and browsing context.

So I think the gist of it all both from the implementor side and the web-dev side is that seamless as-specced doesn’t seem to be what anybody wanted to begin with. Or at least it’s more than anybody actually wanted. And anyway like @annevk says, it’s seems a lot of it’s since been “overcome by events” in light of Shadow DOM.

[annevk]

Note also that seamless requires changes to the event model that have never been specified.

[Ritsyy]

how should the removal of iframe seamless change for browsing context , as it would take a lot of changes for it's spec.

[annevk]

Yeah, things that look like they can be removed:

• everything that says seamless
• master concept in the "Browsing context names" section
• the three columns about seamless in the big table
• "explicit self-navigation override"

Basically everything that builds on top of the seamless feature can go.

[Ritsyy]

okay @annevk , will remove the dependent spec on seamless feature.

[annevk]

This was removed in https://github.com/whatwg/html/commit/1490eba4dba5ab476f0981443a86c01acae01311. My mistake for not linking it all together.

[annevk]

Thank you @Ritsyy for making it happen! (And persisting despite my nitpicking. 😊)

[Ritsyy]

@annevk Learned a lot from this bug, thank you so much for all the reviews :)

[indolering]

This is really disappointing as web components do not provide any security, you can't import a web component without it being able to manipulate the page it's in.

[domenic]

Yeah. It would have been cool if someone implemented, IMO, but a number of factors made it not a good tradeoff for implementers given other technologies that serve overlapping use cases (even if none of them serve the exact use case).

[thx1111]

Well, here it is, now 2016 as I add this comment, and I am still using a terminal emulator to display my notes. I'd rather use a web browser for display, because, with things like html, latex, mathjax, and chemdoodle, my notes could draw from a rather rich expressive palette. But then, I also prefer a "modular" approach to writing, cutting and pasting together smaller documents, and then also, assembling those smaller sections to form a larger document. And it's nice to have the smaller bits both able to display on their own, and also contribute to that larger document. But, as it is, in 2016, there is still no simple native html markup to allow this sort of thing. https://stackoverflow.com/questions/8988855/include-another-html-file-in-a-html-file

Some people had hoped that some combination of "iframe", "seamless", and 'target="_parent"' would address this issue - but no. Instead, whatever the technical issues might be, there seems to be a kind of "stupid white men" paternalism that favors complex script-based source material intended to obfuscate rather than simplify. The implication being that end-users must not be content producers. And browser developers set-out to enforce this dictum. It's political, not technical.

Is that too harsh? Where is the simple html construct that assembles a single larger web page from a group of smaller pages, and adopts the styles from its hosting page, without resorting to a lot of javascript?

[thx1111]

BTW, "seamless" was back in again in the HTML 5.1 draft in 2016 Mar 10:
https://www.w3.org/TR/2016/WD-html51-20160310/semantics-embedded-content.html#seamless-iframe

but out again in the HTML 5.1 draft in 2016 Jun 02:
https://www.w3.org/TR/2016/WD-html51-20160602/semantics-embedded-content.html#the-iframe-element

Iframe "seamless" has not returned in the HTML 5.1 draft, 2016 Jun 21:
https://www.w3.org/TR/html51/semantics-embedded-content.html#the-iframe-element

or in the HTML 5.2 draft, 2016 Aug 18:
https://www.w3.org/TR/html52/semantics-embedded-content.html#the-iframe-element

If you are concerned, file an Issue:
https://github.com/w3c/html/issues/new

[zcorpan]

Hello @thx1111 and welcome to WHATWG.

Please read the following:

https://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_removing_bad_ideas_from_a_specification.3F (3rd bullet point in this case)

Also please read: https://wiki.whatwg.org/wiki/Code_of_Conduct - try to be respectful, ranting and blaming is not very helpful. Thanks!

[matthew-dean]

It seems like the issue is that "seamless" inherited styles, which seemed foolish to begin with. I think "seamless" would be fine if it simply "autofit" it's content, such that embedding an iframe could effect the document flow of the document its embedded in. It's too bad this wasn't just added back in with just auto-resizing.

[rniwa]

Note that auto-fitting the height turned out be a serious timing attack vector unless we restricted with CORS.

[matthew-dean]

@rniwa Oh? How did that make a site vulnerable?

[rniwa]

@matthew-dean : You can detect what kind of content was shown inside the frame based on how long it look to layout / style / paint.

[ssokolow]

I'd still find it useful if a CORS check allowed me to combine sandbox (or a second domain) and seamless to load pages I control which then contain <script> embeds for things like Disqus.

Having variable-length resources in a scrollable iframe really isn't the best user experience most of the time but, at the very least, I'd really like to be able to keep all remotely loaded content from running in the same origin as my pages.

[matthew-dean]

@rniwa I don't see how that would be possible; there are too many variables on load time, and detailed eventing would be presumably sandboxed. There are how many billions or trillions of web pages? How could you reliably profile page loads for pages that may change, and over connections that vary in latency throughout the day/week?

[rniwa]

Well, timing attack is typically done on a very specific website, which the attacker knows. A typical timing attack is robust against websites changing its content. You can read various research paper on this matter. e.g. https://www.contextis.com/documents/2/Browser_Timing_Attacks.pdf

[matthew-dean]

Hmm, still.... a theoretical successful detection doesn't equate to real-world exploits, as one of the requirements of such an exploit would be injection into the page hosting the iframe, or a user unwittingly installing a malicious script into their webpage. Even the calculate style vulnerability of the past relied on malicious scripts being allowed access in the first place.

Instead of limiting the utility of useful features of the web, maybe we should focus on the root cause, which is un-sandboxed third-party scripts having full access to the host environment instead of a limited or white-listed API. It just seems unfortunate if a very useful feature of the web becomes a casualty of poor design elsewhere.