Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > HTML > <frame> in html5

Reply
Thread Tools

<frame> in html5

 
 
fulio pen
Guest
Posts: n/a
 
      07-21-2011
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
 
Reply With Quote
 
 
 
 
Jukka K. Korpela
Guest
Posts: n/a
 
      07-21-2011
21.07.2011 14:32, fulio pen wrote:

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

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

--
Yucca, http://www.cs.tut.fi/~jkorpela/
 
Reply With Quote
 
 
 
 
cwdjrxyz
Guest
Posts: n/a
 
      07-22-2011
On Jul 21, 6:32*am, fulio pen <(E-Mail Removed)> wrote:
> 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.

 
Reply With Quote
 
dorayme
Guest
Posts: n/a
 
      07-22-2011
In article
<(E-Mail Removed)
m>,
cwdjrxyz <(E-Mail Removed)> wrote:

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

--
dorayme
 
Reply With Quote
 
Gus Richter
Guest
Posts: n/a
 
      07-22-2011
On 7/22/2011 1:59 AM, cwdjrxyz wrote:

> 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.
<http://www.whatwg.org/specs/web-apps/current-work/multipage/content-models.html#embedded-content-0>

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

--
Gus

 
Reply With Quote
 
Adrienne Boswell
Guest
Posts: n/a
 
      07-22-2011
Gazing into my crystal ball I observed Gus Richter
<(E-Mail Removed)> writing in news:j0brj4$vrr$(E-Mail Removed):

> 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...age/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.

--
Adrienne Boswell at Home
Arbpen Web Site Design Services
http://www.cavalcade-of-coding.info
Please respond to the group so others can share
 
Reply With Quote
 
Jukka K. Korpela
Guest
Posts: n/a
 
      07-22-2011
22.07.2011 20:59, Adrienne Boswell wrote:

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

--
Yucca, http://www.cs.tut.fi/~jkorpela/
 
Reply With Quote
 
Tim Streater
Guest
Posts: n/a
 
      07-22-2011
In article <Xns9F2A6FA89DF84arbpenyahoocom@88.198.244.100>,
Adrienne Boswell <(E-Mail Removed)> wrote:

> Gazing into my crystal ball I observed Gus Richter
> <(E-Mail Removed)> writing in news:j0brj4$vrr$(E-Mail Removed):
>
> > 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...age/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.


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.

--
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted" -- Bill of Rights 1689
 
Reply With Quote
 
cwdjrxyz
Guest
Posts: n/a
 
      07-23-2011
On Jul 22, 7:48*am, Gus Richter <(E-Mail Removed)> wrote:
> On 7/22/2011 1:59 AM, cwdjrxyz wrote:
>
> > 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....>
>
> IFRAME is supported in HTML5 - as is EMBED.
> <http://www.whatwg.org/specs/web-apps/current-work/multipage/content-m...>
>
> > 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.


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.
 
Reply With Quote
 
Jukka K. Korpela
Guest
Posts: n/a
 
      07-24-2011
24.07.2011 00:37, cwdjrxyz wrote:

> 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):
<http://www.whatwg.org/specs/web-apps/current-work/multipage/obsolete.html>

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

--
Yucca, http://www.cs.tut.fi/~jkorpela/
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Thought on HTML5 vs Flash Lawrence D'Oliveiro NZ Computing 3 03-21-2010 02:35 PM
HTML5 and HTTP pranay HTML 2 10-19-2009 10:16 AM
HTML5 Ganesh HTML 70 09-23-2009 05:19 PM
HTML5 vs. XHTML n0ctis HTML 4 08-18-2008 03:11 PM
html5 vs xhtml2 Robert Jones HTML 16 12-14-2007 11:34 PM



Advertisments