For school I have to make a website that must use frames. I complained to my teacher without success.
I want to use HTML5 but seems frames are deprecated. Am I required to use XHTML, HTML 4 or is there some work-around that makes my pages valid HTML5 with use of frames?
I know your class is over, but in professional coding, let this be a lesson:
"Deprecated" means "avoid use; it's going to be removed in the future"
Deprecated things still work - just don't expect support or future-proofing
If the requirement requires it, and you can't negotiate it away, just use the deprecated construct.
If you're really concerned, develop the alternative implementation on the side and keep it ready for the inevitable failure
Charge for the extra work now. By requesting a deprecated feature, they are asking you to double the work. You're going to see it again anyway, so might as well front-load it.
When the failure happens, let the interested party know that this was what you feared; that you prepared for it, but it'll take some time
Deploy your solution as quickly as you can (there will be bugs)
Gain rep for preventing excessive downtime.
Now, there are plenty of example of me answering questions with essays on why following validation rules are important. I've also said that sometimes you just have to be a rebel and break the rules, and document the reasons.
You can see in this example that framesets do work in HTML5 still. I had to download the code and add an HTML5 doctype at the top, however. But the frameset element was still recognized, and the desired result was achieved.
Therefore, knowing that using framesets is completely absurd, and knowing that you have to use this as dictated by your professor/teacher, you could just deal with the single validation error in the W3C validator and use both the HTML5 video element as well as the deprecated frameset element.
<!DOCTYPE html>
<html>
<head>
</head>
<!-- frameset is deprecated in html5, but it still works. -->
<frameset framespacing="0" rows="150,*" frameborder="0" noresize>
<frame name="top" src="http://www.npscripts.com/framer/demo-top.html" target="top">
<frame name="main" src="http://www.google.com" target="main">
</frameset>
</html>
Keep in mind that if it's a project for school, it's most likely not going to be something that will be around in a year or two once the browser vendors remove frameset support for HTML5 completely. Just know that you are right and just do what your teacher/professor asks just to get the grade :)
UPDATE:
The toplevel parent doc uses XHTML and the frame uses HTML5. The validator did not complain about the frameset being illegal, and it didn't complain about the video element.
index.php:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">
<html>
<head>
</head>
<frameset framespacing="0" rows="150,*" frameborder="0" noresize>
<frame name="top" src="http://www.npscripts.com/framer/demo-top.html" target="top">
<frame name="main" src="video.html" target="main">
</frameset>
</html>
video.html:
<!doctype html>
<html>
<head>
</head>
<body>
<div id="player-container">
<div class="arrow"></div>
<div class="player">
<video id="vid1" width="480" height="267"
poster="http://cdn.kaltura.org/apis/html5lib/kplayer-examples/media/bbb480.jpg"
durationHint="33" controls>
<source src="http://cdn.kaltura.org/apis/html5lib/kplayer-examples/media/bbb_trailer_iphone.m4v" />
<source src="http://cdn.kaltura.org/apis/html5lib/kplayer-examples/media/bbb400p.ogv" />
</video>
</div>
</body>
</html>
Maybe some AJAX page content injection could be used as an alternative, though I still can't get around why your teacher would refuse to rid the website of frames.
Additionally, is there any specific reason you personally want to us HTML5?
But if not, I believe <iframe>s are still around.
You'll have to resort to XHTML or HTML 4.01 for this. Although iframe is still there in HTML5, its use is not recommended for embedding content meant for the user.
And be sure to tell your teacher that frames haven't been state-of-the-art since the late nineties. They have no place in any kind of education at all, except possibly for historical reasons.
Frames were not deprecated in HTML5, but were deprecated in XHTML 1.1 Strict and 2.0, but remained in XHTML Transitional and returned in HTML5. Also here is an interesting article on using CSS to mimic frames without frames. I just tested it in IE 8, FF 3, Opera 11, Safari 5, Chrome 8. I love frames, but they do have their problems, particularly with search engines, bookmarks and printing and with CSS you can create print or display only content. I'm hoping to upgrade Alex's XHTML/CSS frame without frames solution to HTML5/CSS3.
Related
If you use deprecated attributes or tags <center>, <font color="red">, or <td valign="top"> etc. in XHTML 1.0 Strict (no depr. attributes), modern browsers (I will use Chrome as an example) still take notice of and use them.
If you use HTML5 <video> on an XHTML 1.0 Strict DOCTYPE Chrome will still recognize it - it's not as if they'd program it to not. I tested the worst deprecated, capitalized, and unquoted attribute code I could write, along with HTML5 audio, with the XHTML 1.0 Strict DOCTYPE in Chrome and it rendered flawlessly.
Here's the code I tested, working flawlessly in Chrome (red bg, centered table, audio playing):
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>Do browsers care about the DOCTYPE?</title>
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" >
</head>
<body bgcolor=#ff0000>
<CENTER>
<table cellpadding="0" cellspacing=0>
<tr><td valign=top>test</td></tr>
</table>
</CENTER>
and some HTML5 audio..
<audio autoplay>
<source src="http://www.duncannz.com/resources/sound/alarm.mp3" type="audio/mp3">fallback text</audio>
</body>
</html>
So my question: Do modern browsers (translation: browsers other than IE) pay any attention at all, or do anything differently, because of the DOCTYPE? Do they even bother to read and interpret it?
Browsers do care about the DOCTYPE - otherwise there wouldn't be any point in having it!
You are right in saying that many browsers interpret old/deprecated commands in the correct way, but this is largely a matter of backwards compatibility. There is such a huge amount of content on the web that it is next to impossible to keep everything up-to-date and standards-complient. The web browsers continue to support these outdated pages because if they didn't, much of the content on the web would look slightly off. Most users don't know the difference between HTML4 and 5, so the blame could fall on the browser, which could be devastating - especially if a page looks bad on Firefox and nice on IE!
The DOCTYPE is mainly used in validation and to determine whether a browser runs in this "quirks mode" (where many of these older rules still work) or "standards mode" . Many professional web designers use the W3C validation tools to make sure their web pages are valid HTML, and the tools provided by their website look at the DOCTYPE to choose the correct set of rules with which to validate. Furthermore, XHTML strict does not allow empty tags or other blatant syntactic errors.
Hope this helps!
Try this in Chrome:
<!DOCTYPE html>
<title>Test case</title>
<p hidden>My text
<table><tr><td>Hello World</table>
against this
<title>Test case</title>
<p hidden>My text
<table><tr><td>Hello World</table>
Only in the former case will the text "Hello World" be visible.
In most Modern Browsers, you're not going to notice much difference (depending on the page) when using different Doctypes. The biggest difference you'll notice is not in your markup, but in your use of CSS, and the layout/positioning of elements. The Doctype is used when validating your pages, and in determining the mode, the browser renders the page in. So, depending on the Doctype you use, it will determine if the page is rendered in Standards mode, Quirks mode, etc. In IE, and older browsers, you'll notice much more of a difference.
For a more in-depth information on the subject, check out this link: http://hsivonen.iki.fi/doctype/
Yes, they do. It means the difference between Quirks or Standard mode, and can affect how IE handles box containers.
Have a look here:
http://www.quirksmode.org/css/quirksmode.html
And also here:
http://www.webmasterworld.com/forum21/7975.htm They discuss this topic in detail.
maybe the paragraph called "How DOCTYPES Affect Rendering" could help you?
http://www.upsdell.com/BrowserNews/res_doctype.htm
At the current date it is still possible to use DTD entities as variables in chrome/firefox/opera/ie in .xml and .xhtml and .svg and other xml-based files(breaks in .html files as I imagine it uses an html rendered instead of an xml renderer) without having to resort to javascript or php/other server-side preprocessor magic:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" [
<!ENTITY theword "bird">
<!ENTITY thexmlns "http://www.w3.org/1999/xhtml">
]>
<html xmlns="&thexmlns;">
<head>
<title>The word is &theword;</title>
</head>
<body>
<p>This document uses the word &theword; multiple times.</p>
<p>This document's word can be changed from &theword; by altering the entity.</p>
</body>
</html>
This seems like a useful test to see if doctypes still work(save the example above as example.xml or example.xhtml and see if it works).
So far I only found a realistic use for it in android projects xml files to use
entities inside attributes to prevent lines from having too much text one one line,
or from having the repeated long text in multiple attributes that could have a short entity encode them instead.
Am I missing something?? This code, which I think is fine, comes up with an empty page. If you change one of the URLs to facebook.com, that won't load either. Are Google, Amazon and Facebook all blocking their site from showing if it's in a frameset? (Why wouldn't they just bust out?) Or is my HTML flawed?
<html>
<head>
<title>Test</title>
</head>
<FRAMESET ROWS="71, *" FRAMEBORDER=NO FRAMESPACING=0 BORDER=0>
<FRAME SRC="http://google.com">
<FRAME SRC="http://www.amazon.com/dp/0307951529?tag=fw-book-20" name='btm'>
</FRAMESET>
</html>
They're blocking frames using x-frame-options. If you view their response headers you'll see this:
x-frame-options SAMEORIGIN
This works regardless if JavaScript is enabled. However, it does require a relatively modern browser as listed on the MDN page I linked to.
My suggestion, find a more elegant way to do what you're trying to accomplish without using frames. Frames are evil and have created some of the most evil webApps out there. Please refrain, and let us help you find a better way to solve what ever problem it is you're trying to solve by using frames.
I even support properly used iFrames, but not famesets...
From Richard Kiessig's ultra fast asp.net book,
Head section can't contain any tags that cause the browser to draw content on the screen, users will see noting until it has downloaded all resources in the section.
-- What he is referring from this statement?
<HEAD runat ="server">
<title>WebForm1</title>
<h1> Hi </h1>
</HEAD>
Browser is rending 'hi'.
h1 inside head is invalid html. It is not allowed. But if producers of webbrowsers would reject every invalid html-document, about 90% (or even more) websites would not displayed to the user.
So one browser producer built a browser who was able to render invalid sites too, and all the user started to use this browser. So the producers of correct webbrowsers had no other chance. They also built browsers that can render invalid html. And because of this, all webbrowsers that are in use are browsers that are able to render invalid html.
BUT:
There is no standard defined on how to render invalid html. So each producer has his own ideas about how to display an invalid document, and so, when you write invalid html, you could have luck, and the document looks fine in the one browser you used for developing and testing. But the users of your website do not only use YOUR browser. They use ALL available browsers, and if your html-code is invalid, the chances are really high, that many users use a browser you dont know, and this browser don't display what you want, but some garbage.
Conclusio:
Producers of really good Web-Browsers MUST produce browsers that can render any garbage.
Producers of really good html-documents MUST procuce valid html.
The statement “Head section can't contain any tags that cause the browser to draw content on the screen, users will see noting until it has downloaded all resources in the section.” is best ignored; it just causes confusion and lacks a point. Trying to correct the mistakes in it would take long and would not really lead to anything.
Regarding the treatment of the invalid markup
<HEAD runat ="server">
<title>WebForm1</title>
<h1> Hi </h1>
</HEAD>
the simple answer is that browsers have parsers that imply a closing </head> tag and an opening <body> tag, when they encounter <h1> while parsing a head element. This is in full conformance with HTML specifications.
In the fragment, the only invalid thing, apart from the runat ="server" attribute, which is not expected to be delivered to clients at all (it’s ASP not HTML), is the spurious end tag </HEAD>. The head element was already closed, it cannot be closed again.
Yeah, sure the <head></head> can contain all tags that by default carry the display:none; property. Those are elements like <meta> and <title>. But <h1> has to render on the screen, it is display:inline;. Most elements aren't display:none; though, and should be placed in the <body></body> section.
At that point it won't validate with w3c therefore you're breaking web standards. However, it should render just fine in all modern browsers. Most people would say you want to retain organization and quality when building web pages, part of that is making sure your code is the correct syntax.
ETA: Standard HTML5 markup...
<!DOCTYPE html>
<html>
<head>
<title>My Title</title>
<!--[if lt IE 9]>
<script src="//html5shiv.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->
</head>
<body>
<header>
</header>
<section>
</section>
<footer>
</footer>
</body>
</html>
In that lt IE9 comment, it adds HTML5 support to IE 8 and below which do not support it. ;-)
what is the internal mechanism of <bgsound> tag html?
I've looked into it:
For MIDI and WAV files, Internet Explorer loads winmm.dll and plays it through that. Specifically, it uses PlaySound. For MP3 files, it uses the ActiveMovie Control, runs it through the ActiveMovie Control Type Library (Quartz.dll, for info on its functions see here) to parse it, and plays that using DirectSound (DSOUND.DLL). Well, there you go.
The internal mechanism is entirely up to the browser vendor (should they choose to implement this non-standard element).
It is a black box, and shouldn't matter to anybody not developing the browser itself.
Not sure what you mean by internal mechanism, because bgsound is IE only and they keep there sources closed, but other vendors use embed instead of bgsound. What are you trying to do?
<html>
<head>
<title>Music</title>
<bgsound src="sound.mid" loop="infinite"> <!-- MS. Instead of infinite you can use a number. -->
</head>
<body>
<embed src="sound.mid" autostart="true" loop="true" hidden="true" height="0" width="0"> <!-- Others. -->
</body>
</html>
Looking at options for embedding the 3D Secure page inside my own order form, I came across the following:
"Some commerce sites will devote the full browser page to the authentication rather than using a frame (not necessarily an iFrame, which is a less secure object anyway)."
from http://en.wikipedia.org/wiki/3-D_Secure
Can someone give me the lowdown as to why iframes are less secure, and cause problems, as opposed to normal frames? And what are the basic differences?
The way I see it, iframe is the way to go.
The difference is an iframe is able to "float" within content in a page, that is you can create an html page and position an iframe within it. This allows you to have a page and place another document directly in it. A frameset allows you to split the screen into different pages (horizontally and vertically) and display different documents in each part.
Read IFrames security summary.
IFrame is just an "internal frame". The reason why it can be considered less secure (than not using any kind of frame at all) is because you can include content that does not originate from your domain.
All this means is that you should trust whatever you include in an iFrame or a regular frame.
Frames and IFrames are equally secure (and insecure if you include content from an untrusted source).
iframes are used a lot to include complete pages. When those pages are hosted on another domain you get problems with cross side scripting and stuff. There are ways to fix this.
Frames were used to divide your page into multiple parts (for example, a navigation menu on the left). Using them is no longer recommended.
Basically the difference between <frame> tag and <iframe> tag is :
When we use <frame> tag then the content of a web page constitutes of frames which is created by using <frame> and <frameset> tags only (and <body> tag is not used) as :
<html>
<head>
<title>HTML Frames</title>
</head>
<frameset rows="20%,70%,10%">
<frame name="top" src="/html/top.html" />
<frame name="main" src="/html/main.html" />
<frame name="bottom" src="/html/bottom.html" />
</frameset>
</html>
And when we use <iframe> then the content of web page don't contain frames and content of web page is created by using <body> tag (and <frame> and <frameset> tags are not used) as:
<html>
<head>
<title>HTML Iframes</title>
</head>
<body>
<p>See the video</p>
<iframe width="854" height="480" src="https://www.youtube.com/embed/2eabXBvw4oI"
frameborder="0" allowfullscreen>
</iframe>
</body>
</html>
So <iframe> just brings some other source's document to a web page. The <iframe> are used to specify inline frames or floating frames. The World Wide Web Consortium (W3C) included the <iframe> feature in HTML 4.01.
<frameset> tags were used to create frames with the tag <frame> whereas <iframe> fulfills functions of both <frame> and <frameset> tags. Unlike <frame> tags, <iframe> tags can also be placed inside the <body> tags.
Placement of <iframe> is easy, a coder can easily put the <iframe> tag among the other webpage tags, and also add several <iframe> tags if he/she wants. On the other hand, placing <frame> tags in <frameset> is bit complicated.
Note : <frame> tag and <frameset> tag are deprecated in HTML5
So now as use of <frame> and <frameset> tag is deprecated so web developers use <body> tag for creating content of a webpage and for embedding some other source's document in the web page <iframe> tags are used. But even <frame> tags were also used to embed other source's document in a webpage and even <iframe> tags are also used to create frames.
The only reasons I can think of are actually in the wiki article you referenced to mention a couple...
"The "Verified by Visa" system has drawn some criticism, since it is
hard for users to differentiate between the legitimate Verified by
Visa pop-up window or inline frame, and a fraudulent phishing site."
"as of 2008, most web browsers do not provide a simple way to check
the security certificate for the contents of an iframe"
If you read the Criticism section in the article it details all the potential security flaws.
Otherwise the only difference is the fact that an IFrame is an inline frame and a Frame is part of a Frameset. Which means more layout problems than anything else!
Inline frame is just one "box" and you can place it anywhere on your site.
Frames are a bunch of 'boxes' put together to make one site with many pages.
While the security is the same, it may be easier for fraudulent applications to dupe users using an iframe since they have more flexibility regarding where the frame is placed.