Checkboxs

**Michael Winter** · Jul 23 '05, 02:44 PM

Re: Checkboxs

On Sun, 17 Oct 2004 09:09:53 +0000 (UTC), Oli <oli@NOSPAMoliw oods.co.uk>
wrote:
[color=blue]
> I have a form with a textbox...
>
> <input type="text" name="textbox1" value="value1" disabled>[/color]

Might I suggest that you don't start with that HTML. If the user doesn't
have scripting enabled, the field will be completely useless. Instead,
disable the field once the page has loaded. In this case, if the user
agent cannot execute the script, the user can still enter a value. It's
then a matter of checking on the server that the checkbox is checked. If
it isn't, you might want to warn the user to make sure that's what they
didn't forget to check the box by accident.

Might I also suggest that you use better names for your elements;
"textbox1" isn't very informative.
[color=blue]
> Obviously that produces a textbox that the user cannot edit.
>
> What I want is when the user puts a tick in a checkbox next to the
> textbox for the textbox to become active.
>
> I know it's possible, but how?![/color]

function disable(elem, bool) {
elem.disabled = bool;
}

/* Disable the text box when the document loads. */
function initForm() {
disable(documen t.forms['myForm'].elements['textbox1'], true);
}

<body onload="initFor m();">



<input type="checkbox"
onchange="disab le(this.form.el ements['textbox1'], !this.checked); ">
<input type="text" name="textbox1" >

Hope that helps,
Mike

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.

**johkar** · Jul 23 '05, 02:44 PM

Re: Checkboxs

There are a variety of ways to do it depending on browsers, but this is one
would work on most. For even further browser support, "this" could be
replaced by 'checkbox1' and then replace elm.checked. with
document.myForm .elements(elm). checked

<script language="javas cript" type="text/javascript">
function setTextbox(elm, tobox){
if(elm.checked)
document.myForm .elements(tobox ).disabled=fals e;
else
document.myForm .elements(tobox ).disabled=true ;
}
</script>
<form name="myForm" method="post" action="">
<input type="text" name="textfield 1" id="textfield1 " value="value1"
disabled="disab led" />
<input type="checkbox" name="checkbox1 " id="checkbox1" value="checkbox "
onclick="setTex tbox(this,'text field1')" />
</form>

John

"Oli" <oli@NOSPAMoliw oods.co.uk> wrote in message
news:cktct1$gat $1@titan.btinte rnet.com...[color=blue]
> Hi,
>
> I have a form with a textbox...
>
> <input type="text" name="textbox1" value="value1" disabled>
>
> Obviously that produces a textbox that the user cannot edit.
>
> What I want is when the user puts a tick in a checkbox next to the textbox
> for the textbox to become active.
>
> I know it's possible, but how?!
>
> TIA
> Oli
>
>[/color]

**Michael Winter** · Jul 23 '05, 02:44 PM

Re: Checkboxs

On Sun, 17 Oct 2004 10:45:05 -0500, johkar <nosendjunk@msn .com> wrote:

[snip]
[color=blue]
> document.myForm .elements(elm). checked[/color]

Subscripting collections with parentheses is a Microsoft-ism. Whilst some
browsers do support it, merely as a compatibility feature, others - most
notably Mozilla - won't. Instead, use square brackets, which is the
correct, standardised method.

A minor point: you could use the forms collection in addition to elements:

document.forms['myForm'].elements[elm].checked
[color=blue]
> <script language="javas cript" type="text/javascript">[/color]

The language attribute is deprecated, and the (required) type attribute
makes it redundant anyway. Remove it.
[color=blue]
> function setTextbox(elm, tobox){
> if(elm.checked)
> document.myForm .elements(tobox ).disabled=fals e;
> else
> document.myForm .elements(tobox ).disabled=true ;[/color]

Along with the previous comments, you could simplify that to:

document.forms['myForm'].elements[elm].disable = !elm.checked;
[color=blue]
> }
> </script>
> <form name="myForm" method="post" action="">
> <input type="text" name="textfield 1" id="textfield1 " value="value1"
> disabled="disab led" />[/color]

Two points here:

1) It's generally a bad idea to disable a control via HTML. It makes the
form unusable to a visitor with Javascript unavailable.
2) Unless you're writing XHTML, which I doubt, don't include the slash at
the end of the tag. It makes what would otherwise be valid documents,
invalid for no reason.
[color=blue]
> <input type="checkbox" name="checkbox1 " id="checkbox1"
> value="checkbox " onclick="setTex tbox(this,'text field1')" />
> </form>[/color]

[snip]

Finally, please don't top-post.

Mike

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.

**johkar** · Jul 23 '05, 02:45 PM

Re: Checkboxs

[snip]
[color=blue]
>
> Two points here:
>
> 1) It's generally a bad idea to disable a control via HTML. It makes the
> form unusable to a visitor with Javascript unavailable.
> 2) Unless you're writing XHTML, which I doubt, don't include the slash at
> the end of the tag. It makes what would otherwise be valid documents,
> invalid for no reason.
>[color=green]
> > <input type="checkbox" name="checkbox1 " id="checkbox1"
> > value="checkbox " onclick="setTex tbox(this,'text field1')" />
> > </form>[/color]
> Mike
>
> --
> Michael Winter
> Replace ".invalid" with ".uk" to reply by e-mail.[/color]

