Form won't validate without action/method?

[Pete]

I have form/select which executes a function using onchange. No
problem. However, when I validate the page with a strict HTML 4.01
doctype at http://validator.w3.org, it demands either an action or a
method for the form?.

If I give it an empty action <form action="" ..... it validates OK. Is
this acceptable or is there a better/standards correct way?

Thanks.

[McKirahan]

"Pete" <so*******************@yahoo.co.uk> wrote in message
news:1a*************************@posting.google.co m...

I have form/select which executes a function using onchange. No
problem. However, when I validate the page with a strict HTML 4.01
doctype at http://validator.w3.org, it demands either an action or a
method for the form?.

If I give it an empty action <form action="" ..... it validates OK. Is
this acceptable or is there a better/standards correct way?

Thanks.

I believe that a missing or blank "action=" will default to the current page
and that a missing "method=" will default to "get". If "get" is specifed
(or defaulted to) instead of "post" then, on form submission, the
querystring (which follows the URL) will contain a list of the form fields
and there values.

It's good form to specify both; for example,

<form action="thispage.htm" method="post">

[Michael Winter]

On 10 Feb 2004 20:27:22 -0800, Pete <so*******************@yahoo.co.uk>
wrote:

I have form/select which executes a function using onchange. No
problem. However, when I validate the page with a strict HTML 4.01
doctype at http://validator.w3.org, it demands either an action or a
method for the form?.
The action attribute is required and the method attribute defaults to GET.
Specifying 'action=""' will submit the form to the current page.
If I give it an empty action <form action="" ..... it validates OK. Is
this acceptable or is there a better/standards correct way?

It would appear that you're only using a form in order to access the form
controls. Is this assumption correct? If so, you should avoid this
practice: it is quite simple to script an interface with form controls,
without actually requiring an enclosing form element. Please post the
code, or provide a URI, if you're interested.

Mike

--
Michael Winter
M.******@blueyonder.co.invalid (replace ".invalid" with ".uk" to reply)

[Richard Cornford]

"Michael Winter" <M.******@blueyonder.co.invalid> wrote in message
news:op**************@news-text.blueyonder.co.uk...
<snip>

It would appear that you're only using a form in order to access
the form controls. Is this assumption correct? If so, you should
avoid this practice: it is quite simple to script an interface
with form controls, without actually requiring an enclosing form
element. ...

If support for Netscape 4 is relevant then the form is needed, as
otherwise the controls don't display (similarly, without a form HotJava
will show the controls but you can't do anything with them. Not that
anyone in their right mind would use HotJava as a web browser any more).

Certainly once Netscape 4 is gone there will be no need for the form
elements if there is no intention to submit anything. But with a form
the - form - properties of the controls would still provide a convenient
way for controls to refer to each other without having to go to the
document and look each other up by ID. Possibly allowing multiple forms
to implement similar patterns without interfering with each other
(server-side loop generated).

Also, the onsubmit handler might sometimes be a good level at which to
place an event handler even if it had to always return false. And
controls in forms are relatively easy to fall-back to server-side
scripts in the absence of client-side support. While a control outside
of a form is going to be pretty pointless without client-side scripting.

Richard.

[Michael Winter]

On Wed, 11 Feb 2004 16:16:34 -0000, Richard Cornford
<Ri*****@litotes.demon.co.uk> wrote:

"Michael Winter" <M.******@blueyonder.co.invalid> wrote in message
news:op**************@news-text.blueyonder.co.uk...
<snip>

It would appear that you're only using a form in order to access
the form controls. Is this assumption correct? If so, you should
avoid this practice: it is quite simple to script an interface
with form controls, without actually requiring an enclosing form
element. ...
If support for Netscape 4 is relevant then the form is needed, as
otherwise the controls don't display (similarly, without a form HotJava
will show the controls but you can't do anything with them. Not that
anyone in their right mind would use HotJava as a web browser any more).

