valid html for framesets

Arie Mijnlieff

Hi !

I have an html file (http://www.kpc.nl/home.html) which i send to the
w3 validator as well as to a an online HTML tidy script.

The w3 validator (validator.w3.org) claims the frameset tag doesnt
have a border tag whereas the html tidy script
(http://infohound.net/tidy/tidy.pl) claims everything is ok..

Who is right ? I am asking this because i would like to write clean
html. If the w3 validator is right how should i suppres the borders in
a frameset ?

Thanks, Arie
below my file: (as well as on http://www.kpc.nl/home.html)

1: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
"http://www.w3.org/TR/html4/frameset.dtd">
2:
3: <html>
4: <head>
5: <title>Keizer Prestatie Consultancy</title>
6: <meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1">
7: </head>
8:
9: <frameset rows="125,*" border="0" frameborder="0">
10: <frame name="topframe" scrolling="auto"
src="interface/top.html">
11: <frameset cols="175,*" border="0">
12: <frame name="toc" scrolling="no"
src="interface/toc/index.htm">
13: <frame name="content" scrolling="auto"
src="content/home/index.html">
14:
15: </frameset>
16: </frameset>
17:
18: <noframes><body>
19:
20: </body></noframes>
21:
22:
23:
24: </html>

Jul 23 '05 #1

Follow Post Reply

2419

Bjoern Hoehrmann

* Arie Mijnlieff wrote in comp.infosystems.www.authoring.html:

I have an html file (http://www.kpc.nl/home.html) which i send to the
w3 validator as well as to a an online HTML tidy script.

The w3 validator (validator.w3.org) claims the frameset tag doesnt
have a border tag whereas the html tidy script
(http://infohound.net/tidy/tidy.pl) claims everything is ok..

The version of Tidy that this online interface uses is probably outdated
as the current Tidy correctly reports

* % get http://www.kpc.nl/home.html | tidy -e
* line 9 column 1 - Warning: <frameset> proprietary attribute "border"
* line 9 column 1 - Warning: <frameset> proprietary attribute "frameborder"
* line 11 column 9 - Warning: <frameset> proprietary attribute "border"
* Info: Doctype given is "-//W3C//DTD HTML 4.01 Frameset//EN"
* Info: Document content looks like HTML Proprietary
--
Björn Höhrmann · mailto:bj****@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Jul 23 '05 #2

Pierre Goiffon

Bjoern Hoehrmann wrote:

line 9 column 1 - Warning: <frameset> proprietary attribute "border"

The question is : what is the equivalent for this attribute ? I tried
few CSS stuffs but can't manage to get the same result.
Maybe the best thing is to use HTML 3.2 ?

Jul 23 '05 #3

David Dorward

Pierre Goiffon wrote:

Bjoern Hoehrmann wrote:
line 9 column 1 - Warning: <frameset> proprietary attribute "border"
The question is : what is the equivalent for this attribute ?
http://w3.org/TR/html4/present/frames.html#h-16.2.2

<frame ... frameborder="...">

IIRC, browser support is close to non-existent.
I tried few CSS stuffs but can't manage to get the same result.
CSS doesn't touch on frames.
Maybe the best thing is to use HTML 3.2 ?

HTML 3.2 doesn't have frames in it at all.

http://w3.org/TR/html4/appendix/changes.html#h-A.3 - FRAME and FRAMESET are
listed under the new elements.

Frames come loaded with accessibility problems, and are almost always best
avoided. You appear to be using them as a means to include common content
on multiple pages. Better techniques for that are described at
http://www.allmyfaqs.com/faq.pl?Incl...ile_in_another
--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is

Jul 23 '05 #4

Steve Pugh

Pierre Goiffon <pg******@invalid.fr> wrote:

Bjoern Hoehrmann wrote:
line 9 column 1 - Warning: <frameset> proprietary attribute "border"
The question is : what is the equivalent for this attribute ?

In HTML 4.x and XHTML 1.0 the equivalent is setting frameborder="0" on
each <frame>. Browser support is (almost?) non-existant,
I tried few CSS stuffs but can't manage to get the same result.
In theory a stylesheet linked to from the frameset document that
specifies
frame {border: none;}
might (but it's hard to tell as the CSS spec doesn't mention how
frames fit into the CSS box model) work but browser support may or may
not be there.
Maybe the best thing is to use HTML 3.2 ?

Good idea in this case. Frames don't exist in HTML 3.2.

In practice you have three options:
1. Invalid, borderless frames.
2. Valid, bordered frames.
3. Don't use frames.

Teve

--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>

Jul 23 '05 #5

Lachlan Hunt

Arie Mijnlieff wrote:

I have an html file (http://www.kpc.nl/home.html)

I see no good reason to be using frames in this instance, and they have
been poorly implemented. In fact, there are very few good uses of
frames in existance. You have also totally failed to provide any no
frames content, making your site useless to any user agent that does not
support frames, such as google.

You will find it much more effective to combine all three frames
together into an individual document and position the content using
style sheets.

--
Lachlan Hunt
http://lachy.id.au/
http://GetFirefox.com/ Rediscover the Web
http://SpreadFirefox.com/ Igniting the Web

Jul 23 '05 #6

Pierre Goiffon

Steve Pugh wrote:

The question is : what is the equivalent for this attribute ?

David, Steve, thanks for anwsers.
In fact I tried frameborder and border:none but none of these solution
have enough browser support to be used on the w3

Jul 23 '05 #7

Jukka K. Korpela

Steve Pugh <st***@pugh.net> wrote:

In practice you have three options:
1. Invalid, borderless frames.
2. Valid, bordered frames.
3. Don't use frames.

There _is_ a fourth option too. I don't recommend it, except perhaps as a
lesser evil than 1:

4. Use the nonstandard attributes, and validate against a customized DTD.

The frameset document won't conform to HTML specifications then (those
specs disallow all customized DTDs, even DTDs that are just _stricter_ than
Strict!), but it would be a valid SGML document, it would behave just as
well as case 1, and most importantly you would catch _unintentional_
deviations from "standard" HTML, such as a forgotten end tag or misspelled
attribute name.

I recently wrote a document on customized DTDs:
http://www.cs.tut.fi/~jkorpela/html/own-dtd.html
and you might simply test the idea by replacing your frameset document's
DOCTYPE declaration with
<!DOCTYPE HTML SYSTEM "http://www.cs.tut.fi/~jkorpela/html/frameset.dtd">
(though you would need to use a validator like
http://www.htmlhelp.com/validator/
since the W3C validator has "mystery meat" limitations).

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

Jul 23 '05 #8

Andreas Prilop

On 13 Feb 2005, Arie Mijnlieff wrote:

http://www.kpc.nl/home.html

6: <meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1">

In addition to the other comments:
Specify the encoding (charset) of your pages in the HTTP header
and get rid of this ersatz <meta http-equiv>.
http://www.w3.org/International/O-HTTP-charset.html
http://ppewww.ph.gla.ac.uk/~flavell/...t/ns-burp.html

Jul 23 '05 #9

AES

In article <cu*******************@news.demon.co.uk>,
David Dorward <do*****@yahoo.com> wrote:

Frames come loaded with accessibility problems, and are almost always best
avoided. You appear to be using them as a means to include common content
on multiple pages. Better techniques for that are described at
http://www.allmyfaqs.com/faq.pl?Incl...ile_in_another

This oft-repeated assertion is FALSE. The list of "better techniques"
to be (allegedly) found at that web site comprises:

* HTML Preprocessing (Do it before uploading) Works for everyone
* Server Side Includes (Have the webserver do it) Needs server
support
* Server Side Scripting (Have it done on the webserver by another
program) Needs server support
* Frames (Have the browser do it) Requires client support
* Objects (Have the browser do it) Requires client suppport
* Client Side Scripting (Have the browser do it) Requires advanced
client support

Note that there is NO technique on this list that can be accomplished
with just plain old unassisted HTML. Even the first one, which
supposedly "works for everyone", in fact requires moderately complex
processing and modification of your HTML documents before you upload
them.

Asking for a _simple, easy to use_ means to "include common content on
multiple pages" is a perfectly reasonable request, and a desirable
capability for plain vanilla HTML. If frames provide the only way to
accomplish this, well, they'll naturally be used. If anyone wants to
point to another genuinely better way to meet this need _within plain
vanilla, unprocessed HTML_, I'll be delighted to hear of it.

[And incidentally, my take after reading a lot of the opinions (aka
rants) that have been posted on this group and on HTML pages concerning
the alleged problems of frames is that most of these reasons are at this
point either minor, irrelevant, or obsolete.]

Jul 23 '05 #10

Jukka K. Korpela

AES <si*****@stanford.edu> wrote:

Asking for a _simple, easy to use_ means to "include common content on
multiple pages" is a perfectly reasonable request, and a desirable
capability for plain vanilla HTML.
Certainly. And it actually exists in HTML as formally defined; browser
vendors just didn't bother implementing it. But just saying that the
request is reasonable does not make it fulfilled.
If frames provide the only way to accomplish this,

The condition is simply false, so your longish rant is pointless.

Frames do _not_ provide a method to include common content on multiple
pages.

And the method that they provide to create a false impression of such
inclusion is neither simple nor easy to use. It's no wonder that most use
of frames fails to follow even the simplest guidelines such as naming
frames by their function and content, not position, and always including a
useful noframes content. So frames clearly exceed the authoring skills of
most people who try to use them.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

Jul 23 '05 #11

Harlan Messinger

AES wrote:

Asking for a _simple, easy to use_ means to "include common content on
multiple pages" is a perfectly reasonable request, and a desirable
capability for plain vanilla HTML. If frames provide the only way to
accomplish this, well, they'll naturally be used. If anyone wants to
point to another genuinely better way to meet this need _within plain
vanilla, unprocessed HTML_, I'll be delighted to hear of it.
There isn't. But what of it? Almost any server can provide some
server-side technology, hosting services provide it for very little
money or build it into their basic service level, and SSI is exceedingly
easy, with no programming required.
[And incidentally, my take after reading a lot of the opinions (aka
rants) that have been posted on this group and on HTML pages concerning
the alleged problems of frames is that most of these reasons are at this
point either minor, irrelevant, or obsolete.]

The inability to link to or bookmark a page will never be minor or
irrelevant or become an obsolete issue.

Jul 23 '05 #12

Darin McGrew

AES <si*****@stanford.edu> wrote:

Asking for a _simple, easy to use_ means to "include common content on
multiple pages" is a perfectly reasonable request, and a desirable
capability for plain vanilla HTML.
There are all sorts of "perfectly reasonable" things that the various major
browser vendors haven't bothered to implement over the years. I waited
years for decent cross-browser support for en dashes and em dashes. At this
point, I doubt we'll ever see decent support for captioned figures (not
div-soup or table-based workarounds, but real structural captioned figures
a la HTML 3.0).
If frames provide the only way to accomplish this, well, they'll
naturally be used.

The problem is that doing a frames-based site right (working around the
various accessibility/usability problems inherent in the design of frames)
is a lot more complicated than any of the other solutions that you decry
(preprocessing, SSI, server-side or client-side scripting, objects).
--
Darin McGrew, da***@TheRallyeClub.org, http://www.TheRallyeClub.org/
A gimmick car rallye is not a race, but a fun puzzle testing your
ability to follow instructions. Upcoming gimmick car rallye in
Silicon Valley: The Prisoner (Saturday, March 5)

Jul 23 '05 #13

Alan J. Flavell

On Mon, 14 Feb 2005, Harlan Messinger wrote:

AES wrote:
Asking for a _simple, easy to use_ means to "include common content on
multiple pages" is a perfectly reasonable request,
Maybe, but it's one that isn't fulfilled by HTML as we have it.
If frames provide the only way to
accomplish this, well, they'll naturally be used.
They don't by any means provide "the only way".
If anyone wants to point to another genuinely better way to meet
this need _within plain vanilla, unprocessed HTML_,
That's just being silly. The WWW does not care in the least how you
assemble the content in the privacy of your own server; its rules
apply to the data stream that comes out of the server at the end of
that process. That data stream needs to conform to the rules of HTML
and the limitations of available client agents, but that doesn't stop
you using any appropriate techniques for /generating/ it.
I'll be delighted to hear of it.
Stop trolling, please.

There isn't. But what of it? Almost any server can provide some
server-side technology, hosting services provide it for very little
money or build it into their basic service level,
Indeed. (Or some preprocessor and a makefile etc.)
and SSI is exceedingly easy, with no programming required.

Except that SSI is harmful to cacheability, especially if it's used in
a naive way. There's nothing wrong with server-side assembly of pages
as a principle, but I'd want to give the various options some thought
before making a choice. (Apache's "XBitHack full" might be a better
compromise, if you're otherwise happy with SSI - but it's still only
one from quite a number of options).
[And incidentally, my take after reading a lot of the opinions
(aka rants) that have been posted on this group and on HTML pages
concerning the alleged problems of frames is that most of these
reasons are at this point either minor, irrelevant, or obsolete.]

The inability to link to or bookmark a page will never be minor or
irrelevant or become an obsolete issue.

Bookmarking can be sort-of overcome, locally, but that doesn't
help when one needs to link to a particular frame configuration, or
to send its URL to a friend.

In fact, it's clear that a substantial proportion of the users of
frames see the difficulties of navigation as a /benefit/ - forcing
their readers to enter by the front door, and proceed along a path
that the author has laid out for them, no matter what the user might
want. Even if frames had no other disadvantages, I wouldn't really
want to be seen to associate with such control-freaks.

all the best

Jul 23 '05 #14

valid html for framesets

This discussion thread is closed

Similar topics