(Pardon the ot, but I know there are other webdevs here). For various reasons, I like to keep my html...uhh...let's say "non-bleeding-edge" :), downside of course being I tend to not be quite as up on what's out there as I should be. So just tossing this question out there:

I know (at least historically) iframes don't normally resize based on their internal content, but only based on the the outer html page. Aside from the obvious JS, does modern HTML/CSS provide any way to have something like an iframe (ie, embed content from another URL), but otherwise behaves and flows more like a div, expanding (at least vertically, even if nothing else) as the embedded content expands?

Would it be too kludgey or questionable-compatibility (or just fail) to just use CSS to set the iframe element to block-style layout?

Not that I know of. The way I do it is to set a static height in the css based on what I expect should be good enough, then do javascript to resize. There's a newish postMessage function that works pretty well for it.

It is a pity you still can't get it to automatically size though, I'd use the heck out of that.

AFAIK, <div src="..."> syntax was proposed for this purpose (with fallback) in early editions of html5, don't know if it made it into the standard.

On 25/02/2015 9:55 PM, Nick Sabalausky wrote:
> (Pardon the ot, but I know there are other webdevs here). For various
> reasons, I like to keep my html...uhh...let's say "non-bleeding-edge"
> :), downside of course being I tend to not be quite as up on what's out
> there as I should be. So just tossing this question out there:
>
> I know (at least historically) iframes don't normally resize based on
> their internal content, but only based on the the outer html page. Aside
> from the obvious JS, does modern HTML/CSS provide any way to have
> something like an iframe (ie, embed content from another URL), but
> otherwise behaves and flows more like a div, expanding (at least
> vertically, even if nothing else) as the embedded content expands?
>
> Would it be too kludgey or questionable-compatibility (or just fail) to
> just use CSS to set the iframe element to block-style layout?

My understanding of the argument against doing this is that it would be a potential security hole. If the content of an iframe could control its size it could theoretically hijack the parent page.

Instead, I would consider using JS to load and insert the content, or generate the composite page on the sever.

A...

---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com

On 02/26/2015 04:34 AM, Alix Pexton wrote:
>
> My understanding of the argument against doing this is that it would be
> a potential security hole. If the content of an iframe could control its
> size it could theoretically hijack the parent page.
>
> Instead, I would consider using JS to load and insert the content, or
> generate the composite page on the sever.
>

Ehh, I'm not sure I buy that.

1. I don't see how the inner content could "squeeze out" the outer page unless the iframe/external-div/whatever is the very first piece of content on the page. Which is highly unlikely since pretty much every site at least has some header logo/banner/menu or something.

2. Using JS to fill an element or server-side compositing suffers from the same theoretical issue too. So really it has nothing to do with iframes and everything to do with embedding external content (which has become ubiquitous anyway, what with ads, jquery, various google tools, disqus, twit/face share widgets, etc.)

Sure, with JS or server-side compositing, there's at least the possibility of sanitizing the inner content first, but that'd be a heuristic mess, and perhaps a pointless bother anyway since...

3. Even if all else fails, the outer page's author should easily be able to mitigate such a problem with a reasonable max-width/max-height.

I think the big thing though is the "really it has nothing to do with iframes and everything to do with embedding external content".