Quite right. I forgot about the problems associated with NN4.
Certainly once Netscape 4 is gone there will be no need for the form
elements if there is no intention to submit anything. But with a form
the - form - properties of the controls would still provide a convenient
way for controls to refer to each other without having to go to the
document and look each other up by ID. Possibly allowing multiple forms
to implement similar patterns without interfering with each other
(server-side loop generated).
True, but I wouldn't like to advocate bad practices like HTML element
abuse just for the purposes of convenience. That is the domain of tables
for layout, and the like.
Also, the onsubmit handler might sometimes be a good level at which to
place an event handler even if it had to always return false. And
controls in forms are relatively easy to fall-back to server-side
scripts in the absence of client-side support. While a control outside
of a form is going to be pretty pointless without client-side scripting.

That was why I asked the OP to post code if the question revolved solely
around a UI: to give useful advice, we would need to know what was trying
to be accomplished.

Mike

--
Michael Winter
M.******@blueyonder.co.invalid (replace ".invalid" with ".uk" to reply)

[Richard Cornford]

"Michael Winter" <M.******@blueyonder.co.invalid> wrote in message
news:op**************@news-text.blueyonder.co.uk...
<snip>

... . But with a form the - form - properties of the controls would
still provide a convenient way for controls to refer to each other
without having to go to the document and look each other up by ID.
Possibly allowing multiple forms to implement similar patterns
without interfering with each other (server-side loop generated).
True, but I wouldn't like to advocate bad practices like HTML element
abuse just for the purposes of convenience. That is the domain of
tables for layout, and the like.

But is it element abuse akin to using tables for layout? As I understand
it the argument with tables is that semantically table implies tabular
data and so is inappropriate for non-tabular data and in almost all
circumstances tables used for layout would not (directly) contain
tabular data.

Among the many definitions of "form" in the first dictionary that came
to hand, the only definition that seemed pertinent was:-

Form:
"A printed document, esp. one with spaces in which to insert facts or
answers: an application form."

We can forget about "printed" in our context and "document" is not the
usual HTML/DOM document, but "with spaces in which to insert facts or
answers" seems very relevant to this context. It implies that the
semantic meaning of FORM is as a container of spaces in which to insert
facts or answers; form controls.

So where is the abuse if form controls are contained in a form,
submitted or not?

I realise that is just one of many possible interpretations and someone
wanting to stress the submitability of a form would point out that it
has a required ACTION attribute and that is fairly meaningless if the
form is not intended to be submitted. But I wouldn't like to rule out a
potentially useful construct just because of a dogma.

<snip>... , we would need to know what was trying to be accomplished.

Don't we always? ;-)

Richard.

[Michael Winter]

On Wed, 11 Feb 2004 19:02:39 -0000, Richard Cornford
<Ri*****@litotes.demon.co.uk> wrote:

"Michael Winter" <M.******@blueyonder.co.invalid> wrote in message
news:op**************@news-text.blueyonder.co.uk...
<snip>

... . But with a form the - form - properties of the controls would
still provide a convenient way for controls to refer to each other
without having to go to the document and look each other up by ID.
Possibly allowing multiple forms to implement similar patterns
without interfering with each other (server-side loop generated).
True, but I wouldn't like to advocate bad practices like HTML element
abuse just for the purposes of convenience. That is the domain of
tables for layout, and the like.

[snip]
Form:
"A printed document, esp. one with spaces in which to insert facts or
answers: an application form."

We can forget about "printed" in our context and "document" is not the
usual HTML/DOM document, but "with spaces in which to insert facts or
answers" seems very relevant to this context. It implies that the
semantic meaning of FORM is as a container of spaces in which to insert
facts or answers; form controls.

So where is the abuse if form controls are contained in a form,
submitted or not?

Button elements used to initiate script actions? Checkboxes or radio
buttons that affect page behaviour (assuming there is no server-side
support)?

I'm useless at coming up with examples like this, so there might be other,
better uses to illustrate my point. However, neither of the above fit the
definition of a form, would be submittable, and thereby warrant the use of
a form element.

Mike

--
Michael Winter
M.******@blueyonder.co.invalid (replace ".invalid" with ".uk" to reply)

[Richard Cornford]

"Michael Winter" <M.******@blueyonder.co.invalid> wrote in message
news:op**************@news-text.blueyonder.co.uk...
<snip>

