I am developing an universal windows app. I need to download a webpage and extract images from it.
I got the html code and extracted the links to images and downloaded them. The thing is, the site has infinite scrolling (like facebook). When I scroll down to the bottom it loads more images. I am not able to incorporate this into my app. I am a beginner and have very little knowledge of web development or windows app development. This is my first app. I am stuck and have no idea how to proceed. I don't want to use webview as it displays ads from the site and other unnecessary contents. I only want the links to those images. Please help me go past this situation. I need a way to download the new html content that the site loads when user gets to the bottom or some other way to get the image links.
Thanks in advance.
You may or may not be a me to implement this specifically because of the reason you stated. You need to determine how the site loads this information. First I would download Fiddler and in turn enable https connect logging so you can see your encrypted traffic going through Fiddler. Btw the Web View has events you can hook to see loading URLs, etc and it can also be hidden.
So again you need to first understand how the site you want to do this on works and emulate that, assuming they don't have an api already to give you this information as mentioned I'm the comments.
When you do that, come back with code examples and you'll get better help.
This error keeps on appearing. How to remove this? My site is an https and the content of the iframe is also coming from an https source, I don't know what seems to be the problem?
// edited:
this is the detailed error that appears. and yes, I am using IE6.
There are nonsecure items in either your page or in the iFramed page. Look at the source code for any URL that does not begin with https://.
You will have to look very closely at all your resource references.
1) Make sure that it's the <iframe> that is causing your problem. Do as #JonathonReinhart suggested and comment it out so that you can ascertain that your issue is from there. (Edit: never mind, it appears that the <iframe> is indeed your issue)
2) Browsers are very sensitive to iframes because they can access content that is a) not yours and b) insecure. In general, though, whenever you have an HTTPS page that accesses anything (scripts, frames, images) from an HTTP page, it'll throw you a warning. However, with iframes, the browser will shut you down, with most of them disabling the iframe completely unless the user confirms that they want to access the content. I'm not sure how lenient IE6 is with this, but if there's anything that's the slightest bit fishy about the way you're accessing the content, the browser is not going to like it. You shouldn't have an issue if the HTTPS page is accessing HTTPS content, but you need to scope out all of your resources (perhaps in another browser?) to make sure that you're accessing everything securely.
3) Also keep in mind that the page you're accessing (though it may be secure itself) may access insecure resources. I would recommend going to that page and checking its resources as well, because the browser will still count it accessing those resources insecurely as your page accessing them insecurely.
I am trying to find a iframe equivalent or alternate method of inserting a page into another page, the page will still need to be active, and when I submit a form or click a link within it, it will need to function like an iframe. I know iframes still work, but now that they have been depreciating over several years, I would like to find a new method. Is there one, and what kind of scripting am I looking at?
My answer: No, there is no alternative, at least if you need to embed a page with another domain.
It is logical because you shouldn't have any cross domain access to an embedded page (for example https://americanbank.com/), which can only be guaranteed if the embedded site is captured inside a frame. And since that kind of frame is exactly the iframe, there is no space for alternatives and no reason to not use it.
EDIT: Well I have to concede there are some tricky ways but never without accessing a server side dynamic site via AJAX. So it is somehow possible but not with a comparable effort.
You can ajax in external pages that is very similar to an iframe. jQuery makes this really easy.
What we plan to do is to display a particular page from another site on our webpage (not really a whole page but it's more like a box within a page with job listings on it). However, I heard iFrame is no longer advisable to use.
Is it still okay in this instance (only 1 page and 1 iFrame)? Or are there other alternatives?
#Breezer is right in the fact that you want to use iframes as little as possible for as little of your content as possible(for SEO purposes and the fact you aren't hosting the content, so it could go down at anytime). Aside from this, I doubt the page you are trying to display is being rendered in a way that you want to display on your site anyways. Being a third party site you can use something like curl (server side) to screen scrape the data and parse out what you'd like to display on your site. Or, if you're looking for a client side alternative, you can use YQL to grab that third party information and then render as you may.
Here's a great tutorial on YQL, and doing exactly what you want, from #Nettuts (http://net.tutsplus.com/tutorials/javascript-ajax/quick-tip-cross-domain-ajax-request-with-yql-and-jquery/)
Hope that gives you some options.
well it's fine using iframes to show another external webbpage, what's bad is building an entire website around a iframe because that will be hard to search engines to interrupt what your website is about therefore rank it lower in the search results
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 9 years ago.
The community reviewed whether to reopen this question 6 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
Somewhere along the line I picked up the notion that using iframes is 'bad practice'.
Is this true? What are the pros/cons of using them?
As with all technologies, it has its ups and downs. If you are using an iframe to get around a properly developed site, then of course it is bad practice. However sometimes an iframe is acceptable.
One of the main problems with an iframe has to do with bookmarks and navigation. If you are using it to simply embed a page inside your content, I think that is fine. That is what an iframe is for.
However I've seen iframes abused as well. It should never be used as an integral part of your site, but as a piece of content within a site.
Usually, if you can do it without an iframe, that is a better option. I'm sure others here may have more information or more specific examples, it all comes down to the problem you are trying to solve.
With that said, if you are limited to HTML and have no access to a backend like PHP or ASP.NET etc, sometimes an iframe is your only option.
They're not bad practice, they're just another tool and they add flexibility.
For use as a standard page element... they're good, because they're a simple and reliable way to separate content onto several pages. Especially for user-generated content, it may be useful to "sandbox" internal pages into an iframe so poor markup doesn't affect the main page. The downside is that if you introduce multiple layers of scrolling (one for the browser, one for the iframe) your users will get frustrated. Like adzm said, you don't want to use an iframe for primary navigation, but think about them as a text/markup equivalent to the way a video or another media file would be embedded.
For scripting background events, the choice is generally between a hidden iframe and XmlHttpRequest to load content for the current page. The difference there is that an iframe generates a page load, so you can move back and forward in browser cache with most browsers. Notice that Google, who uses XmlHttpRequest all over the place, also uses iframes in certain cases to allow a user to move back and forward in browser history.
It's 'bad practice' to use them without understanding their drawbacks. Adzm's post sums them up very well.
On the flipside, gmail makes heavy use of iFrames in the background for some of it's cooler features (like the automatic file upload). If you're aware of the limitations of iFrames I don't believe you should feel any compunction about using them.
Having worked with them in many circumstances, I've really come to think that iframe's are the web programming equivalent of the goto statement. That is, something to be generally avoided. Within a site they can be somewhat useful. However, cross-site, they are almost always a bad idea for anything but the simplest of content.
Consider the possibilities ... if used for parameterized content, they've created an interface. And in a professional site, that interface requires an SLA and version management - which are almost always ignored in rush to get online.
If used for active content - frames that host script - then there are the (different) cross domain script restrictions. Some can be hacked, but rarely consistently. And if your framed content has a need to be interactive, it will struggle to do so beyond the frame.
If used with licensed content, then the participating sites are burdened by the need to move entitlement information out of band between the hosts.
So, although, occaisionally useful within a site, they are rather unsuited to mashups. You're far better looking at real portals and portlets. Worse, they are a darling of every web amateur - many a tech manager has siezed on them as a solution to many problems. In fact, they create more.
Based on my experience a positive side for iframe are when calling third party codes, that may involve calling a javascript that calls a has a Document.write(); command. As you may know, these commands cannot be called asynchronously due to how it is parsed (DOM Parser etc). An example of this is http://sourceforge.net/projects/phpadsnew/ I've made use of iframes to help speed up our site as there were multiple calls to phpadsnews and the site was waiting for the response before proceeding to render different parts of the page. with an iframe I was able to allow the site to render other parts of the page and still call the Document.write() command of phpads asynchronously. Preventing and js locking.
There are definitely uses for iframes folks. How else would you put the weather networks widget on your page? The only other way is to grab their XML and parse it, but then of course you need conditions to throw up the pertenant weather graphics... not really worth it, but way cleaner if you have the time.
The original frameset model (Frameset and Frame-elements) were very bad from a usability standpoint. IFrame vas a later invention which didn't have as many problems as the original frameset model, but it does have its drawback.
If you allow the user to navigate inside the IFrame, then links and bookmarks will not work as expected (because you bookmark the URL of the outer page, but not the URL of the iframe).
It's worth noting that iframes will, regardless of the speed of your users' internet connection or the contents of the iframe, cause a small (0.3s or so) but noticeable slowdown in the speed your page downloads. This is not something you'll see when testing it locally. Actually, this is true for any element added to a page, but iframes seem to be worse.
When your main page loads in HTTP protocol and parts of your page need to work in HTTPS protocol, iFrame can beat jsonp hands down.
Especially, if your dataType is not natively json and needs to be translated on server into json and translated on client back into e.g. complex html.
So nope - iFrame is not evil.
They are not bad, but actually helpful. I had a huge problem some time ago where I had to embed my twitter feed and it just wouldn't let md do it on the same page, so I set it on a different page, and put it in as an iframe.
They are also good because all browsers (and phone browsers) support them. They can not be considered a bad practice, as long as you use them correctly.
I have seen IFRAMEs applied very successfully as an easy way to make dynamic context menus, but the target audience of that web-app was only Internet Explorer users.
I would say that it all depends on your requirements. If you wish to make sure your page works equally well on every browser, avoid IFRAMEs. If you are targeting a narrow and well-known audience (eg. on the local Intranet) and you see a benefit in using IFRAMEs then I would say it's OK to do so.