Paul Lautman wrote:
Randy Webb wrote:
>Paul Lautman said the following on 7/5/2006 3:44 PM:
<snip>
>>Something like this:
Not, not "something like this". Why try to hide/show
a textbox and rearrange the flow of the page, or leave
it blank, instead of modifying the readOnly attribute....
Go stick your head in a pig! ... apart from showing how
rude you can be.
For future reference a far better post would have been
along the lines of:
################################################## #####
Or closer to what the OP asked for, you could put:
<input type="checkbox" id="b1" onclick="javascript:if
In javascript syntax the - javascript
: - at the beginning of the onclick
attribute value represents a label, but as no - break - or continue -
statements (labelled or otherwise) appear in the code any label is
redundant. Microsoft have decided to use this construct to indicate
which scripting language should be used to interpret the intrinsic event
attribute value, but when used in this way no label exists in the
resulting code. The practical result of this is that - javascirpt: - is
dangerous to use as a label in an intrinsic event attribute value
because it will not be seen as such by IE browsers. However, as IE
browsers default to interpreting intrinsic event attributes as JScript
unless action is taken to change the default scripting language for a
page (i.e. another language is employed on the page first) there is
generally no point in attempting to express to IE that it needs to
interpret an intrinsic event attribute value in any special way.
(this.checked) {getElementById('i1').readOnly = false;} else
Using the unqualified Identifier - getElementById - in the value of an
intrinsic event handling attribute can only be successful in
environments where the - document - object is on the resulting
internally generated function's scope chain. This can only be the case
if the scope chains of such functions are explicitly augmented by the
browser. While it is not uncommon, such augmentation is not specified in
any standard, and so not required (so should not be expected outside of
known environments) and unlikely to be consistent where it is
implemented. In reality there a browsers that do not undertake such
augmentation and browsers that do but do not include the - document -
object on such scope chains. Thus using such an unqualified Identifier
will guarantee otherwise avoidable script failure in some environments;
it is non-reliable code used where a considerably more reliable
alternative is trivially available.
However, when form controls appear in a form element that is intended to
submit data to a server a reference from one intrinsic event handling
attribute value to another control in the same form is most reliably
achieved using the first control's - form - property, the elements -
collection of that form and the name of the control that is being
referenced:-
this.form.elements['otherFieldName']
{getElementById('i1').readOnly = true;}"/>
Testing a boolean value in order to branch into the assignment of one of
two boolean values is needlessly indirect. The same could be achieved
with:-
getElementById('i1').readOnly = !this.checked;
- or:-
this.form.elements['otherFieldName'].readOnly = !this.checked;
<input type="text" id="i1" READONLY/>
The penultimate slash above implies an attempt to write XHTML, but this
cannot be the case as XHTML uses case sensitive attribute names and the
read only attribute in XHTML is all lower case (and should be written
readonly="readonly"). In SGML such a penultimate slash (SGML application
languages where the SGML declaration asserts SHORTTAG YES (as is the
case with HTML 4)) changes the interpretation of the above into:-
<input type="text" id="i1" READONLY>>
(implying a text chevron following the element).
Few browsers actually follow this requirement of SGML parsing when
interpreting HTML documents, ignoring the slash instead, but that does
not mean that it is a good idea to include such constructs in documents
that are expected to be interpreted as HTML. Doing so is likely to
introduce confusion in the minds of human readers as to which type of
mark-up is being employed (and in our context, which type of DOM is
being scripted as a result) and it will force an HTML browser to engage
in error-correction while interpreting the document (with potentially
inconstant results and inevitable overheads).
################################################## ######
Overall this design pattern promotes unreliable outcomes (regardless of
which property is used to 'disable' the field). We are dealing with a
minor GUI enhancement and it doesn't really matter if the ability to
enable/disable the field on the client is available as the server code
should be set up to ignore anything entered into the potentially
disabled field if the corresponding checkbox is not checked.
Enabling/disabling the field on the client just makes it more apparent
to the user that the checkbox selection relates to the field.
If the HTML loads with the field readonly, disabled or hidden and
client-side scripting is not capable of rendering it non-readonly,
enabled or visible then the field will remain unavailable to the user
even if the checkbox is checked, potentially rendering the entire form
non-viable as a mechanism for entering the required data. This is a bad
design choice, and potentially costly if the purpose of the form is
ultimately to enable the user to hand over their money.
A better strategy would load the form in a fully usable state and then
have a script render the field readonly, disabled or hidden (either
onload or following the parsing of the form element). This has the
advantage that whenever the script could not enable the field it will
also not be able to disable it with this initial action. The ability to
initially render the field unavailable implies the symmetrical ability
to later make it available again in response to interaction with the
checkbox, but when the script fails to initially act on the field the
result will not be an unusable form.
Note how much more helpful such a post is.
7% more helpful would be my judgement, but then I would consider the
overall effect about 75% harmful because of the issues I have enumerated
above.
Richard.
