Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #35815 > unrolled thread

Is there a control for this?

Back to article view | Back to comp.lang.javascript

Contents

  Is there a control for this? dr.j.r.stockton@gmail.com - 2018-11-15 04:43 -0800
    Re: Is there a control for this? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-11-15 15:49 +0000
    Re: Is there a control for this? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2018-11-15 16:51 +0100
      Re: Is there a control for this? dr.j.r.stockton@gmail.com - 2018-11-15 10:17 -0800
        Re: Is there a control for this? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2018-11-15 23:19 +0100
          Re: Is there a control for this? dr.j.r.stockton@gmail.com - 2018-11-16 03:49 -0800
            Re: Is there a control for this? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2018-11-16 12:58 +0100
              Re: Is there a control for this? dr.j.r.stockton@gmail.com - 2018-11-16 10:51 -0800
                Re: Is there a control for this? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2018-11-16 22:33 +0100
                  Re: Is there a control for this? dr.j.r.stockton@gmail.com - 2018-11-17 03:26 -0800
                    Re: Is there a control for this? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2018-11-17 21:59 +0100
                      Re: Is there a control for this? dr.j.r.stockton@gmail.com - 2018-11-18 06:29 -0800
                        Re: Is there a control for this? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-11-18 15:44 +0000
      Re: Is there a control for this? Gloops <gloops@zailes.invalid.org.invalid> - 2018-11-18 10:35 +0100
        Re: Is there a control for this? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2018-11-18 11:32 +0100
          Re: Is there a control for this? Gloops <gloops@zailes.invalid.org.invalid> - 2018-11-29 17:08 +0100
        Re: Is there a control for this? dr.j.r.stockton@gmail.com - 2018-11-18 05:37 -0800
        Re: Is there a control for this? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-11-18 17:13 +0100
          Re: Is there a control for this? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2018-11-18 21:28 +0100
            Re: Is there a control for this? dr.j.r.stockton@gmail.com - 2018-11-19 02:51 -0800

#35815 — Is there a control for this?

I have several controls, to be all alike, and the first has
been upgraded to (with these 3 inputs on ONE line) :-

L
<input type=button value="-" onclick="this.nextSibling.value--;Draw()">
<input name=L type=text size=4 value=13>
<input type=button value="+" onclick="this.previousSibling.value++;Draw()">

One of the effects of Draw() is reading the control.

Is there a better approach nowadays - a single control element,
perhaps?  It must accept typed values in L, and a slider would
either be too long or give insufficient resolution.

FYI, I hope to adjust the above onclicks so that they ALL are
"Nudge(this, Bool)" where Bool means previous or next; or even
make it look both ways for its numeric input control.

-- 
  (c) John Stockton, near London, UK.  Using Google Groups.
 Mail: J.R.""""""""@physics.org - or as Reply-To, if any.

[toc] | [next] | [standalone]

#35816

dr.j.r.stockton@gmail.com writes:

> I have several controls, to be all alike, and the first has
> been upgraded to (with these 3 inputs on ONE line) :-
>
> L
> <input type=button value="-" onclick="this.nextSibling.value--;Draw()">
> <input name=L type=text size=4 value=13>
> <input type=button value="+" onclick="this.previousSibling.value++;Draw()">
>
> One of the effects of Draw() is reading the control.
>
> Is there a better approach nowadays - a single control element,
> perhaps?  It must accept typed values in L, and a slider would
> either be too long or give insufficient resolution.

The HTML5 solution is <input type=number> though it's up to the browser
how that is rendered.  That's not necessarily a negative -- if there's a
good way to alter a number on some platform (maybe with a swipe action)
they you want that to be made available.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#35817

dr.j.r.stockton@gmail.com wrote on 15 Nov 2018 in comp.lang.javascript:

> I have several controls, to be all alike, and the first has
> been upgraded to (with these 3 inputs on ONE line) :-
> 
> L
> <input type=button value="-" onclick="this.nextSibling.value--;Draw()">
> <input name=L type=text size=4 value=13>
> <input type=button value="+" onclick="this.previousSibling.value++;Draw
()">
> One of the effects of Draw() is reading the control.

