I would like to use iframe html5 tag in my web project (ASP.NET MVC5). But I am wonder the browsers not allowed display content. So is using iframe dead?
My goal is wrap the payment gate window to iframe tag and place to my web page.
Iframe is not dead. It is still widely used, mostly for advertisement (third parties can serve content without intervention from the site admin). This answer mentions some valid points.
You can separate websites and domains easily without security concerns (cross-domain policy). That makes it unique and irreplaceable.
It works?
Yes.
But...
It was deprecated in HTML5, tough some browsers still support it I do not recommend you to use it in your projects.
The problems
1) It was removed from web standards, you maybe get some problems while trying to access your page from newer browsers.
2) It's SEO unfriendly. A webpage was supposed to only have one URL, but if you use frames your page will have multiple URLs (one for each frame).
3) If the frame source isn't reliable you can get security problems.
Sites that use it
JS Bin, JS Fiddle and Codepen are good examples.
I am about to develop a web site for data entry. It will have hundreds of data entry pages. Previously i have made extensive use of iFrames from the menuing system.
Is this now best practice, i number of developers i have mentioned this to have questioned the use of iFrames saying there are better techniques now. However no one could give me a reason not to use the iFrame.
Does anyone have some opinions on the use of iFrames and the reason i should not use them? If not an iFrame then what?
An iFrame is to embed foreign content, another site or another page of your site. Web is not only about what you see but about semantic meanings.
Using iFrames is the most effective way to kill your ranking in search engines and also to difficult web browsing since a browser cannot tell what part of the content represents what or how they are related to each other.
For instance, navigate into an iFrame based page and bookmark an internal page, then come back through the bookmark and see the results.
Do a search in Internet and there are many more explanations about this.
I understand that frames are a lot more typing work to implement than Iframes, and that they require a lot more styling than Iframes. I am currently working on a website which must download some content (in fact, an entire set of webpages) from another website, one - by - one of course depending on the user's action on the main website. Iframes seem to be a short and rowdy way to implement this requirement, but what I am worried about is performance and integrity.
I would like some advice on what I would rather use when the following criteria is met:
The pages that must be downloaded onto my webpage are quite large (width and height)
Contains multiple images
Experiences occasional downtimes (maintainence)
any ideas for a man in wonder?
At this point, go with iFrames:
iFrame is HTML5. Frameset is obsolete in HTML5.
You have to load pages into each Frameset. iFrames can be embedded anywhere in a document.
You can style, hide, resize either, but iFrames are much easier to work with in this regard.
I've seen cases where the developer went with Frameset because he couldn't get the iFrame to size properly, but this isn't too big a deal with a little Javascript (if even that). The only reason to use a Frameset is if you don't fear it's eventual deprecation with modern browsers, and/or if you can't get iFrames to size the way you want based on the content you're integrating and need a quick solution.
If this is about display of 3rd party data in your site, you could use data feeds from the other sites if they're available, or use a screen scraper to extract the information you need, then display it in your own way on the page.
Unless it needs to look exactly like to other page.
Check out this link on screen scraping for ASP.NET
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
For me iframes are pure evil (well, maybe not so pure). They seems to make a lot of troubles. Yes, your whole site will load once and then you can just load single pages. But people invented AJAX for this purpose.
One of the biggest issues I found with iframe was that I couldn't paste a link to one of the subpages, because the URL never changed (yes, I know there is a workaround for this). Second thing, web search engines may have problems indexing such pages.
Sometimes the accessibility of this sites are worse and some browser can even display them improperly.
There are better ways to design layouts without iframes. Everyday I can see some one asking at SO questions, like "How to access iframe with jQuery?".
So what are the benefits of iframes? What reason can it be to still use them? I just would like to know why.
I can think of 2 reasons (at the moment) why people would still use iframes instead of AJAX:
1) Iframes circumvent the cross domain origin policy (images, scripts, and styles do not). This can be useful for pulling in sites / content from other domain names relatively safely. Basically, this allows the advantage of being able to visually show data from other domains without letting them stomp all over your page with unlimited access (like something like JSONP would be able to do).
2) You can load multiple types of resources from within an iframe, not just certain mime-types (you're relatively limited to application/javascript, application/x-javascript, text/css, text/xml, image/png, image/jpeg, image/gif with scripts, XHR, images, and sources). For instance, if I want to show you a PDF, I can open an iframe and let the Adobe Reader plugin show you that file. Additionally, in the same domain, if I want to pipeline a script, style, and image all together (inline on the page, image would have to be data URI), I can accomplish this with an iframe (and if it's in the same domain, port, and protocol I can access it with JavaScript as well).
Did you know that Gmail is a set of iframes? The visible part is just clever positioning. Additionally, many OAuth implementation (Twitter, Facebook, Google, Yahoo!) usually use iframes to associate a user on their domain with a successful authentication URL (for after the user logs in).
IFRAMEs are used to embed and isolate third-party content into a website.
Most of web advertising solutions are based on iframes - because they give security (cross-domain policy) and isolated rectangle on screen which can be fully managed by third party content and scripting (a common use case is advertisments).
Another modern use of IFRAMES is a management of history (common back button workaround) of AJAX applications.
FRAMEs are poor version of IFRAMES. Their use is declining.
If a user has javascript disabled, iframes will work when ajax doesn't. This is not out of the question, considering that people use things like NoScript.
I use them on ajax websites, when I need to upload files without reloading the page.
I still see iframes being used in large corporations where they provide a single sign on which injects header information about the authenticated user which is then passed, via an iframe, towards the actual application(s). Since the "portal" surrounding the iframe handles all the specific authentication details those applications behind it don't need to have each an implementation for it, making things easier to make for the development team and having a single place to monitor and adjust authentication details of users.
There are plenty of technical reasons to use them (especially the security issue mentioned by Dan Beam).
What you shouldn't do is use iframes “like frames”, doing navigation to new pages by updating the iframe only. As you say, this prevents the navigation from being bookmarkable/linkable, responding to the normal navigation buttons, and providing useful link affordances like open-in-new-tab.
But that's not peculiar to iframes. You can see more and more pages where the navigation is done by fetching new content with XMLHttpRequest and writing it to the main content div's innerHTML. Often this is done with jQuery load() and clever-clever slidey animations. This breaks navigation just as badly as iframe-used-as-frame, or indeed old-school framesets. It's a shame so many web authors are using this tactic believing it to be a super-modern web design methodology, when really it's just a new skin on yesterday's despised framesets.
You can work around it in both cases, but it means you have to store a viewstate in the # fragment identifier part and support proper hash-navigation, which isn't trivial. Even then you've still got problems with non-JS agents like search engines; you end up having to have a parallel ?-based and #-based navigation to support both. It's a pain and most don't bother.
Framesets are outdated as of HTML 5, and sometimes you need to have a frame with another site within a site.
Also AJAX can only do so much. Try uploading a file to a site on another domain through https without an iframe. AJAX won't help you there.
In addition to others reasons, I have one specific usage of iframe in my application. Unfortunately, the target browser in my case is Internet Explorer 6. I need to have a footer and a header that are fixed in my web pages. The main part of this page is scrollable.
However, there is a bug in IE6 where I cannot display a div element on top of select elements using the z-index CSS property. Thus, I need to create an iframe that will be used as a hack to avoid this problem.
Of course, this is a really specific usage of iframe and only concern IE6...
Javascript WYSIWYG Editors use iframes, because that is easiest and best way to make it. For example TinyMCE uses it:
http://tinymce.moxiecode.com/
I was building a social network and i see iframes being useful for widgets to put on other peoples website to show like a mini profile or integrate with the content on a remote server. Seems like the most simple way to build this. I know some widgets use JavaScript. Also with the iframe method the session is the same as visiting the site like normal, so great for like buttons.
Many Formatted Text Editors (e.g. TinyMCE, HTMLArea) are implemented as iframe.
iFrames are okay for some cases, as X-domain-requests, or posting data to a source via parameters. But when I want to access data across domains, I prefer using CSS-files - they can accept params, set cookies, add content to the page (:before & :after) and give a visual feedback.
What are your techniques to using mobile with asp.net, I know how to detect mobile but I'm stumped trying to find a good way to show my pages on a mobile device.
I'm thinking of just doing a Multi-View and showing the mobile view when they are mobile, however that would not work with our masterpage unless I do same, I'd rather just have the page redirect to a mobile version.
But I'd like this to happen automatically, don't want to add the code to every page, I've used an HttpModule but it causes every object in the website to use it, only want this on aspx pages so I just used a user control that it put on the top of the master page.
I also added a folder called mobile in the tree that contains folders for each mobile device, so if they go to ~/Account/Login.aspx it redirects to ~/Account/Mobile/IPhone/Login.aspx but i had to exclude the masterpage in the mobile device or it'll be in an endless loop :)
I like the way MVC does it where they have a custom ViewEngine that just redirects, but I can't go MVC due to some ASP.NET controls that my company requires.
Ideas?
It very much depends on the particular site and what has prompted you to consider having a mobile version of the site. How much content do you have that is unsuitable for mobile browsers (e.g. Flash, AJAX) ? How complex are these custom controls that you mentioned?
Personally I think it is best to try to design your main site to be compatible for people browsing on more recent smartphones (e.g. iphone, Android) since they are becoming very popular and increasingly capable. These phones have browsers that are normally based on WebKit so testing in Chrome or Safari would give at least some idea of how well your page would work.
If necessary then you could use slightly different stylesheets for desktop and mobile. You make the page more accessible by hiding unimportant content and simplifying navigation.
ASP .NET actually has a complex device filtering system built in, so you can change parts of the page, even the master page to use, depending on the current browser. See here: http://ryanfarley.com/blog/archive/2008/08/14/more-on-device-filtering-with-asp.net-server-control-properties.aspx. You just need to make sure that your browser definitions are up to date.
Avoid complex ASP .NET controls like GridViews since you have less control over the HTML and CSS. Controls like the ListView are much more flexible.
Some functionality like AJAX might be a bit buggy on certain devices, especially if you are using AJAX UpdatePanels. You could use an emulator to test these scenarios. Alternatively you could disable these features on mobile devices. That's assuming your even using them.
To accommodate low end devices you could have a separate mobile site that runs in parallel. To create mobile pages, you inherit from System.Web.UI.MobileControls.MobilePage instead of the normal Page class. W3Schools has some useful information: http://www.w3schools.com/dotnetmobile/control_mobilepage.asp. Note that mobile web forms is now deprecated though so it is not considered the way forward.
If you are going to run two or more sites in parallel and you have complex logic needed by both then you could create a class library to hold the shared functionality. It would cut out some code duplication.
To avoid an infinite loop when redirecting to the mobile version, just check the current URL to see if it contains the base URL for the mobile site. It might be easiest just to do the redirect on the main page but have a link somewhere on every page that goes to the mobile version when clicked.
Overall it is a very complex subject so perhaps consider getting a suitable book.