Point taken on the brackets. Enlighten me once more. Ending slashes on
inputs and such ala XHTML would cause errors in which browsers? I wasn't
aware of any, though you seem to be the expert.

John

**Richard Cornford** · Jul 23 '05, 02:45 PM

Re: Checkboxs

johkar wrote:[color=blue][color=green]
>> Michael Winter[/color]
><snip>[color=green]
>> 2) Unless you're writing XHTML, which I doubt, don't include
>> the slash at the end of the tag. It makes what would otherwise
>> be valid documents, invalid for no reason.[/color][/color]
<snip>[color=blue]
> Point taken on the brackets. Enlighten me once more. Ending
> slashes on inputs and such ala XHTML would cause errors in which
> browsers? I wasn't aware of any, though you seem to be the
> expert.[/color]

They don't cause errors, they are errors. They force the browser to put
in extra work error-correcting them.

In SGML they have formal meaning, but it isn't a meaning that
corresponds with what you expect them to do, and HTML web browsers
disregard that formal meaning anyway and just treat them as errors.

Richard.

**johkar** · Jul 23 '05, 02:45 PM

Re: Checkboxs

Re: Checkboxs
From: Richard Cornford
Date Posted: 10/17/2004 9:23:00 PM

johkar wrote:[color=blue][color=green]
>> Michael Winter[/color]
><snip>[color=green]
>> 2) Unless you're writing XHTML, which I doubt, don't include
>> the slash at the end of the tag. It makes what would otherwise
>> be valid documents, invalid for no reason.[/color][/color]
<snip>[color=blue]
> Point taken on the brackets. Enlighten me once more. Ending
> slashes on inputs and such ala XHTML would cause errors in which
> browsers? I wasn't aware of any, though you seem to be the
> expert.[/color]

They don't cause errors, they are errors. They force the browser to put
in extra work error-correcting them.

In SGML they have formal meaning, but it isn't a meaning that
corresponds with what you expect them to do, and HTML web browsers
disregard that formal meaning anyway and just treat them as errors.

Richard.

Ok, I understand XHTML replaces HTML 4; and also understand most browsers
don't truly support it yet...or treat it like HTML if you leave off the
declaration. So assume they did, would you not use XHTML ever? I am just
trying to understand when to use it. Are all the experts behind the Web
Standards Project wrong? http://www.webstandards.org/

John

**Michael Winter** · Jul 23 '05, 02:46 PM

Re: Checkboxs

On Mon, 18 Oct 2004 05:52:46 -0500, johkar <nosendjunk@msn .com> wrote:
[color=blue]
> Re: Checkboxs
> From: Richard Cornford
> Date Posted: 10/17/2004 9:23:00 PM[/color]

At present it appears that either your news reader is broken, or you've
disabled normal quoting when replying. I'm not going to force the issue,
but it would be nice for you to reply properly, resulting in properly
threaded, and quoted, posts.

[snip]
[color=blue]
> Ok, I understand XHTML replaces HTML 4;[/color]

I don't know about "replaces". It is the next in line, but with IE
(unfortunately holding the largest market share) unable to properly
support XHTML, I fail to see the point of using it. As I understand it, it
will be impossible to have IE parse the page without invoking quirks-mode,
because the mark-up will be treated as malformed HTML.
[color=blue]
> and also understand most browsers don't truly support it yet[/color]

I was under that impression that modern browsers did, but they are
outnumbered by IE which doesn't.
[color=blue]
> ...or treat it like HTML if you leave off the declaration.[/color]

More importantly, as I already said, they treat it as malformed HTML. That
seems to me to be a step backward.
[color=blue]
> So assume they did, would you not use XHTML ever?[/color]

"Not ever" is too strong, but I personally won't use it for quite a long
time. All browsers can handle Strict HTML, which is probably better for
the moment than Strict XHTML.
[color=blue]
> I am just trying to understand when to use it.[/color]

I couldn't honestly say when a good time to switch over would come. I
suppose it's like writing for browsers like NN4, now. Is it really worth
it? Some argue yes, others no. When (if) the same situation occurs with
XHTML - that the number of people that will use error-corrected HTML,
rather than XHTML, drops to a vast minority - then I'd consider using it.
[color=blue]
> Are all the experts behind the Web Standards Project wrong?
> http://www.webstandards.org/[/color]

I think perhaps your interpretation is. From a quick look around, I see
nothing that says, "Abandon HTML! You must switch to XHTML or the Web is
doomed!"

The main aim of the organisation is to promote the use of Web-related
standards. HTML is just as big a part of those standards as any of the
other technologies and, if used properly, it will achieve the intended
goals just as well: forward compatibility, accessibility, and the
separation of presentation and content.

The important point is that you write semantically correct, valid mark-up,
and that you don't intentionally hinder the accessibility of your work. I
think the reason why XHTML is proclaimed as the way forward is that, in
theory, it enforces the former. However, that would only hold true if user
agents strictly conform to parsing rules, intentionally breaking
badly-written documents. From what I've read elsewhere, this isn't
happening meaning that malformed XHTML is likely to be published just like
HTML.

Mike

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.

Checkboxs

Checkboxs

Comment

Comment

Comment

Comment

Comment

Comment

Comment