User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:2.0b11pre) Gecko/20110202 Firefox/4.0b11pre Build Identifier: 4.0b11pre http://dev.w3.org/html5/spec/the-iframe-element.html#attr-iframe-seamless "The seamless attribute is a boolean attribute. When specified, it indicates that the iframe element's browsing context is to be rendered in a manner that makes it appear to be part of the containing document (seamlessly included in the parent document)." see also bug 80713 and details about related "moz-seamless" Reproducible: Always Steps to Reproduce: [this is a feature request]
Updated•7 years ago
|
||
Updated•6 years ago
|
||
Comment 1•5 years ago
|
||
It should be easy to implement, a small rule can be add into html.css :
iframe[seamless] {
border:none;
}
The second part doesn't work but it should be something like this :
iframe[seamless] scrollbar {
display:none;
}this is a small rule that should Implement the border [border from ntim007] as well as the second part and makes most if not all values their default that could and should be added into html.css:
iframe[seamless], iframe[seamless="*"]:not([seamless="false"]):not([seamless="no"]) {
border:none;
width:auto;
height:auto;
padding: 0px;
background-color: transparent;
overflow:visible;
overflow-y:visible;
overflow-x:visible;
}
Updated•4 years ago
|
||
Updated•4 years ago
|
||
I have HTML5 seamless iframe too , because UC Browser 9.9 support seamless iframe no prefix as release. Link browser support - http://caniuse.com/#feat=iframe-seamless Picture - http://s7.postimg.org/kc4l375nf/Screenshot_from_2014_11_20_21_24_07.png
Comment 4•3 years ago
|
||
The navigation behaviour, when the seamless attribute is specified, relies on the source browsing context (see [1] step 3). We have this now and set it fairly consistently, but not correctly in all cases. Bug 960563 tracks this. [1] https://html.spec.whatwg.org/multipage/browsers.html#navigate
This has been removed from the current HTML5 spec[1] and this bug should probably be closed. [1] https://github.com/whatwg/html/issues/331
Updated•a year ago
|
||
(In reply to Zach Lym from comment #5) > This has been removed from the current HTML5 spec[1] and this bug should > probably be closed. > > [1] https://github.com/whatwg/html/issues/331 Thanks you to result , I have to HTML5 spec to real standard.
Updated•a year ago
|
||
Comment 7•a year ago
|
||
I noticed this was referenced in at least https://developer.mozilla.org/en-US/docs/Web/API/HTMLIFrameElement
Comment 8•a year ago
|
||
Good catch :ms2ger. Thx. Entry removed.
Comment 9•a year ago
|
||
Per comment 7, the spec states: > The following properties have been added: srcdoc, sandbox, seamless, and contentWindow. Thus, the reason for WONTFIX was a misunderstanding. REOPENing on that ground. More importantly, this is a critically important feature for the web. iframes are an important security container, and having them size to content is a requirement in many places. One example is to take user contributed rich content, and render it as part of the page. Yet, the user content must not have access to the rest of the page. Concretely, if I was to write an email client as webapp, and I wanted to have a "conversation view" with consecutive emails, I would need this. I would jail each HTML email into a seamless iframe, and size the iframe to content, and then I could put 10 emails one after the other. Current webapps work around this by trying to sanitize the HTML on the server side before display. That is one solution, and they should continue to do that, but we all know that there are plenty of XSS exploits. The seamless iframe would be a welcome additional protection. The more apps migrate to the web, the more this is needed.
Updated•a year ago
|
||
Updated•a year ago
|
||
Comment 10•a year ago
|
||
The spec doesn't define seamless anymore, so I don't see how we can keep this open. If you want seamless, file a spec bug and get it defined there. (MDN seems to still mention seamless even though it isn't in the spec and was even removed from Chrome https://github.com/whatwg/html/issues/331#issuecomment-156712803)
Description
•