Form:
"A printed document, esp. one with spaces in which to insert
facts or answers: an application form." <snip>... , but "with spaces in which to insert facts or answers"
seems very relevant to this context. It implies that the
semantic meaning of FORM is as a container of spaces in which
to insert facts or answers; form controls.

So where is the abuse if form controls are contained in a form,
submitted or not?
Button elements used to initiate script actions? Checkboxes or radio
buttons that affect page behaviour (assuming there is no server-side
support)?

Thinking about it I am going to have to concede that a semantic
definition of FORM that considers it a container for from controls would
have to require that there be more than one control and that all of the
controls in a form would have to be related. An isolated control, say a
button, probably isn't any more than a control and that would probably
extend to sets of like-named radio buttons.

But given multiple related controls within a form I don't think that
what those controls actually do is relevant, and I don't think it
matters which type of controls they are. Even buttons are an opportunity
to enter the answer to a question; the question "are you going to press
this button?".
I'm useless at coming up with examples like this, so there might
be other, better uses to illustrate my point.
There are plenty of other people to volunteer an opinion.
However, neither of the above fit the definition of a form, would be
submittable, and thereby warrant the use of a form element.

So are you saying that form means submittable? It is the crux of the
matter, does semantic mark-up mean what it says or mean what it does?

Richard.

[Michael Winter]

On Wed, 11 Feb 2004 20:35:46 -0000, Richard Cornford
<Ri*****@litotes.demon.co.uk> wrote:

"Michael Winter" <M.******@blueyonder.co.invalid> wrote in message
news:op**************@news-text.blueyonder.co.uk...
<snip>

Form:
"A printed document, esp. one with spaces in which to insert
facts or answers: an application form." <snip> ... , but "with spaces in which to insert facts or answers"
seems very relevant to this context. It implies that the
semantic meaning of FORM is as a container of spaces in which
to insert facts or answers; form controls.

So where is the abuse if form controls are contained in a form,
submitted or not?
Button elements used to initiate script actions? Checkboxes or radio
buttons that affect page behaviour (assuming there is no server-side
support)?

Thinking about it I am going to have to concede that a semantic
definition of FORM that considers it a container for from controls would
have to require that there be more than one control and that all of the
controls in a form would have to be related. An isolated control, say a
button, probably isn't any more than a control and that would probably
extend to sets of like-named radio buttons.

But given multiple related controls within a form I don't think that
what those controls actually do is relevant, and I don't think it
matters which type of controls they are. Even buttons are an opportunity
to enter the answer to a question; the question "are you going to press
this button?".

I did consider that as I wrote my previous post.

I'm useless at coming up with examples like this, so there might
be other, better uses to illustrate my point.

There are plenty of other people to volunteer an opinion.

However, neither of the above fit the definition of a form, would be
submittable, and thereby warrant the use of a form element.

So are you saying that form means submittable?

Not necessarily, but I can't think of anything that I might describe as a
form, that I wouldn't implement as a submittable form. As I pointed out,
creating random examples isn't my forte.
It is the crux of the matter, does semantic mark-up mean what it says
or mean what it does?

The former. For example, a DIV should partition a document logically. It
shouldn't be used just because it puts some space above and below the
element, particularly as there is nothing in the specification that says
it should do so.

This then brings us back full-circle: what does 'form' mean, and should
that meaning be the limit of its use? The initial intent would appear to
be for submission to a server, indicated by the required status of the
action attribute, and this, from the Specification:

"Users generally 'complete' a form by modifying its controls...before
submitting the form to an agent for processing."

Based on that, forms shouldn't be used for easy reference, but only if you
mean to send data.

Mike

--
Michael Winter
M.******@blueyonder.co.invalid (replace ".invalid" with ".uk" to reply)

[Pete]

Michael Winter <M.******@blueyonder.co.invalid> wrote in message news:<op**************@news-text.blueyonder.co.uk>...

On 10 Feb 2004 20:27:22 -0800, Pete <so*******************@yahoo.co.uk>
wrote:

