I'm curious to find out how a browser loads and renders a frameset. I know this may be different among different browsers. I am personally most concerned with how IE does it.
From my understanding, the browser will make one request for the page that contains the frameset. Upon rendering that page, the browser will then make a request for each individual frame's content within that frameset.
Is this correct and if so, are the requests for individual frames within the frameset done asynchronously or are the requests performed linear?
This is assuming that we are purely using HTML.
From my understanding, the browser will make one request for the page that contains the frameset. Upon rendering that page, the browser will then make a request for each individual frame's content within that frameset.
Yes, that's basically correct.
are the requests for individual frames within the frameset done asynchronously or are the requests performed linear?
From memory (and I haven't worked with Framesets in a loooong time), it is asynchronous.
Framesets are basically an obsolete technology, and haven't really been in common use for a long time now, but I'd be very surprised if it works any differently to iframes, which are asynch.
You specifically asked about IE. For current IE versions, there really shouldn't be any major differences between IE and the other browsers.
But older IE versions (IE8 and earlier) had quite tight restrictions on the number of files they were capable of loading asynchronously. If I recally correctly, the limit was just two files at a time, or something of that order.
Given that, if you've got more than a couple of files in your frameset and you load it in an old IE version, then the answer is yes, it probably will load at least some of them linearly.
But the best advice really is to avoid framesets entirely. They are deprecated for good reasons.
Related
I'm creating a Chrome Web Extension, which uses the chrome.webRequest API to intercept and alter HTTPS requests.
Within their documentation, Google talk about different request types. One of these types is main_frame, which is a request for "a document that is loaded for a top-level frame".
To me this implies that Chrome treats everything as an iframe, but that doesn't seem right. What is the meaning of the "top-level frame" terminology?
The frame terminology is used to describe part of the Chrome browser's rendering process. Please see this article on Rendering Architecture for more information.
From the article, a frame contains:
DOM state,
CSS,
Canvases,
External resources, such as images, video, fonts, and SVG.
Therefore, a frame is a complete HTML document plus the document's URL.
It's actually correct to consider everything as an iframe, because that's how the Chrome browser views web pages when it's rendering them. The "top-level-frame" is the uppermost frame in a "frame hierarchy", and contains the information retrieved from the initial URL request. Any other frames, for example, iframes, are child frames of this "top-level-frame".
As an interesting aside, for performance purposes, frames from different websites are dealt with by different rendering processes. This is why your main web page (top-level-frame) can load quickly, whilst your iframe (child-frame) takes a few seconds.
I have a simple frameset which works fine and when frames arnt supported it shows a link to the frame free version. What I would like is for the page to redirect to the frame free version if the browser doesn't support frames. I have googled without success and I am sure it can be done but as yet I haven't worked out. Ideas please?
You can use 'Browser Sniffing' and blacklist those without support however this is generally a bad idea.
Also you should avoid using frames are they have been dropped from HTML5 and are an accessibility nightmare
Use either CSS positioning or iframes to achieve similar results
I have read that frames are not supported in HTML5 but I still want to use them, on occasion.
:-) before you launch into a lecture as to the "evils" of frames, let me say I've resolved the biggest ones - orphaned frames and useless bookmarks. My pages which use frames check to see if they are in the correct frameset, if not, they load the correct frameset. When you bookmark one of my pages which contain frames, the bookmark takes you to the "page" you bookmarked, not just the frameset with default frame sources.
As to HTML5 not supporting frames, is using them a matter of specifying the correct DOCTYPE so that the page is not considered HTML5?
I admit I know very little about DOCTYPE statements and would appreciate any knowledge you can share with me.
Bob
Browsers either support frames or they don't. "Out of the box", all the modern graphical browsers do, though it may be possible for users to disable them. The doctype makes no difference to this.
In HTML5, frames are obsolete. This means that authors, if they want their pages to be HTML5 compliant, must not use frames. It does not mean the user agents (e.g. browsers) should not support them.¹ Indeed, the HTML5 spec devotes a section here and another one here to describing how user agents should process frames and framesets.
¹ So to be absolutely clear, the statement "frames are not supported in HTML5" is simply inaccurate.
On my website, I intend to stream background audio using the HTML5 <audio> tag. However, even after cutting down on the track length, my two files (MP3 and OGG Vorbis, for different browsers) end up at just short of 5MB a piece.
Due to this, it would be nice to ensure loading time and bandwidth is conserved by caching the files. What I would like to know, but can't seem to find, is if it's possible to force the files to cache, or if browsers would normally cache the files at all.
Thanks for your input!
You can not force caching. Browser treats these files as standard resources, so make sure that your server is properly configured to make caching as likely as possible. (Returns valid ETag, Expires and Cache-Control, no Pragma:none, 304 Not modified responses, etc..). HTML5 local storage can be used (but not worth the effort) to cache small items like pictures.
Mobile browsers have such a small cache, that even this doesn't help and they will flush the cache pretty soon.
Fast forward 7 years, and you can now easily do this with a Service Worker. You could even get crafty and cache/combine various Range requests if you wanted.
https://developers.google.com/web/ilt/pwa/caching-files-with-service-worker
Is it possible to listen to any kind of internet radio with HTML5 directly? I mean is it posible to play live mp3 streams in HTML5 complaint browsers?
Yes, it is.
Take a look at the former specification of html5:
http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#attr-media-src
There is a huge load of specialities about streaming in html5.
And furthermore, take a look at this:
http://web.psung.name/zeya/ - a whole html5 media server.
EDIT
Actually it's like impossible to stream live media.
It's not that it'll stay impossible, but actually it isn't implemented at all - well none of the today's HTML5 browsers are going to support this in the next month's, because the real "live-stream", as known from flash (or equal) hasn't really been specified by the w3-committee - yet.
2. EDIT
As previous experiments showed, it may be possible to use streams without explicitly implement something specific for them. The "non"-stream way works on both streams and static files.