Loading into TEXTAREA skips lines ?

[David]

Hi,

I have a simple form which uses the following code to add lines into a
textarea field from a button
The problem is that it always seems to begin on the 3rd line, i.e.
skips line 1 & 2 in the textarea box

I would like it to start at line 1, how can I adjust the code to do
this ?


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

<SCRIPT language="JavaScript">
<!--
function addItem(){

var Unit = document.schedule.schedule_update.value
if (Unit=='')
{Unit += document.formname.quantity.value + " x "
+document.formname.list2.value}
else
{Unit += '\n' + document.formname.quantity.value + " x " +
document.formname.list2.value}
document.schedule.schedule_update.value = Unit
}

//-->
</SCRIPT>


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


Many thanks

David

 

[news]

Hi,

I have a simple form which uses the following code to add lines into a
textarea field from a button
The problem is that it always seems to begin on the 3rd line, i.e.
skips line 1 & 2 in the textarea box

You haven't provided any HTML, so my guess is that just that,
a guess, but... I'd guess your markup has the TextArea element
defined with whitespace before the closing tag. Your javascript is
testing
to see if the textarea's value is empty, but it isn't, so it's
adding an extra newline character before adding your text.

I would like it to start at line 1, how can I adjust the code to do
this ?

<!--

Don't use HTML comments in scripts. At best they do nothing, at
worst they'll prevent your script executing.