I have form/select which executes a function using onchange. No
problem. However, when I validate the page with a strict HTML 4.01
doctype at http://validator.w3.org, it demands either an action or a
method for the form?.

The action attribute is required and the method attribute defaults to GET.
Specifying 'action=""' will submit the form to the current page.

If I give it an empty action <form action="" ..... it validates OK. Is
this acceptable or is there a better/standards correct way?

It would appear that you're only using a form in order to access the form
controls. Is this assumption correct? If so, you should avoid this
practice: it is quite simple to script an interface with form controls,
without actually requiring an enclosing form element. Please post the
code, or provide a URI, if you're interested.

Mike

Thanks Michael.

It's a world clock that I like. It isn't mine and I'm just tidying it
up before using it. The author's original did have (action=" ") but I
couldn't understand why, so I er.. deleted it! Your form assumption is
correct I think. I didn't know you could dump <form> to use its stuff.

Anyway, here's what I'm working from.
http://www.btinternet.com/~kurt.grig...orldclock.html

Pete.

[Michael Winter]

On 11 Feb 2004 15:02:31 -0800, Pete <so*******************@yahoo.co.uk>
wrote:

[snip]

It's a world clock that I like. It isn't mine and I'm just tidying it
up before using it. The author's original did have (action=" ") but I
couldn't understand why, so I er.. deleted it! Your form assumption is
correct I think. I didn't know you could dump <form> to use its stuff.

I was expecting a lot of work, but all you have to do is delete the start
and end form tags. The form element isn't used at all by neither the HTML,
nor the script.

You have a lot of tidying up do to, I'm afraid.

There are *far* too many global variables in the script. Several of them
are quite likely to clash, particularly if other badly written,
'off-the-shelf' scripts are used. There are plenty that can be reduced to
local variables.

<script type="text/javascript">
<!-- World Clock (No DST, standard time only!)

You can remove the SGML comment markers: the reasons for using them are no
longer valid.
It should also be safe to assume that all browsers in use at least
understand the style element, so the same markers can be removed in your
example (in the .zip file).

if (document.getElementById){

This is a good start, but it's insufficient. There are many instances of
the style property being used without testing, as well as the data and
firstChild properties. This also limits the script's availability to more
recent browsers: you don't mention this.

window.onload=ClockAndAssign;

This will destroy any existing handlers. You should either attempt to
chain the events, use DOM's addEventListener() (which should add, not
replace, handlers - I think), or just instruct users to add the function
call to the onload event through HTML.

isItLocal=(z.options[0].selected)?true:false;

The "?true:false" here and elsewhere, is completely pointless. This is
equivalent:

isItLocal = z.options[ 0 ].selected;

In ClockAndAssign()

mins=eval(mins+addOddMinutes);

The eval() is unnecessary: both mins and addOddMinutes are integers. It
would be a bad way of dealing with the situation, even if they weren't.

leap_year=(eval(year%4)==0)?true:false;

This eval(), and the conditional operator, aren't needed, either: year is
an integer, and

year % 4 == 0

evaluates to a boolean, anyway.

That probably isn't the end of it...

Mike

--
Michael Winter
M.******@blueyonder.co.invalid (replace ".invalid" with ".uk" to reply)

[Richard Cornford]

"Michael Winter" <M.******@blueyonder.co.invalid> wrote in message
news:op**************@news-text.blueyonder.co.uk...
<snip>

So are you saying that form means submittable?
Not necessarily, but I can't think of anything that I might
describe as a form, that I wouldn't implement as a submittable
form. As I pointed out, creating random examples isn't my forte.

Designing to take advantage of server-side fall-back is usually a good
idea so even a form that represented a control panel for something that
could operate entirely client-side on an appropriately supportive
browser would be sensible. But that is taking advantage of the
submittability of forms to achieve reliability. But if the client-side
code has no intention of ever letting the form be submitted if it is
capable of executing I don't see that as indicating that a form should
not be present in the HTML.

It is the crux of the matter, does semantic mark-up mean what
it says or mean what it does?

The former. For example, a DIV should partition a document
logically. It shouldn't be used just because it puts some space
above and below the element, particularly as there is nothing in
the specification that says it should do so.

