frames [lame]

[a]

Hi,

Got some problem:
I've got 3 frames e.g.

<frameset rows="80%,20%">
<frameset cols="50%,50%">
<frame src ="stats.php" name="left">
<frame src ="flag.php" name="right">
</frameset>
<frame src = "command.php" >

</frameset>

and i want to use data from little form (below) in command.php in 2 other
frames. How can i send data form this form and use it in other frames? If
use POST i send it only to 1 frame

[command.php]

<FORM METHOD = POST action="sojusz.php" TARGET = "right" >
Name:
<INPUT TYPE = TEXT NAME ="player" SIZE = 25>

<INPUT TYPE = HIDDEN NAME = "stage" VALUE = 1" >
<INPUT TYPE = SUBMIT VALUE = "Search">
</FORM>

 

[a]

corrected code:

[command.php]

<FORM METHOD = POST action="flag.php" TARGET = "right" >
Name:
<INPUT TYPE = TEXT NAME ="player" SIZE = 25>

<INPUT TYPE = HIDDEN NAME = "stage" VALUE = 1" >
<INPUT TYPE = SUBMIT VALUE = "Search">
</FORM>

 

[Leif K-Brooks]

Got some problem:
I've got 3 frames

That is a serious problem! <http://html-faq.com/htmlframes/?framesareevil>

 

[Mark Parnell]

Hi,
G'day.

Got some problem:
I've got 3 frames

That sounds like 3 problems to me.

Problems with frames:
http://www.htmlhelp.com/design/frames/whatswrong.html
http://html-faq.com/htmlframes/?framesareevil
http://dorward.me.uk/www/frames/

Search Engines and Frames:
http://www.google.com/webmasters/2.html (see under "Your pages use
frames")
http://searchenginewatch.com/webmasters/article.php/2167901

Using Frames Properly:
http://www.markparnell.com.au/articles/frames.php

 

[Jake]

Hi,

Got some problem:
I've got 3 frames e.g.

<frameset rows="80%,20%">
<frameset cols="50%,50%">
<frame src ="stats.php" name="left">
<frame src ="flag.php" name="right">
</frameset>
<frame src = "command.php" >

</frameset>

and i want to use data from little form (below) in command.php in 2 other
frames. How can i send data form this form and use it in other frames? If
use POST i send it only to 1 frame

[command.php]

<FORM METHOD = POST action="sojusz.php" TARGET = "right" >
Name:
<INPUT TYPE = TEXT NAME ="player" SIZE = 25>

<INPUT TYPE = HIDDEN NAME = "stage" VALUE = 1" >
<INPUT TYPE = SUBMIT VALUE = "Search">
</FORM>

You'll probably get a better response from one of the Javascript groups,
which is what you are going to have to use.

Just one suggestion. When you give a name to each of the frames, you
should make the names meaningful e.g. 'Navigation' 'Main Content'.
People who can't see your site, but listen to it, will find meaningful
names easier to work with.

(Sits back and waits for the frames-are-evil fundamentalists to quote
the usual bogus arguments)

regards.

 

[Mitja Trampus]

Hi,

Got some problem:
I've got 3 frames e.g.

<frameset rows="80%,20%">
<frameset cols="50%,50%">
<frame src ="stats.php" name="left">
<frame src ="flag.php" name="right">
</frameset>
<frame src = "command.php" >

</frameset>

and i want to use data from little form (below) in command.php in 2 other
frames. How can i send data form this form and use it in other frames? If
use POST i send it only to 1 frame

[command.php]

<FORM METHOD = POST action="sojusz.php" TARGET = "right" >
Name:
<INPUT TYPE = TEXT NAME ="player" SIZE = 25>

<INPUT TYPE = HIDDEN NAME = "stage" VALUE = 1" >
<INPUT TYPE = SUBMIT VALUE = "Search">
</FORM>

You'll probably get a better response from one of the Javascript groups,
which is what you are going to have to use.

Since you're already using php, I'd suggest you stick with
that - it's much more accessible for search engines and a
presumably noticable percentage of other users, although a
slight bit heavier on the server.

Do something like:

[main page]:
<frameset>
<frame src="topframes.php" name="top">
<frame src="bottom.php">
</frameset>

[bottom]:
<form action="topframes.php" target="top">

[topframes]:
A php that receives GET parameters and passes them on to the
two pages in question.
<frameset>
<frame src="topleft.php?get_parameters">
<frame src="topright.php?get_parameters">
</frameset>

For this to work, however, POST is out - you'll have to use
GET. Workarounds for POST are possible but ugly.


And, as many others suggested - if you're using php already,
making the move from frames to dynamically appended menus
would not exactly hurt.

 

[dorayme]

(Sits back and waits for the frames-are-evil fundamentalists to quote
the usual bogus arguments)