This only works in modern browsers, 
if the source-code[!] is not split in multiple lines 
in a way that generate empty text nodes, 
and 
I would want to know which node and 
with what value draw() receives,
so try:

======================

<script>
const drawIt = (t) => {
	if (t.value=='+') {
		t.previousSibling.value++;
	} else {
    		t.nextSibling.value--;
	};
    	draw(t);
};
</script>

<input type=button value="-" onclick="drawIt(this);"
><input id='result1' size=4 value=13 readonly
><input type=button value="+" onclick="drawIt(this);">

===========
 
> Is there a better approach nowadays - a single control element,
> perhaps?  It must accept typed values in L, and a slider would
> either be too long or give insufficient resolution.

<input type="number" value="13" step="1" onmouseup="draw(this)">

However, see: <https://caniuse.com/#search=input%20type>
 
> FYI, I hope to adjust the above onclicks so that they ALL are
> "Nudge(this, Bool)" where Bool means previous or next; or even
> make it look both ways for its numeric input control.

See above 



-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#35818

On Thursday, November 15, 2018 at 3:51:45 PM UTC, Evertjan. wrote:
> JRS wrote on 15 Nov 2018 in comp.lang.javascript:
> 
> > I have several controls, to be all alike, and the first has
> > been upgraded to (with these 3 inputs on ONE line) :-
> > 
> > L
> > <input type=button value="-" onclick="this.nextSibling.value--;Draw()">
> > <input name=L type=text size=4 value=13>
> > <input type=button value="+" onclick="this.previousSibling.value++;Draw
> ()">
> > One of the effects of Draw() is reading the control.
> 
> This only works in modern browsers, 
> if the source-code[!] is not split in multiple lines 
> in a way that generate empty text nodes, 

which is why I wrote "on ONE line".

> and 
> I would want to know which node and 
> with what value draw() receives,

Draw takes no arguments; it reads all controls and draws accordingly.
Much safer than trying to change only what is needed, and amply fast
enough even in this old laptop.


> so try:
> 
> ======================
> 
> <script>
> const drawIt = (t) => {
> 	if (t.value=='+') {
> 		t.previousSibling.value++;
> 	} else {
>     		t.nextSibling.value--;
> 	};
>     	draw(t);
> };
> </script>
> 
> <input type=button value="-" onclick="drawIt(this);"
> ><input id='result1' size=4 value=13 readonly
> ><input type=button value="+" onclick="drawIt(this);">

I would have written something similar, but that looks optimal.
> 
> ===========
>  
> > Is there a better approach nowadays - a single control element,
> > perhaps?  It must accept typed values in L, and a slider would
> > either be too long or give insufficient resolution.
> 
> <input type="number" value="13" step="1" onmouseup="draw(this)">

Rem acu tetigisti, as they would write elsewhere; I think I first met it in something by P.G.Wodehouse.

> However, see: <https://caniuse.com/#search=input%20type>

OK in Firefox, though size=4 seems not to work; OK in Vivaldi,
size not tested.  Installed in the page and working in Firefox.

Snag - it seems to go a bit bad with non-integers, first increment is wrong;
it should be type=integer, or debugged.

Thanks, as usual.

-- 
  (c) John Stockton, near London, UK.  Using Google Groups.           |
 Mail: J.R.""""""""@physics.org - or as Reply-To, if any.             |

[toc] | [prev] | [next] | [standalone]

#35819

dr.j.r.stockton@gmail.com wrote on 15 Nov 2018 in comp.lang.javascript:

>> <input type="number" value="13" step="1" onmouseup="draw(this)">
> 
> Rem acu tetigisti, as they would write elsewhere; I think I first met it
> in something by P.G.Wodehouse. 
> 
>> However, see: <https://caniuse.com/#search=input%20type>
> 
> OK in Firefox, though size=4 seems not to work;

