Form won't validate without action/method?

Discussion in 'Javascript' started by Pete, Feb 11, 2004.

  1. Pete

    Pete Guest

    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.
     
    Pete, Feb 11, 2004
    #1
    1. Advertising

  2. Pete

    McKirahan Guest

    "Pete" <> wrote in message
    news:...
    > 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">
     
    McKirahan, Feb 11, 2004
    #2
    1. Advertising

  3. On 10 Feb 2004 20:27:22 -0800, Pete <>
    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
    d (replace ".invalid" with ".uk" to reply)
     
    Michael Winter, Feb 11, 2004
    #3
  4. "Michael Winter" <> wrote in message
    news:eek:...
    <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.
     
    Richard Cornford, Feb 11, 2004
    #4
  5. On Wed, 11 Feb 2004 16:16:34 -0000, Richard Cornford
    <> wrote:

    > "Michael Winter" <> wrote in message
    > news:eek:...
    > <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
    d (replace ".invalid" with ".uk" to reply)
     
    Michael Winter, Feb 11, 2004
    #5
  6. "Michael Winter" <> wrote in message
    news:eek:...
    <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.
     
    Richard Cornford, Feb 11, 2004
    #6
  7. On Wed, 11 Feb 2004 19:02:39 -0000, Richard Cornford
    <> wrote:

    > "Michael Winter" <> wrote in message
    > news:eek:...
    > <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
    d (replace ".invalid" with ".uk" to reply)
     
    Michael Winter, Feb 11, 2004
    #7
  8. "Michael Winter" <> wrote in message
    news:eek:...
    <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.
     
    Richard Cornford, Feb 11, 2004
    #8
  9. On Wed, 11 Feb 2004 20:35:46 -0000, Richard Cornford
    <> wrote:

    > "Michael Winter" <> wrote in message
    > news:eek:...
    > <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
    d (replace ".invalid" with ".uk" to reply)
     
    Michael Winter, Feb 11, 2004
    #9
  10. Pete

    Pete Guest

    Michael Winter <> wrote in message news:<>...
    > On 10 Feb 2004 20:27:22 -0800, Pete <>
    > 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.grigg/javascript/worldclock.html

    Pete.
     
    Pete, Feb 11, 2004
    #10
  11. On 11 Feb 2004 15:02:31 -0800, Pete <>
    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
    d (replace ".invalid" with ".uk" to reply)
     
    Michael Winter, Feb 12, 2004
    #11
  12. JRS: In article <c0dkh3$afs$1$>, seen in
    news:comp.lang.javascript, Richard Cornford
    <> 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, Feb 12, 2004
    #12
  13. JRS: In article <>, seen in
    news:comp.lang.javascript, Michael Winter <
    d> posted at Thu, 12 Feb 2004 00:00:48 :-
    >On 11 Feb 2004 15:02:31 -0800, Pete <>
    >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.
     
    Dr John Stockton, Feb 12, 2004
    #13
  14. "Michael Winter" <> wrote in message
    news:eek:...
    <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.
     
    Richard Cornford, Feb 12, 2004
    #14
  15. Michael Winter <> writes:

    > On 11 Feb 2004 15:02:31 -0800, Pete
    > <> 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/software/isodates/isocontents.html
    "ISO 8601 Dates: What They Are and Why They're Good".)

    --
    Chris Jeris Apply (1 6 2 4)(3 7) to domain to reply.
     
    Christopher Jeris, Feb 12, 2004
    #15
  16. On Thu, 12 Feb 2004 15:13:41 -0000, Richard Cornford
    <> 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
    d (replace ".invalid" with ".uk" to reply)
     
    Michael Winter, Feb 12, 2004
    #16
  17. "Michael Winter" <> wrote in message
    news:eek:...
    <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, Feb 13, 2004
    #17
  18. "Dr John Stockton" <> wrote in message
    news:...
    <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.
     
    Richard Cornford, Feb 13, 2004
    #18
  19. On Fri, 13 Feb 2004 07:44:30 -0000, Richard Cornford
    <> wrote:

    > "Dr John Stockton" <> wrote in message
    > news:...
    > <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
    d (replace ".invalid" with ".uk" to reply)
     
    Michael Winter, Feb 13, 2004
    #19
  20. "Michael Winter" <> wrote in message
    news:eek:...
    <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.
     
    Richard Cornford, Feb 13, 2004
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Joe Bloggs
    Replies:
    1
    Views:
    800
    Sudsy
    Aug 3, 2003
  2. rjweytens
    Replies:
    6
    Views:
    16,107
    rjweytens
    Jun 25, 2004
  3. runescience

    Struts mapping action to action???

    runescience, Feb 6, 2006, in forum: Java
    Replies:
    3
    Views:
    1,833
    runescience
    Feb 7, 2006
  4. ramakrishna
    Replies:
    1
    Views:
    5,454
    Babu Kalakrishnan
    Sep 13, 2006
  5. John
    Replies:
    0
    Views:
    888
Loading...

Share This Page