Jake, in a first move to be rid of frames on my remaining frames
site, I turned all the *actual* content and navigation pages (as
distinct from the frameset pages which are in 4.01 Frameset)
into 4.01 Strict in a CSS overhaul. All was fine but I was then
surprised to find that my home link on these pages was not W3C
kosher because this DTD does not support the "target" attribute
(="_top"). I use this attribute so that the home page (which is
not a frameset at all) comes up in the whole browser window
rather than in one of the two frames (simple nav left and
content right). W3C says to use Transitional for this attribute.
I could not face going back so I left it and it works still in
all the browsers I know. But it is an irritation as I like at
least to have stuff validate. Any thoughts on this? How bad is
it to be not quite validated in this respect in your opinion?

dorayme

 

[rf]

dorayme wrote:

[target attribute]

How bad is
it to be not quite validated in this respect in your opinion?

I'm not jake but I have an opinion.

Validation is a tool, not an end in itself. You have made a concious
decision to use a single peice of HTML that is not valid to the DTD you
use. That's not bad at all IMHO. What *would* be bad is if you simply
ignored the validator entirely, which you don't.

Also, being legacy code, near enough is good enough

 

[Mark Parnell]

Validation is a tool, not an end in itself. You have made a concious
decision to use a single peice of HTML that is not valid to the DTD you
use. That's not bad at all IMHO. What *would* be bad is if you simply
ignored the validator entirely, which you don't.

I'll second that.

Also, being legacy code, near enough is good enough

Especially if you (dorayme) are in the process of removing the frames -
once that is complete, you can remove the target attribute anyway.

 

[dorayme]

dorayme wrote:

[target attribute]

How bad is
it to be not quite validated in this respect in your opinion?

I'm not jake but I have an opinion.

Validation is a tool, not an end in itself. You have made a concious
decision to use a single peice of HTML that is not valid to the DTD you
use. That's not bad at all IMHO. What *would* be bad is if you simply
ignored the validator entirely, which you don't.

Also, being legacy code, near enough is good enough

OK Richard. I guess I was wanting to know if there were any
practical consequences I should be worried about in the coming
few months in respect to just this particular link...

dorayme

 

[rf]

From: rf <[email protected]>

dorayme wrote:

[target attribute]

How bad is
it to be not quite validated in this respect in your opinion?

I'm not jake but I have an opinion.

Validation is a tool, not an end in itself. You have made a concious
decision to use a single peice of HTML that is not valid to the DTD you
use. That's not bad at all IMHO. What *would* be bad is if you simply
ignored the validator entirely, which you don't.

Also, being legacy code, near enough is good enough

OK Richard. I guess I was wanting to know if there were any
practical consequences I should be worried about in the coming
few months in respect to just this particular link...

dorayme

You mean will a browser care? Well, no, browsers dont give a damn about
validation. You can throw every bit of deprecated transitional stuff you
can find at them and they will attempt to render it. You can even, as we
know, throw totally invalid stuff at them and some of them will still
render it.

Deprecated elements/attributes will be supported for a *long* time to come.
Microsoft aren't going to get rid of the height attributes they use in
their table cells any time soon and google will continue to use font
elements

 

[dorayme]

I'll second that.


Especially if you (dorayme) are in the process of removing the frames -
once that is complete, you can remove the target attribute anyway.

Hi Mark, btw, I read a piece you wrote on frames while I
investigated this matter (I had it bookmarked from some time
ago). Very good I thought. Anyway I have accidentally discovered
for myself a further "disadvantage" to frames. ie. inability to
use the set of advantages flowing from 4.01 Strict while
remaining valid!

dorayme

 

[Jake]

Jake, in a first move to be rid of frames on my remaining frames
site, I turned all the *actual* content and navigation pages (as
distinct from the frameset pages which are in 4.01 Frameset)
into 4.01 Strict in a CSS overhaul. All was fine but I was then
surprised to find that my home link on these pages was not W3C
kosher because this DTD does not support the "target" attribute
(="_top"). I use this attribute so that the home page (which is
not a frameset at all) comes up in the whole browser window
rather than in one of the two frames (simple nav left and
content right). W3C says to use Transitional for this attribute.
I could not face going back so I left it and it works still in
all the browsers I know. But it is an irritation as I like at
least to have stuff validate. Any thoughts on this? How bad is
it to be not quite validated in this respect in your opinion?

dorayme

Yes, a (minor) problem.

Any pages that I do are validated as 4.01 strict.

However, I do have a small number of pages that use an Iframe and, as I
load the content of the Iframe based on a user decision (i.e. They click
one of a series of links and the Iframe gets filled with the appropriate
content -- usually a series of maps at various resolutions) I validate
those pages as 'transitional'.

The pages work OK in IE6, Firefox, Opera, Mozilla and Netscape ...... so
I'm quite happy with that.

