It is accepted as the next; HTML5 is for today, whereas HTML4.01 was
yesterday.
HTML4.01 also changed as it went along.
So it was for HTML4.01 and CSS2.1 as well.
FRAME and FRAMESET are non-conforming and are entirely obsolete in HTML5
and must not be used by authors.
<
http://www.whatwg.org/specs/web-apps/current-work/multipage/obsolete....>
IFRAME is supported in HTML5 - as is EMBED.
The EMBED element is official in HTML5 - is supported - as is IFRAME.
First, most browsers are loose as a goose, and it will not be a
surprise if some will show a frame properly on a html5 page. Of course
the W3c html5 checker will show an error. This is certainly the case
for some less recent versions of html. Most recent browers seem to do
little checking to see if all elements belong to the Doctype specified
and seem to just add more elements as new versions of html come along.
For me, an ideal browser would check to see if all elements belong to
the W3C Doctype specified and present no view of the page if there are
any errors. Detection of errors for a Doctype is easy and fast using
the W3C validator, and the code for it can be downloaded from the W3C.
Thus it should be easy for browsers to add this feature. Since a large
number of web pages are full of errors, and even many huge companies
write code that is a html soup of many versions of html, browser
providers are unlikely to do this. However it would be possible for a
transitional period to give a screen that reports the page has errors,
and that the owner of the page should be informed of this. Then you
would be asked if you would like to see if the browser can show the
page anyway, and if you so select, the page will be presented as it
now is by loose browsers. Perhaps there would then be enough
complaints to web page owners to get them to put pressure on their
code writers to clean up their code. Unfortunately, as the slow
transition to xhtml indicates, one still finds few xhtml pages that
validate at the W3C, and, of those that do, most are served as text/
html rather than the required application/xhtml+xml which means the
page is only served as html, not xhtml. Thus the transitional period
might well extend for a long time if the history of proper xhtml usage
for the last 10 years is any indication.
A little more information about the embed element might be useful.
First embed has never been a part of W3C html or xhtml from html2 up
to html5. The W3c validator thus rightly gives error messages if you
use it. Embed is a hangover from the browser war era, first used by
Netscape. It is easily avoided, at least for html 4 and more recent,
by using the proper object method for embedding. It is not necessary
to use embed for any media I have used including flv/swf, wmv. wma,
mov, rm, and many more. You also do not need it to embed a web page in
another web page.
Embedded video or audio in html5 only can use the embed element, and
likely presents media using installed media players just as it can by
loose browsers for previous versions of html/xhtml without throwing an
error. However you can better use the object element to do this, just
as you do in correct code up to html5. But html5 has both a new video
and audio element. These allow the browser to use a "house" player,
not a player added to the OS, to be used for video and audio. If there
were only one official house player, this would help make it easy to
use only one media format on all browsers without regard to what
players might or might not be installed on the OS. Unfortunately, each
browser maker is free to choose a "house" player. A modern mp4 video
format is required for IE9. Some other browsers will accept this, but
others require an ogg format. Safari will use a mp4 format, but if the
video is long it will have to download completely and not stream(and
that can require a long time for a long video). To overcome the Safari
streaming problem, you can hint the mp4 video file to output it as a
mov file that will stream. This can be done on a pay version of a QT
player. Thus to cover most current browsers that can handle html5
video and audio elements, I find it necessary to include the same
video in mp4, ogg, and mov versions. To complicate matters more some
html5 capable browsers do not yet support important video attributes
that may be desired such as loop, autoplay, controls, and poster.
Using html5 with video and audio elements with a "house" player likely
is one of the main factors driving the extreme push to html5 by some.
This gives the browser companies control of media. I need only mention
the Apple/flash debate as the most extreme example.