Use css styles for width in px, not the old html attribute


-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#35824

On Thursday, November 15, 2018 at 10:19:59 PM UTC, Evertjan. wrote:
> JRS wrote on 15 Nov 2018 in comp.lang.javascript:
> 
> >> <input type="number" value="13" step="1" onmouseup="draw(this)">
> > 
> > Rem acu tetigisti, as they would write elsewhere; I think I first met it
> > in something by P.G.Wodehouse. 
> > 
> >> However, see: <https://caniuse.com/#search=input%20type>
> > 
> > OK in Firefox, though size=4 seems not to work;
> 
> Use css styles for width in px, not the old html attribute

No.  I don't want the width of a text control in px; in this
case I want room for exactly four number characters, monospace
 - the overall width is not important.  I am already using
      .EM4 { width: 4em; }    .

-- 
  (c) John Stockton, near London, UK.  Using Google Groups.           |
 Mail: J.R.""""""""@physics.org - or as Reply-To, if any.

[toc] | [prev] | [next] | [standalone]

#35825

dr.j.r.stockton@gmail.com wrote on 16 Nov 2018 in comp.lang.javascript:

>> Use css styles for width in px, not the old html attribute
> 
> No.  I don't want the width of a text control in px; in this
> case I want room for exactly four number characters, monospace
>  - the overall width is not important.  I am already using
>       .EM4 { width: 4em; }    .

That is, imho, not the task of HTML5 cum CSS3.

Better limit the integer number to -999 to 9999 in JS.



-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#35826

On Friday, November 16, 2018 at 11:58:50 AM UTC, Evertjan. wrote:
> JRS wrote on 16 Nov 2018 in comp.lang.javascript:
> 
> >> Use css styles for width in px, not the old html attribute
> > 
> > No.  I don't want the width of a text control in px; in this
> > case I want room for exactly four number characters, monospace
> >  - the overall width is not important.  I am already using
> >       .EM4 { width: 4em; }    .
> 
> That is, imho, not the task of HTML5 cum CSS3.
> 
> Better limit the integer number to -999 to 9999 in JS.

It's not an integer; it is a percentage inner margin, stepping by 0.5
- but one can type in whatever suits.  A resolution of 0.5% should
serve, 0.1% is the greatest reasonable accuracy.  A negative value
would correspond to printing outside the printer's printable area.
Typically, about 10% would be used, currently.  A floating string,
such as "1e1", can be typed in; but after inc/dec I see 10.5/9.5 .
There is no need to constrain the values, since their effect is
readily enough visible.  Octal is not recognised; hexadecimal is not
understood.

-- 
  (c) John Stockton, near London, UK.  Using Google Groups.           |
 Mail: J.R.""""""""@physics.org - or as Reply-To, if any.             |

[toc] | [prev] | [next] | [standalone]

#35827

dr.j.r.stockton@gmail.com wrote on 16 Nov 2018 in comp.lang.javascript:

> On Friday, November 16, 2018 at 11:58:50 AM UTC, Evertjan. wrote:
>> JRS wrote on 16 Nov 2018 in comp.lang.javascript:
>> 
>> >> Use css styles for width in px, not the old html attribute
>> > 
>> > No.  I don't want the width of a text control in px; in this
>> > case I want room for exactly four number characters, monospace
>> >  - the overall width is not important.  I am already using
>> >       .EM4 { width: 4em; }    .
>> 
>> That is, imho, not the task of HTML5 cum CSS3.
>> 
>> Better limit the integer number to -999 to 9999 in JS.
> 
> It's not an integer; it is a percentage inner margin, stepping by 0.5
> - but one can type in whatever suits.  A resolution of 0.5% should
> serve, 0.1% is the greatest reasonable accuracy.  A negative value
> would correspond to printing outside the printer's printable area.
> Typically, about 10% would be used, currently.  A floating string,
> such as "1e1", can be typed in; but after inc/dec I see 10.5/9.5 .
> There is no need to constrain the values, since their effect is
> readily enough visible.  Octal is not recognised; hexadecimal is not
> understood.

