I am working on a web app consisting of 2 apps (one made by me, one 3rd party) residing side-by-side on one webpage. I have been using an iframe to embed the other app, but I want the size of the frame to be changed. Now, I could try going for a solution using javascript, but experience tells me, resizing in javascript is error-prone and inperformant. I am seriously considering to use a frameset in this case.
The arguments against frames I have seen so far do not apply to my case in the slightest, nobody wants to bookmark only a part of the page, the 3rd party app can be accessed externally anyways.
Now, I am wondering how bad the idea of using a frameset really is, I think I saw it being deprecated in the future, meaning support for it could be lost in near future? What other alternatives are there?
Related
I’m building a simple browser, and I’d like to code most of it using HTML/JS/CSS. I cannot use iframes to display pages, due to frame-busting. What are my options?
The browser is not meant to be production-quality, but as a proof-of-concept for my thesis, similar to this interactive mockup. The main features it will need to support are:
Loading any page without frame-busting (even google.com),
Detecting when a link is clicked and opening it in a new frame, with the original one remaining intact.
I intend to write this using Web technologies, but it’s OK if it needs to be wrapped up in a small amount of something else, e.g., to turn it into an Android app. However, if it’s possible, it would be best if I could load the app as a web page. Finally, it is also preferable to be able to run the app on an Android device, but it’s OK if it only works on a desktop.
In researching this question, I came across a few options:
<iframe>. Google.com doesn't load at all in an iframe. I tried using the sandbox attribute, but it still didn’t load. Is there a way around this (for any page)?
Mozilla’s Browser API. This API was supposed to allow you to use the mozbrowser attribute in an iframe when building FirefoxOS apps. I suspect there’s no longer any way to access it. I couldn’t get the sample browser app loaded, and it seems that mozbrowser is not supported in WebExtensions. Did I miss something? Is there a way to make this work?
<webview> in a Chrome app. This is the only option that worked so far. I was able to download and install the sample browser app in Chrome. The one downside is that it seems to be Chrome-only (and I would prefer cross-platform or Firefox, all else being equal). Are there any issues with this option? Any way to make it run without Chrome?
Electron app with <webview>. While the setup here is more complicated than the previous option, it seems like the code would be very similar (there’s even a similar sample browser app). Are there any advantages/disadvantages to this option over the previous?
So, are there ways to make options 1 or 2 work? Are there perhaps other options?
HTML/CSS is a "language" translated by the browser into pages. You cannot code a browser in HTML. The easiest solution is to code it in C#.
I'm not sure if this is a good solution, but you can try Electron (nodeJS). You will only need to use JS/CSS/HTML.
I want to know if a html video is being displayed on a browser, from outside said browser, ideally without any plugins or such.
Motivation - I am trying to add this feature to Caffeine which is a Linux utility which disables the OS screensaver if, say, you are watching a movie.
The flash support was done I believe by detecting the presence of particular files or folders created by the plugin.
Ideally I would like 1 solution, but if I get 2 solutions for Firefox and Chrome, that's good enough.
p.s. Ultimately this would involve python code, but I am not sure if that is sufficient to make this question on-topic, or if this belongs on Superuser or Unix&Linux
This reminds me of something a web browser I was building in VB .Net which needed to detect if there where web pages that had tags like <a href="tel: or <a href="smsI know you said you didn't want a plugin but I would think you could easily right a browser plugin for for just this. In fact not exactly what your looking for but theirs a script monkey script called Hangouts Unlimited which prevents you from getting annoying messages asking if your still awake while in a G+ hangout. I don't know much about python but I would recomennd trying to identify the elements of the tags and when ever it finds such tags to disable the screen saver. Obviously the hangouts unlimited doesn't affect the web browser and that is most likely why you prefer not to have a browser plugin because you need to access system files outside of the browser. But I hope this helps a bit.
I really want a way to have one single file for, for example, the navigation bar and the footer so that I don't have to go through all of my pages (only 20 or so, but anyway...) to update it. So I've realized that frames (iframes? What's the difference) can help me with this.
Additionally, I've heard a lot of places that frames are a no-go in web design for some reason. Is this to do with SEO?
Can I use (i)frames safely? Are there alternatives that keep the url http://www.domain.tld/pagename.html ?
Whatever you do, don't use frames/iframes for page layout.
Your best bet is to use a server-side scripting language to build your page. That way, you can have the individual components in separate files (which makes maintenance easy) and then compose them using the scripting language.
So I've realized that frames (iframes? What's the difference)
An iframe embeds a document in the middle of a page.
A frame is part of a frameset, which consists of an entire page.
can help me with this.
They could, but have plenty of drawbacks (mucking up linking, printing, causing scrolling issues, etc). Use an include (e.g. php or ssi) or template system (e.g. template toolkit's ttree) instead.
Adding to these two good answers, from the SEO point of view a frame based site is also might be a bad idea.
Google supports frames and iframes to
the extent that it can. Frames can
cause problems for search engines
because they don't correspond to the
conceptual model of the web. In this
model, one page displays only one URL.
Pages that use frames or iframes
display several URLs (one for each
frame) within a single page. Google
tries to associate framed content with
the page containing the frames, but we
don't guarantee that we will.
See this
As a side note, have yo considered 301 redirect? It is not precisely keeping the same address, rather the opposite but it might be what you want if I understood your concern.
HTML has had frames from early days, but they are deprecated in the latest version. Many browsers (I have tried with Internet Explorer) don't even display frames properly.
Why has this been done? What was the drawback in frames?
Jakob Nielsen wrote a 1996 column that criticized frames. Some key points:
Frames prevent users from properly bookmarking pages. When a bookmarked frameset page is loaded, users' previous mouse clicks inside the frames do not matter. Only the outer URL is saved, and users have to navigate to where they were manually.
Frames present challenges for printing web pages. Printing all the frames at once is not suited to the different dimensions of paper (and users can get only the first pageful that way). Users generally have to right-click the frame they want and choose the appropriate context menu option.
Users coming from search engines may not have access to navigational elements if they are located in another frame — they are directed to only that frame the search engine found the text in.
While "framesets" (the most common type used on late 1990s/early 2000s web pages) are dying, the iframe (short for inline frame) remains alive and well. In fact, recently iframes have been found useful in today's "mashup" web applications, and extensions to the iframe are currently proposed in the HTML5 specification.
For example, Facebook, in its API for app developers, uses them to seamlessly integrate third-party apps with their own site while minimizing the security risk. (In this model, all third-party code remains on a separate domain, which is good for security reasons.)
Frames are not deprecated in HTML. They are obsolete in HTML 5, and just discouraged before this version. This has been clearly mentioned in the specified links.
Not to answer the OP but rather balance the bashing of framesets.
I find them great and nothing comes close to them when you want your menu intact and still:
Visually incorporate 3-rd party pages/apps (phpmyadmin or similar)
Viewing doctypes other than html (pdf's or images).
Due to its width="x,*" you get a simple "responsive" behaviour.
Also, you can provide smooth menu-animations while fetching main contents.
Used with sense, they're super.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I haven't used frames since 1998. They seem like a bad idea and in all my development I've never had a situation where frames were the right solution, or even a decent solution.
However, I'm now working with an internal web application written by another group and the entire site is built in a - header, left side menu, right side content - frameset.
For one, when VPN'd to my network I constantly get a "website.com/frames.html" cannot be found." error message. This doesn't happen when I'm on the internal network.
Second, the app has a built in email/messaging system. The number of unread messages is shown in the left side menu frame as "Messages (3)" but the count doesn't update as I read the messages. The developer told me since it was in a frame I needed to right click on the menu and 'Refresh'. Seriously????
So, my programming related question is, what reasons do you have for not using frames in a website?
Although they solved a problem at the time they were created (updating part of a "page" while keeping in place a non-updating part), framesets were criticised in terms of usability pretty much from the start, as they break generic functions of the browser, such as:
bookmarking, and copy-and-pasting URLs to share
printing the page as displayed on the screen
reloading the page: since the URL has generally not changed, you will often be taken back to the site's homepage or default frameset; manually reloading some frames is possible, but not obvious to the user
back and forward buttons are ambiguous: undo/redo the last frame change, or take you to the last time the URL bar changed?
The heaviest burden of avoiding framesets - including the same content on every page - is trivial to solve if you are using any server-side language to generate your HTML, even if all it provides is a "server side include". Unlike framesets, a server-side include could occur anywhere on the page; building a site with a server-side scripting language or templating system has other obvious advantages too.
There is still an advantage to being able to update small areas of the page without reloading the entire content, which can be achieved via AJAX. This sometimes leads people to create interfaces with all the problems of framesets outlined above, but that is hardly an argument in favour of framesets. Again, a site built with well-designed AJAX functionality can achieve things which framesets don't even begin to address.
One good reason to avoid frames today is they have been deprecated in HTML 5: Chapter 11 Obsolete features
11.2 Non-conforming features
Elements in the following list are entirely obsolete, and must not be
used by authors:
[...]
frame
frameset
noframes
Either use iframe and CSS instead, or use server-side includes to
generate complete pages with the various invariant parts merged in.
The #1 reason? Users hate them.
Even if they offered advantages in other areas (separation of code, application design, speed etc) they are part of the user interface. If users don't approve, don't use them.
Frames were vaguely useful when you had a static web site, to avoid repeating navigation menu in all pages, for example. It also reduced the overall size of a page.
Both these arguments are obsolete now: sites don't hesitate to serve fat pages, and most of them are dynamically built so including such navigational parts (or status, etc.) has no problem.
The "why" part is well answered above, partly by your own question (you hit a limitation, although it can be overridden with a bit of JS).
My number 1 reason not to use frames is because they break the bookmark (aka favorite) feature of browsers.
With the technology that exists today, frames have become obsolete. But if your legacy project still uses them, you can make the messages update with some ajax.
Just because of the cell phone iPad craze doesn't mean that highly functional full featured sites are suddenly "obsolete", and those who decided to make framesets obsolete seem to be the same complainers who never figured out their full potential in the first place, or maybe they're the lobbyists of the mega-corporate cell-phone and tablet makers who couldn't be bothered to make a decent frames capable browser for their itty-bitty screens.
Admittedly, iFrames can handle simple jobs like scrolling and/or displaying independent segments within a single page pretty well, and I use them for that inside my own frames based website, but to get them to work as well as the foundation for a site itself is a nightmare. Trust me, I know because my website is one of the most sophisticated frameset based sites on the Internet and I've been looking at the pros and cons of transposing it all to iFrames. Nightmare is an understatement.
I can already hear the whiners saying, "Well why did you build it that way in the first place then?" ... and the answer is A: Because I'm not lazy. and B: Because a frames based site is the most functional, visually appealing, and user friendly format for an information based site with hundreds of pages of content that doesn't have to rely on a server. By that I mean all but the external advertising can be viewed straight off a flash drive. No MySQL or PHP needed.
Here's some of the issues I've encountered:
The objection to orphaned pages can be easily handled with JavaScript.
The objection regarding bookmarking is irrelevant unless you use no frames all.
Content specific bookmarking can be handled with an "Add Bookmark" JavaScript function
The objection regarding SEO is easily handled by an XML sitemap and JavaScript.
Laying out dynamically sized frames is far easier and more dependable with standard framesets.
Targeting and replacing nested framesets from an external frame is easier with standard framesets.
In-house scripts like JavaScript searches and non-server dependent shopping carts that are too complex for cookies don't seem possible with iFrames, or if they are, it's way more hassle to get them working than using standard frames.
All that being said, I like the single page appeal of iFrames, and when they can actually do all the same stuff for my site as easily as standard frames does now, then I'll migrate. In the meantime, this nonsense about them being "obsolete" is as irksome as the other so-called "upgrades" they've foisted on us over the years without thinking it all the way through.
So what does all this boil down to for the question of whether or not to use framesets? The answer is that it all depends on what you want your site to do and on what platform it will mostly be viewed on. At some point it becomes impractical to make a multi-page site work well without some frames or iFrame integration. However if you're just creating a basic profile page that displays well on a cell phone or tablet, don't bother with framesets.
They almost always make people angry. What more do you need?
Frames are really useful in some occasions. If you are creating a local webpage that serves only for reading, no interactivity involved and the website will not be public on the internet, all the reasons on not to use frames are removed. For example a user manual for an application that is developed solely in html, frames are really useful in keeping a table of contents on the left in a simple and easy to code way. Also if you have proper navigation within the website then the back button ambiguity is removed completely