[rest of function snipped - it's not pretty, but it works]

document.formname.quantity.value

Do you really have a form called "formname"? Each to his own I suppose

Mike

 

[Lee]

David said:

Hi,

I have a simple form which uses the following code to add lines into a
textarea field from a button
The problem is that it always seems to begin on the 3rd line, i.e.
skips line 1 & 2 in the textarea box

I would like it to start at line 1, how can I adjust the code to do
this ?


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

<SCRIPT language="JavaScript">
<!--
function addItem(){

var Unit = document.schedule.schedule_update.value
if (Unit=='')
{Unit += document.formname.quantity.value + " x "
+document.formname.list2.value}
else
{Unit += '\n' + document.formname.quantity.value + " x " +
document.formname.list2.value}
document.schedule.schedule_update.value = Unit
}

//-->
</SCRIPT>

The code as written (in the 1990's, I would guess) will:
If there is no text in the text box, insert the new text.
If there is text in the text box, insert a NEWLINE and
then append the new text.
It doesn't skip anything.
What do you want it to do in each of those two cases?


--

 

[Thomas 'PointedEars' Lahn]

Use <script type="text\javascript">

Correct is

<script type="text/javascript">

(This is the Internet, not Micro$~1 Windows.)

Do you really have a form called "formname"? Each to his own I suppose

The above should read

document.forms["formname"].elements["quantity"].value

to be both standards compliant and backwards compatible.


PointedEars

 

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn said the following on 9/25/2007 12:49 PM:

According to the W3C Validator, it is.

The W3C Validator uses an SGML or XML parser that can only validate a
document resource against a DTD, and the (X)HTML (4.01/1.x) DTDs only
specify the attribute value to be CDATA (which is fulfilled here):

http://www.w3.org/TR/html401/sgml/loosedtd.html
http://www.w3.org/TR/html401/sgml/framesetdtd.html
http://www.w3.org/TR/html401/sgml/dtd.html
(search for "ELEMENT SCRIPT")

http://www.w3.org/TR/xhtml1/dtds.html#dtdentry_xhtml1-transitional.dtd_script
http://www.w3.org/TR/xhtml1/dtds.html#dtdentry_xhtml1-frameset.dtd_script
http://www.w3.org/TR/xhtml1/dtds.html#dtdentry_xhtml1-strict.dtd_script

http://www.w3.org/TR/2001/REC-xhtml11-20010531/xhtml11_dtd.html#a_xhtml11_dtd
(search for "Scripting Module")
http://www.w3.org/TR/xhtml-modularization/dtd_module_defs.html#a_module_Scripting

I would still consider it not recognizing a violation of the basic media
type syntax a bug, and the further checking against that syntax well-defined
in RFC 2054, subsection 5.1, should be reported as a request for enhancement:

http://validator.w3.org/feedback.html

According to any standards that define MIME Types for the script
element it isn't correct.
Exactly.

document.formname.quantity.value
Do you really have a form called "formname"? Each to his own I suppose

The above should read

document.forms["formname"].elements["quantity"].value

to be both standards compliant and backwards compatible.

Nonsense.

It is _not_ nonsense. (As you should know already,) W3C DOM Level 2 HTML
also specifies the ECMAScript binding for the interfaces defined there:

http://www.w3.org/TR/DOM-Level-2-HTML/ecma-script-binding.html

And the object that implements the HTMLDocument interface in conforming
implementations can be currently referred to with `document' or
`window.document' in all relevant DOM implementations.

(As you also should know already,) this referencing of items of a collection
or node list (with bracket property accessor syntax) is supported since DOM
Level 0 (IE3/NN3):

http://msdn2.microsoft.com/en-us/library/ms531073.aspx
http://research.nihonsoft.org/javascript/jsref/doc1.htm#1010814
http://hal.ific.uv.es/informatica/manuales/ClientReferenceJS13/document.html#1193750


PointedEars

 

[news]

Correct is

<script type="text/javascript">

(This is the Internet, not Micro$~1 Windows.)

Oops. Typo. I switch between OS's so often I have to
think long and hard which slash is which. Call it
path dyslexia. Sad, isn't it?

Mike

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]>,

The *only* time bracket notation is preferred over dot notation is if
the identifier has certain characters in it. It has nothing to do with
"standards compliant" and it sure as Hades has nothing to do with
"backwards compatibility".

Bracket notation is required if the name contains characters
incompatible with dot notation, AND if the name needs to be computed at
run time rather than being supplied at write time. See FAQ notes.

You can prefer it whenever you like.

Personally, I'd use dot notation whenever practical (which does not
include using eval to make it possible.

 

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn said the following on 9/25/2007 1:48 PM:

<snipped lots of URL's I don't care about>

You better should care about them as they also prove your following
statements wrong.

I was referring to your supposition that the only acceptable script
element was with a type attribute that, as you know, has no
defined/standardized MIME types for it.

If I knew that, I would know nonsense.

http://PointedEars.de/scripts/test/mime-types

The only one acceptable is "text/javascript"

It is the only one currently *feasible* for ECMAScript-conforming scripting
in (X)HTML on the Web. It is not the only one acceptable. In SVG, for
example, that value should be "text/ecmascript". (I might add that to the
aforementioned test case.)

and, unless you name your phantom UA, the only thing that complains
about it is the W3C Validator.

And that "Exactly" is because, as you are well aware, there are *no*
*defined* MIME types for the type attribute for a script element.

Utter nonsense. All media types denoting a script language would be valid.
They don't even have to be registered, as long as the syntax for media type
identifiers as referred to by the (X)HTML standard(s) is followed.

document.formname.quantity.value
Do you really have a form called "formname"? Each to his own I suppose
The above should read

document.forms["formname"].elements["quantity"].value

to be both standards compliant and backwards compatible.
Nonsense.

It is _not_ nonsense. (As you should know already,) W3C DOM Level 2 HTML
also specifies the ECMAScript binding for the interfaces defined there:

http://www.w3.org/TR/DOM-Level-2-HTML/ecma-script-binding.html

And as you should know already, I won't repeat my opinion of a bunch of
useless worthless text on a webpage.

It is not some "web page", it is a normative document from a Web standard.

The *only* time bracket notation is preferred over dot notation is if
the identifier has certain characters in it. It has nothing to do with
"standards compliant"

Yes, it has. The item() and namedItem() methods of objects implementing the
HTMLCollection interface are to be triggered through the bracket property
accessor syntax. That for identifiers this works, too, in some UAs, is
proprietary behavior due to the need for backwards-compatibility there.

and it sure as Hades has nothing to do with "backwards compatibility".

It has a lot to do with it. The bracket property accessor syntax that is
required when following the standard published later *also* works with
script engines that were released before that do not differentiate between
the language and the DOM, as it was until including JavaScript 1.3.


PointedEars

 

[Thomas 'PointedEars' Lahn]

Yes, it has. The item() and namedItem() methods of objects implementing the
HTMLCollection interface are to be triggered through the bracket property
accessor syntax. That for identifiers this works, too, in some UAs, is
proprietary behavior due to the need for backwards-compatibility there.

Should have been:

"That for the dot property accessor syntax and identifiers this
works, too, in some UAs, is proprietary behavior due to the need
for backwards-compatibility there."


PointedEars