You should write and print numeric values as formatted strings.
Algol taught me that.

Don't be dependend on the quirks of operating systems and browsers.

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#35828

On Friday, November 16, 2018 at 9:33:46 PM UTC, Evertjan. wrote:
> JRS wrote on 16 Nov 2018 in comp.lang.javascript:

> You should write and print numeric values as formatted strings.
> Algol taught me that.

60 or 68?  I knew one of the authors of the Algol 60 Report, and I have a printed copy.  <script type="text/Algol##"> would be nice, if widely implemented.

 
> Don't be dependend on the quirks of operating systems and browsers.

Knowing them means that they can be avoided.


I require this page to be capable of running in Firefox, as
Firefox debugging is best for me.  But, as a bonus, I would
like the page to read and write a file, as an editor does.
Trying  <input type=file  proved a disappointment; that should
have been type=filename (I would not mind needing two identical
copies, one .HTA & one .HTM).

-- 
  (c) John Stockton, near London, UK.  Using Google Groups.
 Mail: J.R.""""""""@physics.org - or as Reply-To, if any.

[toc] | [prev] | [next] | [standalone]

#35829

dr.j.r.stockton@gmail.com wrote on 17 Nov 2018 in comp.lang.javascript:

> On Friday, November 16, 2018 at 9:33:46 PM UTC, Evertjan. wrote:
>> JRS wrote on 16 Nov 2018 in comp.lang.javascript:
> 
>> You should write and print numeric values as formatted strings.
>> Algol taught me that.
> 
> 60 or 68?  I knew one of the authors of the Algol 60 Report, and I have
> a printed copy.  <script type="text/Algol##"> would be nice, if widely
> implemented. 

I don't remember, I only had this booklet about Algol,
and that printing to the screen or to paper were not something default,
but required a command, and that that command needed to specify the string 
type.

After Assembler for 2650, I went to Central Data Basic, written by an 
unknown yough man called William Gates.
 
>> Don't be dependend on the quirks of operating systems and browsers.
> 
> Knowing them means that they can be avoided.

Well cross-browser-wize avoidance if you are using JS is by
having the scripting do the formatting.

> I require this page to be capable of running in Firefox, as
> Firefox debugging is best for me.  But, as a bonus, I would
> like the page to read and write a file, as an editor does.

Does an editor that? Perhaps.

Client-side accessing a file should be and is forbidden for browsers.

You have two options, imho,
as you don't want to change the security-settings of browsers:

1 use serverside files.

2 use a pseudo-file as in HTML Web Storage:

2.1 window.localStorage - stores data with no expiration date.

2.2 window.sessionStorage - stores data for one session.

> Trying  <input type=file  proved a disappointment; 

John, you should get used to disappointments in cyber-life too,
and I am in general unconvinced of such statements of proof.

Yes, I know that that is just semantics, 
but, ever since brexitis broke out,
I am unconvinced such 'just' is justified.

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#35833

On Saturday, November 17, 2018 at 8:59:35 PM UTC, Evertjan. wrote:
> JRS wrote on 17 Nov 2018 in comp.lang.javascript:
> 
> > On Friday, November 16, 2018 at 9:33:46 PM UTC, Evertjan. wrote:
> >> JRS wrote on 16 Nov 2018 in comp.lang.javascript:
> > 
> >> You should write and print numeric values as formatted strings.
> >> Algol taught me that.
> > 
> > 60 or 68?  I knew one of the authors of the Algol 60 Report, and I have
> > a printed copy.  <script type="text/Algol##"> would be nice, if widely
> > implemented. 
> 
> I don't remember, I only had this booklet about Algol,
> and that printing to the screen or to paper were not something default,
> but required a command, and that that command needed to specify the string 
> type.

Algol 60 did not specify the I/O; that was left to the implementation.
ICT/ICL Algol used a different procedure name for I & for O for each
type of variable.  The language was strongly typed, but with only a
small fixed set of types.