I don't think it is a security hole, but websites typically do not get to set their viewport - the window size is under the user's control. (one of the few things they have left under the user's control!)

So if you told a site to set its own size... it wouldn't really know what that is most the time. At least widths tend to be fluid and variable. Heights sometimes are set dynamically too.

There's solutions to this - the containing page might set it to a width, then let the height be fluid. That's what most the JS solutions do and it works pretty well. But maybe that still feels too hacky for the standards committees, or is just messy to implement for the browser developers.

On 02/26/2015 03:30 AM, Kagamin wrote:
> AFAIK, <div src="..."> syntax was proposed for this purpose (with
> fallback) in early editions of html5, don't know if it made it into the
> standard.

Hmm, just looked that up, but all I found on that was one page that implies (sadly, with no sources referenced) it did not make it in:

http://hannah.wf/why-dont-all-html-elements-have-a-src-attribute/

However, looks like what happened instead was iframe grew a "seamless" attribute, which frankly looks pretty damn sweet:

http://benvinegar.github.io/seamless-talk/#/12

Still researching browser compatibility and adoption though.

TL;DR: New in HTML5: <iframe seamless src="url" /> is the answer (assuming it isn't still *too* new, not sure yet)

On 02/26/2015 02:51 PM, Adam D. Ruppe wrote:
> I don't think it is a security hole, but websites typically do not get
> to set their viewport - the window size is under the user's control.
> (one of the few things they have left under the user's control!)
>
> So if you told a site to set its own size... it wouldn't really know
> what that is most the time. At least widths tend to be fluid and
> variable. Heights sometimes are set dynamically too.
>
> There's solutions to this - the containing page might set it to a width,
> then let the height be fluid.

Yea, that's kinda what I had in mind anyway. All these "embedded widget" things are such a major thing now, and I totally get their appeal and value (want X feature on your site? Just copy/paste this snippet into your page REGARDLESS of your server's language/engine!) But so much of it is done with JS, which is totally unnecessary. Most such things can easily be no-JS iframes (and I guess some are), but one problem is stuff like disqus that needs to grow/expand vertically. Traditional iframe can't really handle that. Looks like HTML5 iframes, thanks to the seamless attribute, WILL be able to handle something like disqus just fine with NO js, but looks like seamless is still rather cutting edge and spotty compatibility despite having been a thing for several years already. Maybe it can be managed well enough with CSS tweakery though, for browsers that aren't ultra cutting edge.

> That's what most the JS solutions do and
> it works pretty well. But maybe that still feels too hacky for the
> standards committees, or is just messy to implement for the browser
> developers.

On 02/26/2015 02:51 PM, Adam D. Ruppe wrote:
>  the window size is under the user's control.
> (one of the few things they have left under the user's control!)
>

Yea. Speaking of, that mobile-directed "no zoom" css thing is seriously fucking evil. If browser devs had any basic integrity whatsoever they'd deliberately ignore that abomination of an attribute, or at least let any B&D users who enjoy being told what they can't do on their own miniature device just opt-in to it.

On Thu, Feb 26, 2015 at 03:36:04PM -0500, Nick Sabalausky via Digitalmars-d wrote:
> On 02/26/2015 02:51 PM, Adam D. Ruppe wrote:
> > the window size is under the user's control.
> >(one of the few things they have left under the user's control!)
> >
> 
> Yea. Speaking of, that mobile-directed "no zoom" css thing is seriously fucking evil. If browser devs had any basic integrity whatsoever they'd deliberately ignore that abomination of an attribute, or at least let any B&D users who enjoy being told what they can't do on their own miniature device just opt-in to it.

I find this trend extremely disturbing and exceptionally annoying. I wish every browser would come with an option to override everything the author tries to shove down your throat and using what YOU, the user, specify as default instead.

Opera used to have an "author mode" and "user mode", where you can set up custom CSS that completely replaces the website's CSS at the touch of a key. Whenever I come across an annoying site with unreadable fonts, garish colors, way too many ads, or text that's unreadable unless you turn on JS (ha! nice try!), a single key-combo discards that whole nonsense and restores power to the user. Bam. Sadly, after they ditched Linux, the Presto engine, the original devs, and jumped on the Chrome bandwagon, Opera is pretty much dead as far as I'm concerned, so these days I'm using Vimperator/Firefox instead. While it *is* possible to setup user CSS, it's more tedious than it has to be, and I'm not sure if it's possible to make it switcheable via a key without having to edit .css files manually.

Although, on second thoughts, that's not necessarily a bad thing... a universal stylesheet that removes all useless font changes, colors, extraneous images, and formats everything into fixed-width 80 column paragraphs, now that could the ticket to pure bliss! :-P Just give me the content, m'am, keep all the frills to yourself. Oh, you mean there's nothing left after the frills and eye-candy are gone? Well, then, I'll move on to another site that actually sports content, thank you very much, have a nice day.


T

-- 
Lawyer: (n.) An innocence-vending machine, the effectiveness of which depends on how much money is inserted.