<frame> in html5

F

fulio pen

hello,

There is no <frame> and <frameset> on html5. but frame is still
useful on web sites sometimes. I wonder whether or not the same task
can be accomplished with css or javascript? Where to get the
information? thanks for your help.

fulio pen
 
J

Jukka K. Korpela

There is no <frame> and <frameset> on html5. but frame is still
useful on web sites sometimes.

So what? HTML5 doesn't magically make browser ignore <frame> and
I wonder whether or not the same task
can be accomplished with css or javascript?

It depends on what the task is. And <iframe> is in HTML5.
 
C

cwdjrxyz

hello,

There is no <frame> and <frameset> on html5.  but frame is still
useful on web sites sometimes.  I wonder whether or not the same task
can be accomplished with css or javascript?  Where to get the
information? thanks for your help.

Unless you are very young, you likely will be able to write a page
viewable, even on very recent computers and browsers, in a Doctype
that allows frames, for as long as you need to write web pages. Html5
is still just experimental, is changing, and not fully supported by
many of the most recent browsers; It is being pushed by some for
various reasons. However, if you insist on writing a valid page in a
Doctype that does not allow frames or iframes, that has long been
possible by correctly embedding one page in another page using proper
objects, not the embed psudo tag that never was offical in W3C html,
at least. The problem with this is mainly that many versions of IE
will not understand this using an ordinary object. But you can use an
Active X object, which IE understands, to embed one page in another
page and use Microsoft conditional comments to direct to the ActiveX
path for IE and the ordinary object path for other browsers. This
approach also will allow including other things such as Applets that
are not included in some more recent Doctypes of html and xhtml. The
embedded page can be in another Doctype than for the main page.
Moreover it is possible to extend what certain Doctypes include, but
this is a rather advanced subject that seems to be little used on
business web pages, for example. Moreover, for html, even many of the
most recent browsers are loose as a goose, and will view a page that
is full of errors for that Doctype. Xhtml is considerably more strict,
especially in respect to XML errors, but many browsers still will let
some other errors through. Of course it is possible to write an xhtml5
page and serve it correctly as application/xhtml+xml. I have done so
and been able to embed other pages, even with Doctype down to html2,
without introducing html5 or xhtml XML errors, and I have posted an
example or two here in the past. Even I do not use this method on most
of my pages, and by the time html5 becomes official and is used for
writing most new pages, I suspect I no longer will be around.
 
D

dorayme

<[email protected]
m>,
cwdjrxyz said:
Even I do not use this method on most
of my pages, and by the time html5 becomes official and is used for
writing most new pages, I suspect I no longer will be around.

Don't worry, we will all be there in that Big Usenet in the Sky
and be able to carry on, the door to hell will be at hand and all
subscribers will need to be very careful to avoid being dragged
or pushed through it.
 
G

Gus Richter

Html5
is still just experimental,

It is accepted as the next; HTML5 is for today, whereas HTML4.01 was
yesterday.
is changing,

HTML4.01 also changed as it went along.
and not fully supported by many of the most recent browsers;

So it was for HTML4.01 and CSS2.1 as well.
However, if you insist on writing a valid page in a
Doctype that does not allow frames or iframes,

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.html#non-conforming-features>

IFRAME is supported in HTML5 - as is EMBED.
that has long been
possible by correctly embedding one page in another page using proper
objects, not the embed psudo tag that never was offical in W3C html,
at least.

The EMBED element is official in HTML5 - is supported - as is IFRAME.
 
A

Adrienne Boswell

Gazing into my crystal ball I observed Gus Richter
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.h
tml#non-conforming-features>

That's really a pity. There is one thing that is good about frames, the
ability to move their borders. In an intranet application I use a lot, I
have a form on the left side, and on the other, I have another frame,
with the query on top, and the results on the bottom. Then I can copy
and paste the results from right side to the form on the left side. If I
can't see all the results on the right side, I can grab the left side
scroll bar and expand or contract it to suit. I don't think that can be
done any other way. Again, it's for an intranet, and I'm the only one
using it.
 
J

Jukka K. Korpela

FRAME and FRAMESET are non-conforming and are entirely obsolete in
HTML5 and must not be used by authors.
[...]
That's really a pity.

Whatever HTML5 might say, we can always ask "You and which army?" That
is, they cannot really stop you from doing what you do. Only remotely
and indirectly might they affect in that direction, by making browsers
not support the "obsolete" stuff, but in fact, HTML5 requires that
browsers keep supporting it. Schizophrenic? No, schizophreny is
something completely different from being self-contradictory, having
split personality, or just looking foolish.
There is one thing that is good about frames, the
ability to move their borders. In an intranet application I use a lot, I
have a form on the left side, and on the other, I have another frame,
with the query on top, and the results on the bottom.

