I'm trying to display an iframe, which can be pointed to various urls, and would like to dynamically resize it to display its contents without a scrollbar.
How can I find those dimensions?
I don't think this is possible. Many sites resize their content to fit their container, so resizing the container to fit the content will be messy at best. Additionally, due to the single-origin policy, JavaScript won't be able to inspect the page loaded in the iframe if it comes from another site, so I don't think you'll even be able to tell if it needs to scroll or not.
You could approximate it by calculating the dimensions ahead of time, but even then it would only be a guess, since the exact size of objects in the browser is controlled only by the browser. If the user has picked a large font size, for example, there may be no size you can expand the iframe to that will be big enough for the user to see the entire page without scrolling.
You can only do it by communicating between the iframe and your website. This is the technique OpenSocial gadgets use for example. This is only possible if both the iframe and the parent are under control, in which case you can use HTML5 cross-window messaging and fall back to other cross-domain hacks if the browser can't deal with that.
You could also try to avoid the iframe by pulling the site directly and serving its content. That would only be possible for a very limited number of sites, mostly just static sites, and even then, not ideal by any means.
Related
I am developing a web site for selling handy crafts so users expect high quality images for per product. because of SEO related problems, I think about loading image asynchronous and just when user reach to per product thumbnail.I don't know how find out that when each user reach to per prouct thumbnail when scrolling page to load main and hight quality image for it; are there any event in javascript for detect that? or I have to calculate by pixels or some way like that?
What you are looking for is called "lazy loading". Lazy Loading means that the required resources are only loaded once the user actually needs it. In this example, the user only needs the image once the image is actually in the viewport (the elements visible on the screen)
The easiest way for Chromium-based browsers and Firefox is using the "loading" attribute of the img-tag and setting the value to "lazy". Example: img loading=lazy src="link"
This will work for most cases. However, if you want to be in control of the functionality behind it what you are searching for is called a "Intersection Observer". With this you can do alot of stuff related to elements and the viewport. E.g. how far is an element away from the viewport, or how much percent of the element is actually in the viewport.
If you want a really short 15 minute video that explains the Intersection Observer basis I can recommend this YouTube video:
https://www.youtube.com/watch?v=2IbRtjez6ag
I hope that this will be enough to help you with your problem!
I'm familiar with two approaches for scaling content in UIWebViews that are on the smaller side (>~320 points in width).
The first approach is to set the appropriate frame size on the web view and the scalesPagesToFit property. This works fine but may easily result in content being presented at such a size that it is not easily consumed.
Another approach is to inject JavaScript to set the content's viewPort width programatically. This works on sites that are intended for mobile presentation (eg, responsive web design). If you're presenting a website that was coded for mobile consumption, the results with this are far superior in terms of content legibility than using the scaleToFit property.
The trouble is that these two approaches are mutually exclusive, or so it seems. If you scale the contents of a site that doesn't feature responsive design and then inject the JS to set the viewPort, you end up with an illegible content frame that scuttles the good work of scalesToFit.
Is there any way to detect programmatically, when a page will respond to the javascript injection as expected and optimize the site for the presentation size, versus when the page will not respond to the javascript but injecting it results in the undoing of the auto-scaling?
Let me start off by saying I really like Superfish (& jQuery). Unfortunately, this - apparently? - does not offer cross-frame support out of the box.
Situation: extranet website, consisting of 2 frames, divided horizontally. The top frame (the smallest one) contains a menu. When hovering over this menu, the "drop down" content gets displayed in the bottom frame (over the other elements there, of course). Here's an example (and actually, the solution we're using today): http://javascript.cooldev.com/scripts/coolmenu/demos/frames/
So does anyone know a way to build a clean (using standard HTML/CSS and as little as JS as possible) solution? Any help would be appreciated! :)
I guess the armies will take on the »ditch your frames« thing, so I won't. I'm assuming you have informed yourself of frameless alternatives and have come to the conclusion that you need frames (for whatever [absurd] reason).
The short story is: you cannot break out of a frame, same as you can't break out of a window. All content is contained within the frame / window - there is no way to have content bleed through.
That said, you have two options left.
Your parent document happens to be a regular document containing two iframes, and all documents are served from the same host (SOP). In this case your menu-frame can create elements in the parent-frame that actually overlap the iframes themselves. So you could position an element within the parent-frame to appear below the corresponding element of the menu-frame, while having it z-indexed over the content-frame
Your parent-frame is a frameset-document and thus doesn't take any content other than frames. You're shit out of luck. The only thing you can do is have your menu-frame do the same trick described in (1), but append the menu-elements to the content-frame.
Either option sucks. If you have the option, ditch your frames. Any dumb server-side language (php, ruby, python, …) allows you to extract often re-used components (like a navigation) into seperate files and link them in every other document you've got. SSI might be an option, too.
If the only reason you're using a frame is to keep the menus attached to the top of the window, then you can simply use position: fixed in the CSS.
Building a drop-down menu system that crosses frames is like building a normal drop-down menu system (mouse over the menu "head", show the menu "body"; mouse out of the head, hide the body; etc.), except:
Since elements cannot actually cross frame boundaries, the best you can do is to have the head in one frame and the body in the other (like COOLjsMenu).
To coordinate the two halves, you can either (depending on the situation) have one frame directly manipulate the other frame's elements, or pass messages between frames and have each frame manage its own elements.
So the extra complication is how to manage the two halves:
If both frames come from the same origin, then JavaScript from one frame can directly manipulate the other frame's elements. (Since you are using COOLjsMenu, I would assume this is the case for your extranet.)
If frames come from different origins, then they cannot manipulate each other's elements, though you may still be able to pass messages between frames:
If you only need to support "modern" browsers (Firefox 3+, Chrome, Safari 4+, IE 8+, Opera 9.5+), then you can use window.postMessage().
If you need to support older browsers (namely IE 6-7), you can use easyXDM (which also uses window.postMessage() if available in the user's browser).
In this case, you will need JavaScript in each frame to manipulate its own elements and communicate with the other frame.
Actually building a cross-frame drop-down menu system is left as an exercise for the reader :-)
You could just use a pure-CSS menu (like http://csswizardry.com/2011/02/creating-a-pure-css-dropdown-menu/). I'm not sure exactly why the navigation is in a different frame, but this will give you the functionality and flexibility to move the drop down lists up or down (by adjusting the padding/margin/top properties in CSS) to fit to the bottom of the frame.
The ideal solution would be to NOT use frames. Instead, you should ideally have your menu setup with a fixed position. The correct CSS for your menu element would be:
position:fixed
You may have to make some other tweaks, such as setting the z-index of your menu to be greater than the rest of your document. If you used fixed positioning, you might be able to get away with using NO javascript. Here are a few examples of menus that use fixed positioning:
Collection of 21 fixed position menus -- For example, the Face Works menu does pretty much the same thing as your menu without using frames.
CSS Floating Menu
CSS: fixed menus
You should note that a frame cannot access content outside of itself. There is no CSS/JavaScript that will let your top frame gain access to the contents of your bottom frame. It would be a security flaw to allow for this to happen. If you really need to use frames then stick with something similar to your current solution.
I hate to play devil's advocate, but you can break out of frames, because at my work we have a JavaScript menu that does just that. It's a very old library but it does do it. You can see the grey frameborders quite clearly and the menu is breaking out of the top frame and appearing over three other frames.
We've used drop down menus with cross frame support before without a too much of a problem. One way to do it is with allwebmenus, a powerful javascript menu builder with lots of really great features, and includes cross frame support out of the box: http://www.likno.com/examples.html?example=crossframe
This page explains how likno does it: http://www.likno.com/drop-down-css-menu/compilepropertiescrossframe.htm.
Deluxe menu also does a similar thing:
http://deluxe-menu.com/data-samples/cross-frame-horizontal-1-sample.htm
and is cheaper if you only want to do it on a single website, but more expensive for multiple sites.
Are there any differences in performance or load/caching behavior when displaying images in img tags vs divs with image backgrounds?
My example:
I have a site with many overlapping images, some of which I will need to load dynamically with javascript. One issue is that I need to anchor the images to the right of the element, so that I can do a nice wipe-to-right effect. Because of this I was using a div with background image positioned right. Couldn't figure out how to do this with img but since divs are working for me I didn't know if this would matter...
AFAIK, browsers cache images the same whether they're in a DIV or an IMG. In any case, I think this one of those cases where specific performance is defined as an implementation detail internal to each rendering engine (and possibly the browsers built around them). As such, it's both out of our control as designers/developers and subject to change from browser to browser and version to version. In other words, I wouldn't spend too much time worrying about it.
The main performance difference is using background images allows you to use CSS sprites. Having one image contain a large number of images from your page means the user only has to make one request instead of one for each image.
Another difference is with responsive layouts. If you have an element that is only shown at certain screen widths (ie, not on mobile phones), it will still load the image if it is specified in the html (using display:none for instance), but most all browsers now will NOT load the image if is a background-image specified in unused media query-CSS rules. A lot of early responsive layouts got criticized because they still used the same bandwidth as the full size sites.
It is also useful with such designs because you can easily specify different images for different screen sizes. "Retina" displays on tablets and even laptops now won't look their best without 2x res graphics. So... even if you don't do such things now, it is probably a good practice to get into, because you might find yourself needing it soon!
I think by using background-image attribute in the div, the page layout gets loaded first and image present in the divs loaded later after the dom is loaded. so by using background-image the html layout is loaded faster on the web browser.
The only difference I can conceive of it this:
You can't scale images as backgrounds, although you can for img tags. This would open a scenario where background images loaded faster becuase it forces you to have the correct native size as opposed to downloading the entire image and scaling it. However, the converse could be true: given that you didn't care about image quality so much, you could deliver smaller imgs to your page and scale them up.
I'd stick with whatever rendered cleaner (and more consistently -- IE/FF/Chrome/Safari/etc).
Technical differences yes, most notably you can set the width/height of an IMG tag and it will stretch the image, which can be useful in some situations.
The main thing you've got to keep in mind though is the context of the image within the HTML document. If the image is content, say an image in a gallery, I'd use a IMG tag. If it is just part of the interface I might use a div instead.
I control an iframe being rendered on another domain. Is there a clear way of telling whether this iframe is being rendered above or below the fold on the parent page? Obviously, I can't access the parent DOM because of the same origin policy restriction.
For example, I tried measuring the speed of rendering on a canvas or VML tag, hoping it would be faster when the tag isn't on screen. This didn't work - there was no discernable speed difference. Ditto for DOM manipulation - there doesn't seem to be a way to differentiate between reflow/repaint operations below or above the fold.
What about flash? I don't have much experience, but could one check how quickly a browser renders flash operations? Or does flash have any 'onvisible' events outside of the DOM standard?
I don't think so.
The same origin policy restriction prevents that, although you can use url parameters, which can be set by the javascript embedding the ad, to the offset on the page.
According to the author of SoundManager2 Scott Schiller, there's a slight difference in the latency of the JS->Flash communication bridge depending on whether the flash movie is on screen or not. That is, it's slower when it is not on screen.
This really varies by-browser, as different browsers interact with the Flash plugin differently. The most precise explanation I could find is on an old connectedpixel post.
At the point of writing, Firefox didn't init a flash object until it was scrolled on page. IE, on the other hand, resized the Stage element when it scrolled into view. No versions of browser, Flash, or OS are given, so this may have changed since that test.
In short, I need to make a flash object and play with it, watching for various events.