I once saw a French "Algol 60" manual in Blackwell's - it was not
standards-compliant, as the reserved words had been translated
into French.  And I once sent off for some Algol 60 FFT code to
study.  The compiler would have liked it; but the variable names
and the extensive comment were in Hungarian.


> Client-side accessing a file should be and is forbidden for browsers.

But that is necessary only if there is a client-server situation;
the use of JavaScript is not restricted to the Web.

I have just started MS IE 11, a sort of browser; I click on what
             <a href="seek.hta"><b>IE : SEEK.HTA</b></a>
displays; I get a new window, in which SEEK.HTA invokes
SEAKFYLE.JS, and that has as much access to the local
system as VBScript has.  SEAKFYLE.JS is run with the JScript
engine.


-- 
  (c) John Stockton, near London, UK.  Using Google Groups.           |
 Mail: J.R.""""""""@physics.org - or as Reply-To, if any.             |

[toc] | [prev] | [next] | [standalone]

#35834

dr.j.r.stockton@gmail.com writes:

> I once saw a French "Algol 60" manual in Blackwell's - it was not
> standards-compliant, as the reserved words had been translated
> into French.

I think that is compliant.  The Report distinguishes between the
reference language, the publication language and what it calls "hardware
representations" of the language.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#35830

On 15th November 2018 at 16:51, Evertjan  wrote :
> <input type=button value="-" onclick="drawIt(this);"
>> <input id='result1' size=4 value=13 readonly
>> <input type=button value="+" onclick="drawIt(this);">
Hello,

You will get this better displayed in a mail/news client inside a PRE 
tag, as it will avoid second and third lines to be considered as quotations.

<pre>
<input type=button value="-" onclick="drawIt(this);"
 ><input id='result1' size=4 value=13 readonly
 ><input type=button value="+" onclick="drawIt(this);">
</pre>


-- 
> (origin in comp.lang.javascript)

-- 
Need another system, not another government.

[toc] | [prev] | [next] | [standalone]

#35831

Gloops <gloops@zailes.invalid.org.invalid> wrote on 18 Nov 2018 in
comp.lang.javascript: 

> On 15th November 2018 at 16:51, Evertjan  wrote :
>> <input type=button value="-" onclick="drawIt(this);"
>>> <input id='result1' size=4 value=13 readonly
>>> <input type=button value="+" onclick="drawIt(this);">
> Hello,
> 
> You will get this better displayed in a mail/news client inside a PRE 
> tag, as it will avoid second and third lines to be considered as
> quotations. 
> 
> <pre>
> <input type=button value="-" onclick="drawIt(this);"
> ><input id='result1' size=4 value=13 readonly
> ><input type=button value="+" onclick="drawIt(this);">
> </pre>

What do you mean by: "considered as quotations" ???
By whom and what would that matter?

Remember: 
<pre> 
is just a shorthand for
<div style='font-family:monospace;white-space: pre;'>


-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#35866

On 18th November 2018 at 11:32, Evertjan  wrote :
> Gloops <gloops@zailes.invalid.org.invalid> wrote on 18 Nov 2018 in
> comp.lang.javascript:
> 
>> On 15th November 2018 at 16:51, Evertjan  wrote :
>>> <input type=button value="-" onclick="drawIt(this);"
>>>> <input id='result1' size=4 value=13 readonly
>>>> <input type=button value="+" onclick="drawIt(this);">
>> Hello,
>>
>> You will get this better displayed in a mail/news client inside a PRE
>> tag, as it will avoid second and third lines to be considered as
>> quotations.
>>
>> <pre>
>> <input type=button value="-" onclick="drawIt(this);"
>>> <input id='result1' size=4 value=13 readonly
>>> <input type=button value="+" onclick="drawIt(this);">
>> </pre>
> 
> What do you mean by: "considered as quotations" ???
> By whom and what would that matter?

