I have these webapplications build in old style HTML, including [framesets] to speed up the GUI of the administration.
Its not accessable by SEO etc. so thats not the issue here, it was all based on speed and minimizing reload at the time.
Now we would like to transform these applications and have begun to investigate HTML5 for the purpose.
Ofcause there is AJAX and db-storage etc. to speed up the interface with the new standards, but our question is really:
is IFRAMES and FRAMESETS going to be removed from the HTML5 standard or will it be "allowed" but "less appriciated" ?
Does anyone know whats going to happend?
The frameset and frame elements are obsolete in HTML5.
See http://www.w3.org/TR/html5/obsolete.html#non-conforming-features
The iframe element is valid.
Note that HTML5 still requires browsers to support frames and framesets as per Oded's link, but they are not valid for authors to use on web pages.
Yes, framesets will work, they are part of the current HTML5 spec.
So is iFrame.
As for your question on will they be deprecated or removed all together?
Frames and framesets should not be used in HTML5 as they have been obsoleted.
Related
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.
when validating a site using w3c validator it tells me the embed tag is not valid markup. So i take it out and it works on safari/chrome but not firefox(3.5.x) but validates fine. Is there something in the object tag i must add in order for firefox to display flash.
A List Apart has a great article on that topic: Flash Satay: Embedding Flash While Supporting Standards.
Read that to understand the general difficulties with embedding flash and to read about different approaches to embed it in valid HTML. And then go and use SWFobject to embed Flash as that is the best way to do it while having both standards support and browser compiliance.
In addition to that you may use the normal Flash Satay method to embed it for people without JavaScript.
embed has never been part of the HTML spec and object should be used. It's been so long since I've touched flash, I hesitate to say more than that which I know.
You should use swfobject. It's valid, although I think I've had the validator trip up on it before (the w3 validator has been known to trip up on stuff like this on occasion).
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.
In a web-based system I maintain at work that recently went live, it makes an Object element to embed a second web page within the main web page. (Effectively the main web page contains the menu and header, and the main application pages are in the object)
For example
<object id="contentarea" standby="loading data, please wait..."
title="loading data, please wait..." width="100%" height="53%"
type="text/html" data="MainPage.aspx"></object>
Older versions of this application use an IFRAME to do this though. I have found that by using the object tag the embedded web page behaves differently to when it was previously hosted in an IFRAME. In IE, for example, the tool tips don't seen to work (I will post a separate question about this!), and it looks like the embedded page cannot access the parent page in script, although it can if it was an IFRAME.
I am told the reason for favouring the object tag over the IFRAME is that the IFRAME is being deprecated and so cannot be relied on for future versions of browsers. Is this true though? Is it preferable to use the Object tag over the Iframe to embed web pages? Or is it likely that the IFRAME will be well-supported into the future (long after I am old and grey, and past the useful life of the application I maintain)?
The IFRAME element is part of the upcoming HTML5 standard. Also, HTML5 is developed by the major browser vendors out there (Mozilla, Opera, Safari, IE), that basically makes a guarantee that we will have an IFRAME element in the foreseeable future. Some of them have support for some HTML5 elements already, like AUDIO and VIDEO and some new JavaScript APIs.
It's also true that the OBJECT element is in the draft, but that's because IFRAME and OBJECT will have different purposes. IFRAMES are mainly designed for sandboxing web applications.
So, my advise is to use IFRAME instead of OBJECT.
If you are embedding a HTML page, here is one noticeable difference between iframe and object:
with iframe updating src will change the browser history (adding a new entry)
with object updating data will not change the browser history
Also it seems like drag&drop does not work if the page is embedded in the object tag, but works in the iframe tag. I noticed it personally using react-draggable, and I can see someone had the same issue (https://stackoverflow.com/questions/31807848/replacing-iframe-with-object-tag-drag-and-drop-not-working)
IFRAMEs are not part of the XHTML 1.0 Strict DTD. They are totally valid in in HTML 4 and XHTML 1.0 Transitional, I believe. For these reasons alone, IFRAME will continue to be supported for a long time.
A lot of bookmarklets and analytics code still use IFRAMEs.
Although the W3C specs may indicate that the IFRAME tag is being deprecated, (in XHTML at least anyway), browser developers do not necessarily follow exactly what those specs say (IE6 anyone?)
As use of IFRAMEs is so prevalent at the moment, and the W3C can't seem to decide if they are part of the future or not (HTML 4.01 vs XHTML), I am pretty sure they are the safer implementation to use for almost every browser.