This then brings us back full-circle: what does 'form' mean,
and should that meaning be the limit of its use?

The initial intent would appear to be for submission to a
server, indicated by the required status of the action attribute,
The initial intent is not necessarily relevant as initially client-side
scripting did not exist and so did not need to be considered in design
decisions. And initially the action attribute was not required. Though
the fact that it is required now may speak for current intent.
and this, from the Specification:

"Users generally 'complete' a form by modifying its controls...
before submitting the form to an agent for processing."

Based on that, forms shouldn't be used for easy reference,
but only if you mean to send data.

An interesting choice of quote; the section that I considered quoting,
pointing out that the "agent" receiving the form information could
reasonable be the client-side code. I decided not to because later
sections in the HTML spec could easily undermine that position.

I am not convinced that the HTML specs are going to help much here. They
do describe and specify how a form and its controls are expected to be
handled by a UA in the context of being submitted, they couldn't do
otherwise the specification must specify whatever needs to be
standardised.

The specification also describes the handling of the form controls when
a form is submitted and only leaves two control types (<input
type="button"> and <button type="button">) exclusively for client-side
interaction. So to the extent that it can be argued that FORM is
intended to be submitted and so should not used in contexts where it
will not be submitted, it might also be argued that, for example, SELECT
is also intended to be submitted and should not be used in contexts
where it cannot be.

But while the specification describes how a FORM will be handled when it
is submitted, and requires an action attribute so the UA will know where
to make the request, it does _not_ require that a FORM actually be
submittable. That is, it does not impose a default mechanism for
submission if the form does not contain a control (such as a submit
button, but including others) that can trigger the submission, and it
does not require that such a control be included within the form.

The HTML 4 specification does not impose submittability upon FORM
elements. If it did it probably could be used to override a semantic
interpretation of FORM based on the meaning (dictionary definition) of
the word. As it doesn't I still don't see any reason for considering a
FORM as necessarily other than a container for (multiple, related)
"spaces in which to insert facts or answers".

Richard.

[Dr John Stockton]

JRS: In article <c0*******************@news.demon.co.uk>, seen in
news:comp.lang.javascript, Richard Cornford
<Ri*****@litotes.demon.co.uk> posted at Wed, 11 Feb 2004 16:16:34
:-

Certainly once Netscape 4 is gone there will be no need for the form
elements if there is no intention to submit anything. But with a form
the - form - properties of the controls would still provide a convenient
way for controls to refer to each other without having to go to the
document and look each other up by ID. Possibly allowing multiple forms
to implement similar patterns without interfering with each other
(server-side loop generated).

Is there some element that can be used instead of <FORM name=XX>
.... </form> to give a similar naming structure? DIV or SPAN maybe?
I want to be able to use document.Frm1.ZZ & document.Frm2.ZZ, and
F = document.Frm1 ; ...; F.ZZ & F = document.Frm2 ; ... ; F.ZZ, to
refer to two different-but-similar ZZ.

I could test, but only in my own browser, whereas I want something
that is known to be at least as good as FORM in all reasonable
browsers (include MSIE 4).

Pages such as <URL:http://www.merlyn.demon.co.uk/holidays.htm> are
rather reliant on this capability; and it is always good to
minimise global identifiers.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://jibbering.com/faq/> Jim Ley's FAQ for news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

[Dr John Stockton]

JRS: In article <op**************@news-text.blueyonder.co.uk>, seen in
news:comp.lang.javascript, Michael Winter <M.******@blueyonder.co.invali
d> posted at Thu, 12 Feb 2004 00:00:48 :-

On 11 Feb 2004 15:02:31 -0800, Pete <so*******************@yahoo.co.uk>
wrote: <script type="text/javascript">
<!-- World Clock (No DST, standard time only!)
I've not seen the original page. There should now be no difficulty in
making a clock that shows proper local time in any location for which
the current summer time rules can be put into TZ-string form (Any
Israelis reading this? Do Arabs have indigenous Summer Time?).

leap_year=(eval(year%4)==0)?true:false;

