I think it would be nice to have an iFrame option in the items palette. It should be quite an easy option to implement because its basic styling options wouldn’t be much different from a standard box (Border, Border Colour, Size etc.)
It would, however, need an additional field for entering the target page or URL to be initially displayed in the frame.
Aligned to this option should be an extended option for links so that users can define whether to open URL’s or site pages in a named iframe within the page. Something like this.
The reason I’m making this suggestion is that this week alone I’ve addressed two questions concerning features that users want to implement that could easily be accommodated through the use of iFrames. The problem is, at present the iframe code has to be added through the code object, which not everyone is comfortable dealing with. I also think it would fit in with the developer’s philosophy of making Sparkle a total website builder without having to move out of the GUI of the app. Given that iFrames are still quite a common part of web pages (particularly those that have fixed positioning), the addition of a simple iFrame that can be scaled to size just like a normal box and then populated by simply specifying a URL or page name, could help to solve a number of the minor limitations that fixed positioning sites occasionally present.
I remember many moons ago using a product called Serif WebPlus. One of its most useful features was something they called a Document Frame - essentially an iFrame with a different name. That product has now long been abandoned, and I haven’t seen too many newer apps that made iFrame integration so simple and intuitive. I feel it would be a great addition to Sparkle, and shouldn’t be too difficult to implement because the code is relatively small with few variables - but hey! what do I know? I’m not a programmer so it may be more difficult than I think!!!
@francbrowne, I see your logic behind this and a really good explanation! :)…
For me, I have seen the use of iframes being used less and less, especially because Google is not a fan of them and flags them when tested through their online methods. Then there is the issue, if not used correctly, it can become a problem - an example… if they have SSL and the user using the iframe doesn’t or the other way around. For me I think embedding the code is a safer approach and has really worked well for me and hasn’t limited me too much!
I agree. iFrames are a bit of a dying breed but only because newer web technologies have given us expanding pages and visibility options that can be brought to bear on things such as “read-more” links or displaying a multitude of article texts or image galleries without having to leave a particular page and then return to it later. This means the design freedom that fixed positioning sites give us starts to get diminished when trying to achieve some of these, quite commonplace, objectives. Sadly, the old iframe scores quite well in these scenarios. In days gone by (before accordions) iframes were a great way to create FAQ pages. All the questions would sit alongside an iFrame and the answers would magically appear when a question was clicked. It was all basic stuff, but it did work.
I’m not so sure about the SEO aspects of iFrames, but I do know that almost every piece of embed code, from Google Maps to YouTube videos are all delivered through an iframe…
Honestly I’d rather see sparkle addressing the missing features than adding support for convoluted iframe setups.
It is already possible to enter a plain URL in the embed element to get an iframe automatically, by the way. The link support is missing but I’m not really sure how that would work in an easily explained way.
Back to my Dreamweaver days. MS Frontpage operated totally on iframes. For those reading this thread and not understanding what an iframe is or does, it was commonly used to place an HTML element on top of another HTML element. A page on top of a page if you will.
Think of layers in a drawing program. It’s a little like that.
Interesting request @francbrowne. For me it became a catch all for a lot of imbeds.
One of the problems with iframes is that you have no control over how the content displays.
You have to hope that the site you are linking to has some element of responsive design and that it will always play nicely within the bounds of your iframe.
Mind you, I’ve never needed to use an iframe and so may be missing something here…
