I need an alternative to frames. My layout is as follows, a hovering menu bar and a web page below. The menu has a text box where i can enter the url which is loaded in the other frame. now any url i click on this frame should be loaded inside this frame only. The problem i'm facing is that a significant number of sites do not allow their sites to be loaded inside frames due to fear of clickjacking i suppose. So i'm desperately looking for an alternative to frames, by which i can still do what i stated above. Is that possible? Any and every help will be truely appreciated.
Thanks.
What you're describing is frames (either using <frameset> or <iframe>). There is no alternative, and both are treated more or less identically from a browser security standpoint.
Related
I am looking at disadvantages of lazy-loading images, and I must be hyper-thorough because we are considering implementing loading="lazy" on many/most images in the site. The reason for that is that I believe I have a strategy that should work.
We are using the browser-native loading="lazy" attribute, since we dropped support for IE recently. Wow, I know.
We are setting all images above the fold to eager, and all images below to lazy, across the entire site.
Then we are listening for the page load event and running a script that converts every image with loading="lazy" to loading="eager" (or auto). So images below the fold will get loaded too, probably in most cases by the time the user scrolls (at least using modern internet connection speeds). The page load event fires after all eager-loaded images have completed, but may/should fire before lazy-loaded images have started, so that is our opportunity to trigger loading below the fold.
One known disadvantage is that lazy-loaded images can cause a layout shift as the user scrolls, since the browser doesn't know the dimensions until the image starts loading. Another disadvantage is that users may be annoyed by images that are not loaded by the time they scroll to the image. This solution addresses both of those problems by converting remaining lazy-loading images to eager as soon as the prioritized images are loaded, to reduce the chance of the user encountering these issues.
There is also the possibility that there may be specific cases where pieces of JavaScript are waiting for an image to load in order to do something with it, and that can sometimes block rendering. Let's treat that as a side issue. I think it's unlikely we'll encounter that in this site, and we'll fix it where it occurs.
A side note, I have also devised a script that observes elements being populated or manipulated on the DOM by external scripts, and converts any newly-added img elements to loading="lazy" (if it occurs before page load), so I am able to guarantee lazy loading on all img elements on the page, and it DOES yield Lighthouse load performance gains of several points.
I am so far not finding many serious and/or likely problems from lazy-loading every or most images on a page, given that it is handled with the strategies that I have devised.
My question is what am I missing. Could this strategy have gaps?
What other considerations do I need to think about? Because I don't want my decisions to cause problems on the site I am working on.
When internet connection is very quick, things are also loading quickly and the user might not even see the status before the images are loaded. However, things are not always so rosy, there might be too many people using the internet and occupying all the bandwidth they can with watching videos, listening to music, chatting with friends.
Your problems start arising when
the users are using too many devices
there is an internet outage during the load of your page
an image is unavailable or slow to load (a very slow third-party UI, perhaps)
Usually, if your design works well and handles these cases in a user-friendly way, then users will notice there was a wait/outage, of course, but will probably not link that to your site. Yet, if your design looks ugly during these phases, then the users will remember that there was an outage/slowness of internet and how ugly your page was.
Since this is something every developer wants to avoid, it makes sense to treat the internet as something that usually works, but always has the potentiality of being down or slow.
As a result, if you know what pictures will appear in the viewport and what pictures will be shown only when the user scrolls, then you can eager-load the pictures the user will see first. Of course, it is not always easy to know what pictures will appear in the viewport, especially if your page looks very differently on different devices. Yet, you could divide your content into two main sections:
the section that is shown even during page load
the section which will be shown only when the page load is complete
you can totally hide the second section and then there would be no visual problems.
Another way to handle this is to know in advance (on server-side) the dimensions of the pictures, hide the picture tags while they are loading and show some placeholder (some "loading" gif, for example) in the place where the pictures will appear and have a load event for all images that are hidden this way which would make sure that the "loading" placeholder will disappear and the actual image appear when the image is loaded. This would ensure that your layout's visual structure is the exact same while it does not have all the images to show yet as when all the images were fully and successfully loaded.
What you may not know if you've never used browser-native lazy loading is that it does not necessarily improve initial load size/time on shorter pages, because it still initiates loading anything closer to the viewport than 3000 pixels, even before the window load event fires. This is what is considered too eager.
Info about this issue: https://calendar.perfplanet.com/2019/native-image-lazy-loading-in-chrome-is-way-too-eager
That can make it useless against Google's Lighthouse performance metrics for shorter pages.
So we are implementing the old-fashioned non-native lazy loading where we have complete control via JavaScript. Our images are served like:
<img data-src="some-image.src" />
<noscript>
<img src="some-image.src" />
</noscript>
...And using JavaScript strategy similar to what was described in the original question here, in addition to the common technique for swapping Image.dataset.src into the Image.src property, or we many use lazySizes.
But I don't get a few things about the functionality of browser-native lazy loading. Particularly, why the browser wouldn't prioritize lazy images above the fold over lazy images below the fold, and not load any lazy image below the fold or fire the load event until everything is loaded above the fold.
And I don't get why lazy loading can't be set with CSS. It would be great if we could apply the loading attribute to sections of a page by CSS selectors alone. Instead we're forced to handle it either with JavaScript or on the server. With CSS it would be as simple as loading: lazy;.
I'm going to look into if these ideas are proposed anywhere. I may also post the code we use in the end.
I am having trouble using Nightmare js to access elements within a specific frame on a webpage that gets its elements from a different html file. These are frames, not iframes, so plugins such as iframe-manager do not work.
I also cannot go to the src page of the frame as what I am attempting to do opens another window when clicked on the frames html.
On the original webpage clicking the button on the frame reveals information within another frame on the webpage. It would be easier (and potentially possible, unlike other options) to navigate within frames on the original webpage.
Any guidance would be appreciated thanks.
Decided to cut my losses and switch to puppeteerJS
Unlike Nightmare, it supports switching to normal frames via their contentFrame() method and $
No shade on Nightmare though, its a good API, just lost support for this frankly archaic web design choice
Here's my problem:
I have a Flash object on my page.
The user can change views within the Flash. [Not directly relevant but possibly useful: when this happens, the Flash creates a JavaScript event.]
I'd like to create separate Disqus comment threads for each Flash view, and according to Disqus's customer support, this needs a unique URL (not just hash fragment) for each comment thread.
It's not possible to write to the URL (as opposed to the hash fragment) without reloading the page (except in newer Webkit browsers).
However, I'd really like to avoid reloading the page, and having to reload the whole Flash object, each time the user changes views. But I'd really like to offer unique Disqus threads on each Flash view.
Can anyone think of a smart way I can get round this?
Could I put the Flash in an iFrame and not reload it when the rest of the page reloaded... or is that impossible?
You could put the cart before the horse and make an AJAX call to replace your main page content elements, so long as the <iframe> is a direct child of the <body> and the main content is a sibling (not a parent) of it.
That is impossible as the iFrame is part of the loaded page. The only, but very ugly, way to implement this is using a frameset..
Why not make two iframes? One as big as your body, the other one smaller, centered, and with a higher z-index.
Then just navigate the bigger iframe and leave the rest of the page alone.
Yes, it's ugly. But ugly questions ask for ugly answers :)
Is it possible to use CSS to work like frames?
What I mean is, when we use frames (left, right for example), clicking on left will refresh only the right section using the 'target' attribute.
Is it possible to create this effect with CSS?
Thanks.
Using frames is usually a bad idea
To answer your question, no, CSS cannot be used to work like frames. CSS is used to changing the style of HTML and as such, cannot actually change the content of a page. It can be used to hide content, but I don't think that is what you require.
However, I feel in this case you may be asking the wrong question. As frames are usually the wrong approach.
When starting out in web design, frames seem like a great idea. You can seperate your navigation from your content, your site will load quicker because the navigation is not loaded every time and the menu is always visible, even when the page is loading.
But, actually, frames are incredibly bad for your usability.
Your users cannot bookmark individual pages
Printing is broken
Standard features in a browser like open in new tab often breaks
Users cannot copy/paste the web address for a specific page for sending to a friend
Frames do have their uses (e.g. Google image search), but for standard navigation menus they are not recommended. Try creating a page in a dynamic server language such as PHP or ASP.NET.
These languages have ways of creating standard elements such as your navigation menu without the use of frames.
No, this has nothing to do with CSS. CSS is for styling elements only. What you are looking for is an IFRAME. And IFRAME can be given a name
<iframe name="my_iframe" src="xyz.htm"></ifram>
and then be targeted in a link.
I've got a design that relies on framed content using CSS. You can do this by using overflow:auto, however it won't do what you want, i.e. loading certain portions of a page. To do this you'd need to use some AJAX library such as jQuery to load the content area dynamically. This is quite dangerous though as your URL may not relate to the current content of the page.
You could probably do something with the overflow part of CSS.
If you set up a div with overflow:auto with a fixed width and height with alot of content you will get scrollbars. Potentially you could use anchors to get content to move to be viewed within the div.
This means that all your content is in one page and it is just moved around with the anchors. You could do a similar thing using a jquery tabs plugin too.
I have never tried this and it might need javascript to get it to work fully.
I have a large, hi-def JavaScript-intensive image banner for a site I'm designing. What is everyone's opinion of using iframes so that you incur the load time only once? Is there a CSS alternative to the iframe?
Feel free to preview the site.
It is very much a work in progress.
I should also have mentioned that I would like the banner rotation to keep moving. When the visitor clicks on a link, the banner rotation starts over. It would be nice if the "animation" kept rotating, regardless of the page the user visits.Blockquote
Well, in that case I would strongly recommend not doing that. The only real way of achieving that is to have the actual website content in the iframe, which means that you suddenly have lots of negative sides to the site: not being able to bookmark urls easily due to the address bar not changing; accessibility concerns; etc
I think you'll find that most people won't care that it reloads again. Once a visitor lands on your website, they'll marvel at the wonderful banner immediately, and then will continue to ignore it while they browse your site - until an image they haven't seen appears and distracts them away from your content.
Keep the rotation random enough, and with enough images, and people will stop to look at it from whatever page they're on.
I find the main challenge with iFrame headers is resizing. Since the font in your header is of static size, I don't see a problem with using an iFrame. Although I'm not sure if it's really intensive enough to be worth it.
Well, the browser appears to cache all seven banner images upon the first load, and runs them out from the cache (for each subsequent page) thereafter. I don't think you have a problem :D
Try it out with Firebug's Net monitoring tool in Firefox.
This may work without CSS also, but if you use CSS to load the background and your server is configured correctly, the image should already only be downloaded once.
Usually the browser will request a resource by asking for it only if it has not been modified since the last time it was downloaded. In this case, the only things sent back and forth are the HTTP headers, no content.
If you want to ensure the image is only downloaded once, add an .htacces or an apache2.conf rule to make the image expire a few days into the future so that users will only request it again if their cache is cleared or the content expiration date passes. An .htaccess file is probably too excessive to use in your case, though results may vary.
You could have it load the main page once, then asynchronously load the other elements when needed (ajax). If you did that, an iFrame would not be necessary. Here is an example of loading only the new material.
While using IFrames as a sort of master page/template for your pages might be a good thing, IFrames have a known negative impact to searchability/SEO.
It might also be unnecessary in the first place because once your images are loaded the first time (and with the large high-def images you have on your site, that would be slow no matter what you do) the images are cached by browsers and will not be reloaded until the user clears their cache or does a Ctrl+F5.