AFAICS, there is never any need to know in javascript if a Gregorian
year is a leap year, except to display the answer to a question such as
"Is it Leap?" or "Has it Feb 29?".
Pete - see below.

For <URL:http://www.merlyn.demon.co.uk/js-date5.htm#SLHGD> it would be
nice to know the correct acronyms for Winter & Summer Time in the test
locations. I think Kobenhavn and Vancouver are right, but my entries
for Moscow, Colombo, & Wagga Wagga are arbitrary substitutes.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://jibbering.com/faq/> Jim Ley's FAQ for news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

[Christopher Jeris]

Michael Winter <M.******@blueyonder.co.invalid> writes:

On 11 Feb 2004 15:02:31 -0800, Pete
<so*******************@yahoo.co.uk> wrote:

leap_year=(eval(year%4)==0)?true:false;

This eval(), and the conditional operator, aren't needed, either: year
is an integer, and

year % 4 == 0

evaluates to a boolean, anyway.

And in any case this is the wrong algorithm. The correct test is

leap_year = (year % 4 == 0) && ((year % 100 != 0) || (year % 400 == 0))

that is, every fourth year is leap, except for the 100th, 200th and
300th year of each 400.

This test applies to Gregorian (new-style) dates only.

(From http://www.uic.edu/depts/accc/softwa...ocontents.html
"ISO 8601 Dates: What They Are and Why They're Good".)

--
Chris Jeris cj****@oinvzer.net Apply (1 6 2 4)(3 7) to domain to reply.

[Michael Winter]

On Thu, 12 Feb 2004 15:13:41 -0000, Richard Cornford
<Ri*****@litotes.demon.co.uk> wrote:

[snip]

Designing to take advantage of server-side fall-back is usually a good
idea so even a form that represented a control panel for something that
could operate entirely client-side on an appropriately supportive
browser would be sensible. But that is taking advantage of the
submittability of forms to achieve reliability. But if the client-side
code has no intention of ever letting the form be submitted if it is
capable of executing I don't see that as indicating that a form should
not be present in the HTML.
I had considered that example, but I would still class that as a
submittable form. Though you might avoid submitting it if at all possible,
the option, for reliability's sake, is still there. This might be avoided
if there are two separate pages - one for server-side, one for client-side
- but surely a hybrid would be more likely (it's simpler).

[snip]
I am not convinced that the HTML specs are going to help much here. They
do describe and specify how a form and its controls are expected to be
handled by a UA in the context of being submitted, they couldn't do
otherwise the specification must specify whatever needs to be
standardised.

The specification also describes the handling of the form controls when
a form is submitted and only leaves two control types (<input
type="button"> and <button type="button">) exclusively for client-side
interaction. So to the extent that it can be argued that FORM is
intended to be submitted and so should not used in contexts where it
will not be submitted, it might also be argued that, for example, SELECT
is also intended to be submitted and should not be used in contexts
where it cannot be.

But while the specification describes how a FORM will be handled when it
is submitted, and requires an action attribute so the UA will know where
to make the request, it does _not_ require that a FORM actually be
submittable. That is, it does not impose a default mechanism for
submission if the form does not contain a control (such as a submit
button, but including others) that can trigger the submission, and it
does not require that such a control be included within the form.

The HTML 4 specification does not impose submittability upon FORM
elements. If it did it probably could be used to override a semantic
interpretation of FORM based on the meaning (dictionary definition) of
the word. As it doesn't I still don't see any reason for considering a
FORM as necessarily other than a container for (multiple, related)
"spaces in which to insert facts or answers".

I can appreciate that in a modern context, form elements could be used
purely as containers, but most of the time, it is unnecessary. If there
were a significant number of controls that needed to be accessed, I would
concede to using a container to make referencing them simpler, and it
would be illogical for me to reject the idea of containing related
controls in form just because it wasn't submitted.

Still, you probably won't see me using a form in solutions to this group
unless the OP used one (this case is an exception as the element wasn't
required at all), or it is obvious that one should be used due to the
close relationship of the controls. Rest assured I won't advise against
them, unless there is some overriding reason to do so (again, this thread
is an example).

Once again, I fall to someone else's opinions, but I do enjoy these little
chats. :)

