- From: Craig Francis <craig.francis@gmail.com>
- Date: Wed, 27 Jan 2016 11:56:55 +0000
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: www-style list <www-style@w3.org>
On 26 Jan 2016, at 19:23, Tab Atkins Jr. <jackalmage@gmail.com> wrote: > Some quick conversation with fantasai suggests a few routes that we could take that would avoid a new property: Thanks TJ, Personally I like the idea of "height: auto" on an iframe, where the UA stylesheet sets it to 150px, but completely understand that compatibility might be an issue there (even if developers are doing this just to get this specific behaviour). Having said that, as the child document will need to opt-in to this, then maybe this won't be a problem? From my understanding, the opt-in is required as someone malicious could iframe another website where the user might be logged in, and depending on if they are logged in or not, the height of the document might be different. CORS might work, and uses existing technology, but this does require an additional HTTP request (not so good for performance)... so maybe there as other options? I was thinking of the X-Frame-Options header, but this seems to be moving to CSP2 frame-ancestors[1] But if this doesn't work, then "height: max-content" would also be perfectly fine for me (I just don't want to continue setting up more iframes, with 2 JavaScript files, just to avoid a scroll bar). Craig [1] https://www.w3.org/TR/CSP2/#directive-frame-ancestors > On 26 Jan 2016, at 19:23, Tab Atkins Jr. <jackalmage@gmail.com> wrote: > > On Tue, Jan 26, 2016 at 8:00 AM, Craig Francis <craig.francis@gmail.com> wrote: >> Considering the recent removal of <iframe seamless>... >> >> I've made a suggestion on the WHATWG issue log regarding what I consider the main use of @seamless on iframes. > [snip suggestion that CSS handle iframes getting content-sized] > > I agree with HTML's removal of @seamless, and with the suggestion that > the content-height part of it is still valuable and relatively easy, > and so should be preserved somehow. > > Handling this in CSS seems sensible too. If we need an > iframe-specific property, that's less than ideal, but we accepted > SVG-specific properties that only apply to single elements, so it's > not unheard of. > > Some quick conversation with fantasai suggests a few routes that we > could take that would avoid a new property: > > * Define "height: max-content" to mean content-size for <iframe>s. > This is a new value that shouldn't have any web-compat burden. > * Require "iframe { height: 150px; }" in the UA stylesheet, then > redefined "height: auto" to mean content-size for <iframe>s. This > potentially has web-compat burden, if people are explicitly setting > height:auto on iframes and expecting the current behavior, but it's > the cleanest solution. > > And agree with zcorpan that cross-origin <iframe>s would need to opt > in somehow (maybe CORS is enough?) in order to get this behavior. > > ~TJ
Received on Wednesday, 27 January 2016 11:57:31 UTC