In reality, I could have left the page as 'strict' -- with the one error
being flagged by the validator; I doubt it would have made any
difference.

-----------------------------------------------------------------

I also make a practice of opening all external links in a new window. In
this case I avoid the use of a 'target' on the link by setting "
rel='external' " in the link and using a piece of Javascript to set the
'target' based on 'rel'.

The pages can then be validated as '4.01 strict'.

(Users without Javascript enabled -- about 1% or less -- get to see the
external page in the same window.)

regards.

 

[rf]

I also make a practice of opening all external links in a new window. In
this case I avoid the use of a 'target' on the link by setting "
rel='external' " in the link and using a piece of Javascript to set the
'target' based on 'rel'.

So, you "validate" to the strict DTD and then use some javascript
skulduggery to get around the fact that you are actually "realising"
something that belongs in transitional

Why not simply accept the fact that you are intentionally doing one single
thing that does not validate to a certain DTD?

The pages can then be validated as '4.01 strict'.

See above. Validation is not a requirement, nor a be all and end all, it is
a handy tool. You *can* choose to ingore, knowingly, some validation
errors.

(Users without Javascript enabled -- about 1%

Other sources cite around 10 to 15%.

or less -- get to see the
external page in the same window.)

Oh happy days. I am now going to disable javascript so *I* have the choice
of opening your "external" link in a new window if *I* choose to (or not),
not if *you* choose me to

 

[Jake]

So, you "validate" to the strict DTD and then use some javascript
skulduggery to get around the fact that you are actually "realising"
something that belongs in transitional

Nope.

With the removal of 'target' from the specifications, HTML is now
concerned more with the content of the page.

The 'rel' attribute on the link is valid HTML and is used to specify
the relationship between the page containing the link, and its target:
in this case, Javascript simply provides the implementation mechanism
when that target is a new window..

The js-deficient user, however, gets to see the content in the same
window -- 'graceful degradation', no?

Why not simply accept the fact that you are intentionally doing one single
thing that does not validate to a certain DTD?

Because it's not necessary, is it?

See above. Validation is not a requirement, nor a be all and end all, it is
a handy tool. You *can* choose to ingore, knowingly, some validation
errors.


Other sources cite around 10 to 15%.

I just go by what I see -- about 1% or less. YMMV.

Oh happy days. I am now going to disable javascript so *I* have the choice
of opening your "external" link in a new window if *I* choose to (or not),
not if *you* choose me to

Isn't 'choice' wonderful?

There is, however IMO, one good reason for opening external links in a
new window: namely, you have no control over the content of the new
page.

Ever been to a site which, with badly-tested flash and/or javascript,
prevents the back-button from ever working?

If you're the user of an AT UA it's nice to be able to simply 'kill' the
offending (current) window and know that you're safely back where you
came from without having to reload the browser..

regards.

 

[Barbara de Zoete]

In message <[email protected]>, rf <[email protected]>
writes

[ target= depricated; can use javascript for external link to open in new window
]

Isn't 'choice' wonderful?

There is, however IMO, one good reason for opening external links in a new
window: namely, you have no control over the content of the new page.

Ever been to a site which, with badly-tested flash and/or javascript, prevents
the back-button from ever working?

If you're the user of an AT UA it's nice to be able to simply 'kill' the
offending (current) window and know that you're safely back where you came
from without having to reload the browser..

No, you just provided more reasons to not enable javascript (or flash for that
matter) while browsing

--
,-- --<--@ -- PretLetters: 'woest wyf', met vele interesses: ----------.
| weblog | http://home.wanadoo.nl/b.de.zoete/_private/weblog.html |
| webontwerp | http://home.wanadoo.nl/b.de.zoete/html/webontwerp.html |
|zweefvliegen | http://home.wanadoo.nl/b.de.zoete/html/vliegen.html |
`-------------------------------------------------- --<--@ ------------'

 

[Mark Parnell]

Ever been to a site which, with badly-tested flash and/or javascript,
prevents the back-button from ever working?

Yes, but I've never linked to any. ;-)

 

[rf]

Jake wrote:

[opening new window]

Ever been to a site which, with badly-tested flash and/or javascript,
prevents the back-button from ever working?

And what does your solution do? Breaks the back button.

 

[Jake]

Jake wrote:

[opening new window]

Ever been to a site which, with badly-tested flash and/or javascript,
prevents the back-button from ever working?

And what does your solution do? Breaks the back button.

You've lost me there, I'm afraid.

As you've opened the page in a new window -- how is the back button
relevant?

Anyway, as I've said -- much easier to kill a window than to reload the
browser.

Regards.

 

[Jake]

In message

Yes, but I've never linked to any. ;-)

...... Just make sure you check regularly ;-)

regards.