Well, nobody special. In a newsgroups, quotation lines begin by ">". The 
display for quotations applies then. To know what you meant it is needed 
to display the source of your message.


> 
> Remember:
> <pre>
> is just a shorthand for
> <div style='font-family:monospace;white-space: pre;'>
> 
> 




-- 
> (origine dans comp.lang.javascript)

--
Besoin d'un autre système, pas d'un autre gouvernement.

[toc] | [prev] | [next] | [standalone]

#35832

On Sunday, November 18, 2018 at 9:35:26 AM UTC, Gloops wrote:
> On 15th November 2018 at 16:51, Evertjan  wrote :
> > <input type=button value="-" onclick="drawIt(this);"
> >> <input id='result1' size=4 value=13 readonly
> >> <input type=button value="+" onclick="drawIt(this);">
> Hello,
> 
> You will get this better displayed in a mail/news client inside a PRE 
> tag, as it will avoid second and third lines to be considered as quotations.

NO.  Standards-compliant newsreaders are intended to display
plain text, and not to understand markups for more ornate
systems.  Attempting to do more frequently amounts to munging.
The over-enthusiasms and deficiencies of your system are your
problem.

 
> <pre>
> <input type=button value="-" onclick="drawIt(this);"
>  ><input id='result1' size=4 value=13 readonly
>  ><input type=button value="+" onclick="drawIt(this);">
> </pre>


-- 
  (c) John Stockton, near London, UK.  Using Google Groups.           |
 Mail: J.R.""""""""@physics.org - or as Reply-To, if any.             |

[toc] | [prev] | [next] | [standalone]

#35835

Gloops wrote on 18.11.2018 10:35:
> On 15th November 2018 at 16:51, Evertjan  wrote :
>> <input type=button value="-" onclick="drawIt(this);"
>>> <input id='result1' size=4 value=13 readonly
>>> <input type=button value="+" onclick="drawIt(this);">
> 
> You will get this better displayed in a mail/news client inside a PRE 
> tag, as it will avoid second and third lines to be considered as quotations.
> 
> <pre>
> <input type=button value="-" onclick="drawIt(this);"
>  ><input id='result1' size=4 value=13 readonly
>  ><input type=button value="+" onclick="drawIt(this);">
> </pre>

As someone who is violating basic rules of conduct for Usenet, you should
be the last person to attempt to lecture others, wrongly, about how the
*plain-text* discussion medium Network News is to be used.

My newsreaders, Mozilla Thunderbird and KNode, do not consider plain tags
at the beginning of a line a quotation (prefix).

<https://www.netmeister.org/news/learn2quote.html>

*You* have mangled the original text instead, probably in using the “Rewrap”
feature wrongly.

Note also that thunderbird=1:60.3.0-1~deb8u1_amd64 is buggy: the KDE 4 color
scheme is no longer observed, and crossposting no longer worked (claiming I
could not post to several newsservers at once although I only have the
target group subscribed on one server); the latter is why I downgraded to
thunderbird=1:52.8.0-1~deb8u1_amd64 today.

-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#35836

Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote on 18 Nov 2018 in 
comp.lang.javascript:

"><input id='result1'"

This "><" in the html code line
was ment by me to prevent text-node insertion
while keeping the linee short enough 
for Usenet newsreader implementations.

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#35837

On Sunday, November 18, 2018 at 8:28:13 PM UTC, Evertjan. wrote:
> Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote on 18 Nov 2018 in 
> comp.lang.javascript:
> 
> "><input id='result1'"
> 
> This "><" in the html code line
> was ment by me to prevent text-node insertion
> while keeping the linee short enough 
> for Usenet newsreader implementations.

Manifestly.  But the code was presented to be read, not for
execution, so I maximised readability by splitting the line
and saying that I had done so.

Ben : that explains it.  Though I did not like the
translation of "go to", which would have been apt for "to go".


-- 
  (c) John Stockton, near London, UK.  Using Google Groups.
 Mail: J.R.""""""""@physics.org - or as Reply-To, if any.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web