You can most probably use <iframe> for that and be happy even if
extraterrestrial beings conquer the Earth and force everyone to use HTML5.
 
T

Tim Streater

Adrienne Boswell said:
Gazing into my crystal ball I observed Gus Richter


That's really a pity. There is one thing that is good about frames, the
ability to move their borders. In an intranet application I use a lot, I
have a form on the left side, and on the other, I have another frame,
with the query on top, and the results on the bottom. Then I can copy
and paste the results from right side to the form on the left side. If I
can't see all the results on the right side, I can grab the left side
scroll bar and expand or contract it to suit. I don't think that can be
done any other way. Again, it's for an intranet, and I'm the only one
using it.

Well, it can, but you have to create a grabbar, manage its onmousedown
events, and resize the <divs> that the grabbar separates. At least,
that's what I do. There may be better, more reliable, or simpler methods
for all I know.
 
C

cwdjrxyz

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.
 
J

Jukka K. Korpela

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.

What are you talking about? The HTML5 drafts _require_ continued support
to the <frame> element; even have _additional_ requirements (not present
in HTML 4.01):
Most recent browers seem to do
little checking to see if all elements belong to the Doctype specified

Understatement of the year? Can you present a single browser that even
reads the document type definition?

It seems that the rest of your posting was equally confused (or
trolling?), so it can be ignored.
 
C

cwdjrxyz

What are you talking about? The HTML5 drafts _require_ continued support
to the <frame> element; even have _additional_ requirements (not present
in HTML 4.01):
<http://www.whatwg.org/specs/web-apps/current-work/multipage/obsolete....>

I am wondering what you are talking about. The link you give just
above says:

"14.2 Non-conforming features

Elements in the following list are entirely obsolete, and must not be
used by authors:

applet Use embed or object instead.

acronym Use abbr instead.

bgsound Use audio instead.

dir Use ul instead.

frame
frameset
noframes
Either use iframe and CSS instead, or use server-side includes to
generate complete pages with the various invariant parts merged in."


The author of a recent book also says that html5 does not include
support for frames(although iframes are supported) but speculates that
developers will continue to use them anyway.
Understatement of the year? Can you present a single browser that even
reads the document type definition?

There have been a lot of browsers used, and I have not used all of
them. Thus I wanted to stay on the safe side by not saying "most
recent browsers" rather than "all recent browsers" or "all browsers".
It seems that the rest of your posting was equally confused (or
trolling?), so it can be ignored.

You are quite free to ignore it. You won't hurt my feelings. Others
can also do the same. I have no time for an extended Usenet exchange.
 
J

Jukka K. Korpela

I am wondering what you are talking about.

I am writing about HTML5, which I know pretty well, having read a few
books on it and written one.
The link you give just above says:

Nothing that you quote affects what I wrote. You are quoting
requirements on authors. I wrote about requirements on browsers (user
agents). Having these very different is one of the key design principles
of HTML5.
The author of a recent book also says that html5 does not include
support for frames(although iframes are supported)

That's a category error. Specifications do not "include" support. They
may _require_ conforming implementations to support something. And
that's what HTML5 does regarding frames.
but speculates that
developers will continue to use them anyway.

Does one really need to _speculate_ that browsers will keep the code
that implements frames, when it is known that frames are used (not as
much as earlier, but still), that HTML5 requires continued support, and
it would be more work to remove the code than to keep it?
There have been a lot of browsers used, and I have not used all of
them. Thus I wanted to stay on the safe side by not saying "most
recent browsers" rather than "all recent browsers" or "all browsers".

Would you also say that most recent browsers don't do grocery shopping
for you?

And in fact you wrote "little checking", not "no checking", so you wrote
as if you hade some actual observations on such behavior.
You are quite free to ignore it. You won't hurt my feelings. Others
can also do the same. I have no time for an extended Usenet exchange.

Yet you had time to wrote some overlong paragraphs that started with
nonsense.
 
T

The Reverse Psycology Major Phd

dorayme said:

.... why? you gonna dye?

b
Don't worry, we will all be there in that Big Usenet in the Sky
and be able to carry on, the door to hell will be at hand and all
subscribers will need to be very careful to avoid being dragged
or pushed through it.


--
b

this is a magnum. It's one of the most
powerful guns known to man. I know what
you're thinking, 'did he shot 5 or 6
bullets?'. Well, in all the confusion I
kinda lost track myself. So ya gotta ask
yourself one question, 'do you feel lucky?
Huh, do ya, do ya punk? Go for it MAKE MY DAY!
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top