Mike

--
Michael Winter
M.******@blueyonder.co.invalid (replace ".invalid" with ".uk" to reply)

[Richard Cornford]

"Michael Winter" <M.******@blueyonder.co.invalid> wrote in message
news:op**************@news-text.blueyonder.co.uk...
<snip>

Once again, I fall to someone else's opinions, but I do
enjoy these little chats. :)

Don't give up yet, I am not totally convinced that I am right. I thought
I would get an expert opinion on the semantic aspect of the question so
I posted a question to comp.infosystems.www.authoring.html to see if
they had any consensus of opinion on the subject. (and I suspect that
they will favour submittability, but not necessarily for any good
reason).

Richard.

[Richard Cornford]

"Dr John Stockton" <sp**@merlyn.demon.co.uk> wrote in message
news:ix**************@merlyn.demon.co.uk...
<snip>

Is there some element that can be used instead of <FORM name=XX>
... </form> to give a similar naming structure?
Not with the same built in form/control referencing mechanism. On W3C
DOM browsers, and with a quite a bit more code, any arbitrary (so
probably DIV) container (with an ID attribute) could be used to isolate
a branch in the DOM tree under which all of the controls occurred, using
method such as - getElementsByTagName - and possibly -
getElementsByName - to look up specific descendants and assemble
structures that could be referenced with similar convenience as the
normal form properties.
DIV or SPAN maybe?
I want to be able to use document.Frm1.ZZ & document.Frm2.ZZ, and
F = document.Frm1 ; ...; F.ZZ & F = document.Frm2 ; ... ; F.ZZ, to
refer to two different-but-similar ZZ. I could test, but only in my own browser, whereas I want something
that is known to be at least as good as FORM in all reasonable
browsers (include MSIE 4).
You will not find anything as cross-browser as forms, scripted correctly
they are about as good as it gets. At present, if javascript executes
and the page is HTML then forms are pretty much consistent in all
browsers. Given 3 or 4 years for the dinosaurs to finally die off, the
W3C DOM (most if it at least) will probably achieve the same
reliability.
Pages such as <URL:http://www.merlyn.demon.co.uk/holidays.htm>
are rather reliant on this capability; and it is always good to
minimise global identifiers.

Given the nature of your pages, especially the fact that pages that talk
about javascript while demonstrating it in the viewers browser probably
aren't worth visiting without a javascript capable and enabled browsers,
I don't see that you have any reason to change your existing use of
forms (apart form the point I made in my last personal email to you).

Richard.

[Michael Winter]

On Fri, 13 Feb 2004 07:44:30 -0000, Richard Cornford
<Ri*****@litotes.demon.co.uk> wrote:

"Dr John Stockton" <sp**@merlyn.demon.co.uk> wrote in message
news:ix**************@merlyn.demon.co.uk...
<snip>

Is there some element that can be used instead of <FORM name=XX>
... </form> to give a similar naming structure?

Not with the same built in form/control referencing mechanism. On W3C
DOM browsers, and with a quite a bit more code, any arbitrary (so
probably DIV) container (with an ID attribute) could be used to isolate
a branch in the DOM tree under which all of the controls occurred, using
method such as - getElementsByTagName - and possibly -
getElementsByName - to look up specific descendants and assemble
structures that could be referenced with similar convenience as the
normal form properties.

getElementsByName() is a method of the HTMLDocument interface only.
getElementsByTagName() is a possibility as it is a method of the Element
interface.

Mike

--
Michael Winter
M.******@blueyonder.co.invalid (replace ".invalid" with ".uk" to reply)

[Richard Cornford]

"Michael Winter" <M.******@blueyonder.co.invalid> wrote in message
news:op**************@news-text.blueyonder.co.uk...
<snip>

getElementsByName() is a method of the HTMLDocument interface only.
getElementsByTagName() is a possibility as it is a method of the
Element interface.

Yes, you are right. I can't have been thinking very clearly when I wrote
that. (I was doubtful it would have been much use even if it was
implemented at that point).

Richard.