Oh Boy...More Brower Weirdness!!!

P

Prisoner at War

So now my nice little onMouseOver and onMouseOut is being refused by
both Opera 9 and MSIE 7 -- the nerve!!

Firefox 2 has no problems with the following, though, which seems
pretty straight-forward to me...

<img src="something.jpg" id="test"
onMouseOver="window.document.test.src='nothing.jpg';"
onMouseOut="window.document.test.src='something.jpg';"/>


Thanks, people!
 
E

Evertjan.

Prisoner at War wrote on 12 apr 2008 in comp.lang.javascript:
So now my nice little onMouseOver and onMouseOut is being refused by
both Opera 9 and MSIE 7 -- the nerve!!

Firefox 2 has no problems with the following, though, which seems
pretty straight-forward to me...

It does not to me.
<img src="something.jpg" id="test"
onMouseOver="window.document.test.src='nothing.jpg';"
onMouseOut="window.document.test.src='something.jpg';"/>

window. is default.

Do not assume the id to be crossbrowser available like above, but do:

document.getElememtById('test').src = '...'
Thanks, people!

Easier yet, do:

<img src="something.jpg"
onMouseOver = "this.src='nothing.jpg';"
onMouseOut = "this.src='something.jpg';">

In many browsers, you can even do:

<img src="something.jpg"
onMouseOver = "this.old=this.src;this.src='nothing.jpg';"
onMouseOut = "this.src=this.old;">
 
P

Prisoner at War

It does not to me.

Eh?? I got it straight out of "The Book of JavaScript, Second
Edition" (2007), by David Thau...he does a couple of silly things like
use "window.document.write()" through the first seventy or so pages
and then tells readers to drop the "window.document" part, but why
shouldn't the full "window.document.id.src" work?
window. is default.

Do not assume the id to be crossbrowser available like above, but do:

HEY!!!!!

IT WORKS!!!!!

THAT WAS THE PROBLEM -- the id attribute was not understood by Opera
and MSIE!!

What the hell?!?! I thought it was advised to be XHTML-
compliant...that XHTML is going to replace HTML...can't believe the
latest versions of those two browsers don't recognize the id attribute
in an said:
document.getElememtById('test').src = '...'

Eh?? So there are many ways of calling an image, huh....
Easier yet, do:

<img src="something.jpg"
onMouseOver = "this.src='nothing.jpg';"
onMouseOut = "this.src='something.jpg';">

THAT WORKS!!! THANKS!!!!
In many browsers, you can even do:

<img src="something.jpg"
onMouseOver = "this.old=this.src;this.src='nothing.jpg';"
onMouseOut = "this.src=this.old;">

Hmmm...perhaps I'll give that a try, too....
 
E

Evertjan.

Prisoner at War wrote on 12 apr 2008 in comp.lang.javascript:
but why
shouldn't the full "window.document.id.src" work?

It should not! It is one of those silly MS ideas,
but MS started out to allow:
document.name.src
which is nearly just as wrong.

===

<img name = 'myImage' id = 'imageId' src = ''>

Which one should work, or both?

document.myImage.src
document.imageId.src

===

No, an element should be called as a javascript 'object' by:

var imageId = document.getElementById('imageId')
or
var myImage0 = document.getElementsByName('myImage')[0]

Less good in my view is:
document.images['myImage']
document.images.myImage
because the name could point to a collection.

===

if 'this' is possible, it is just as nice,
[not tested]:

==========================================
<img src="something.jpg"
onMouseOver = "toggleImg(this,'nothing.jpg');"
onMouseOut = "toggleImg(this,'');">

<img src="somethingElse.jpg"
onMouseOver = "toggleImg(this,'nothingElse.jpg');"
onMouseOut = "toggleImg(this,'');">

<script type='text/javascript'>
function toggleImg(imPointer,img2){
if (img2) {
imPointer.old = imPointer.src;
imPointer.src = img2;
} else {
imPointer.src = imPointer.old;
};
};
</script>
==========================================
 
L

Lasse Reichstein Nielsen

Prisoner at War said:
Eh?? I got it straight out of "The Book of JavaScript, Second
Edition" (2007), by David Thau...

So, the book contains bad practices. That's the case for most
Javascript books.
he does a couple of silly things like
use "window.document.write()" through the first seventy or so pages
and then tells readers to drop the "window.document" part,

Hopefully only drop the "window" part. The "document" is necessary.
but why shouldn't the full "window.document.id.src" work?

Because there is no reason to believe it should, except that *some*
browsers have chosen to create properties on the document object
(and some on the window object) that refers to elements with an id
attribute.

No standard requires it, though.
HEY!!!!!

IT WORKS!!!!!

Whaddayaknow. Maybe Evertjan knows better than the book author. :)
THAT WAS THE PROBLEM -- the id attribute was not understood by Opera
and MSIE!!
What the hell?!?! I thought it was advised to be XHTML-
compliant...

Not really. XHTML is not necessary for any current browser, and indeed
many current browser doesn't even understand it correctly (they just
treat it as HTML with errors).
that XHTML is going to replace HTML...

Unlikely in the short run, and personally I expect something else to
replace both before that happens.

XHTML is not necessary, in the sense that there is no present need
that it fullfils better than HTML. On the other hand, it is harder
to write and has worse browser support.
If there was an advantage to XHTML, then maybe it would have a
future, but I can see non. Easing server side page manipulation is
not an advantage, as it's trivial to convert to HTML before sending
it to a browser.
can't believe the
latest versions of those two browsers don't recognize the id attribute
in an <img> tag....

Sure they do. Otherwise the getElementBy*Id* method wouldn't have found
the image element.

They just don't recognize that "document.test" should refer to the element
with id "test".
Eh?? So there are many ways of calling an image, huh....

There are several ways to refer to an image element in the document
DOM structure. The easiest standard-compliant ones are:
document.getElementById(imageId)
and
document.images[imageId]

You can do more convoluted things, but there's no reason for that.

If you already have the element available (like "this" in an intrinsic
event handler), then ofcourse there is no need to look it up at all,
as the other examples showed.

/L
 
P

Prisoner at War

It should not! It is one of those silly MS ideas,
but MS started out to allow:
document.name.src
which is nearly just as wrong.

Why should it be wrong?? Seems to make sense otherwise...I mean,
doesn't it basically follow the convention used when addressing form
elements? Why not extend that idea to images, too...besides, I've
seen that used since JavaScript 1.2 (I have a few old books from the
'90s).
===

<img name = 'myImage' id = 'imageId' src = ''>

Which one should work, or both?

document.myImage.src
document.imageId.src

===

No, an element should be called as a javascript 'object' by:

var imageId = document.getElementById('imageId')
or
var myImage0 = document.getElementsByName('myImage')[0]

That's something I'm not getting about JavaScript right now...to call
certain objects, one must first "create" them as variables???
(Another confusing fact to my layman's sensibility is how variables
can also be functions!)
Less good in my view is:
document.images['myImage']
document.images.myImage
because the name could point to a collection.

===

if 'this' is possible, it is just as nice,
[not tested]:

==========================================
<img src="something.jpg"
onMouseOver = "toggleImg(this,'nothing.jpg');"
onMouseOut = "toggleImg(this,'');">

<img src="somethingElse.jpg"
onMouseOver = "toggleImg(this,'nothingElse.jpg');"
onMouseOut = "toggleImg(this,'');">

<script type='text/javascript'>
function toggleImg(imPointer,img2){
if (img2) {
imPointer.old = imPointer.src;
imPointer.src = img2;
} else {
imPointer.src = imPointer.old;
};};

</script>
==========================================

It may be "pure" like how bottom-posting is proper netiquette, but it
seems overly wrought for what is really a very simple thing. As a non-
programmer, I think I have to say that I prefer the current "ad hoc"
implementation.
 
P

Prisoner at War

So, the book contains bad practices. That's the case for most
Javascript books.

Not to mention typos! Also, very confusing for a newbie when
sometimes a semi-colon is used after "var timer=null" and sometimes
not.

But I've found this book to be a bit better than most, which remind of
of those "Draw 50 Dogs" ("Dinosaurs/Airplanes/Famous People," etc.) by
Lee J. Ames, where there are only six or eight steps but the first
ones are overly simplistic and the last ones are overly complex.

Why can't programmers write a good book on programming?? Especially
without all kinds of confusing typos and mixing up "var thisTime" with
"var this_Time," etc.
Hopefully only drop the "window" part. The "document" is necessary.

LOL -- and that's my typo!
Because there is no reason to believe it should, except that *some*
browsers have chosen to create properties on the document object
(and some on the window object) that refers to elements with an id
attribute.

No standard requires it, though.

OMG, for real?? But that's what *all* the JavaScript books say!!
Well, the eight or nine I've checked out so far....
Whaddayaknow. Maybe Evertjan knows better than the book author. :)

Yeah, you know, if it weren't for the "psychological comfort" of
having it at the toilet with me, I don't think I would ever use a book
again when it comes to computer programming kind of stuff....
Not really. XHTML is not necessary for any current browser, and indeed
many current browser doesn't even understand it correctly (they just
treat it as HTML with errors).

Well, my IE, FF, and Opera all understand the XHTML-compliant w3c
Schools website all right!
Unlikely in the short run, and personally I expect something else to
replace both before that happens.

Oh, goodness...this is another reason why I realized I didn't want to
go into computer programming (don't laugh, I actually got a B once in
Turbo Pascal using only half my brain!) -- all that hard work, worth
only about two years before some new language becomes the standard....
XHTML is not necessary, in the sense that there is no present need
that it fullfils better than HTML.

Frankly, I found it rather silly myself -- I mean, <br /> and other
closing-tag nonsense??

(I think it's brought to us by the same nerds who insist on bottom-
posting!)
 
V

VK

THAT WAS THE PROBLEM -- the id attribute was not understood by Opera
and MSIE!!

It is understood - by document.getElememtById method as I see. And
document.getElememtById is actually is the only legitimate method
where id attribute should be used. Because it is the most used DOM
methods, many libraries have special function with a short name just
to do document.getElememtById so to save space and programmers' finger
tips. The most common function name for that is $ (and yes, dollar
sign is a valid identifier in Javascript). So by seeing $('foo') and $
('bar') in a 3rd party library you now will know what a hey is that.

Some browsers are going above this recommendation: for each DOM
element with id they are automatically creating global variable with
the same name so programmers wouldn't be "bothered" with
ocument.getElememtById. I hold this improvement as a very bad idea,
yet IE6 (always) and IE7 and Firefox (both in quirk mode only) do
implement it.

There is also document.all collection for all id'ed elements, which is
initially proprietary to IE. Now Firefox implements is as well in
quirk mode - btw in a highly sophisticated (aka convoluted) way.
Namely document.all is undefined in either case, but document.all(id)
_call_ does work in quirk mode. Other words:
typeof document.all == 'undefined' // true
// but
document.all('myDiv') // no problem

AFAIK a first ever historical precedence created by this in the
programming, when an object doesn't exist but at the same time can be
successfully called.

The moral: always use document.getElememtById
 
E

Evertjan.

Prisoner at War wrote on 17 apr 2008 in comp.lang.javascript:
That's something I'm not getting about JavaScript right now...to call
certain objects, one must first "create" them as variables???
(Another confusing fact to my layman's sensibility is how variables
can also be functions!)

You have a wrong concept of [names of] variables, it seems to me.

var blah = 3;

blah here "is" not the variable in sensu strictior,
but blah "holds" a pointer to the space in memory
that is made up as a variable.

you could say, "blah points to a variable",
or in dayly use "blah is a variable"

blah = {};

now the same pointer points to an object.
you could say, "blah points to an object",
or in dayly use "blah is an object"

blah = [];
now it points to an array.

blah = document.getElementById('theId')
now the same blah points to a DOM element.

.... and now to your Q:

blah = function(){alert('Hi!')};
now blah "is" a function.

In general it is all the same "blah"
only once "var"-ed,
changing his [her?] pointer
to "be" another javascript "thing",
depending on what is on the right side of the
"let" operator, the "=".
 
P

Prisoner at War

It is understood - by document.getElememtById method as I see. And
document.getElememtById is actually is the only legitimate method
where id attribute should be used. Because it is the most used DOM
methods, many libraries have special function with a short name just
to do document.getElememtById so to save space and programmers' finger
tips. The most common function name for that is $ (and yes, dollar
sign is a valid identifier in Javascript). So by seeing $('foo') and $
('bar') in a 3rd party library you now will know what a hey is that.

Some browsers are going above this recommendation: for each DOM
element with id they are automatically creating global variable with
the same name so programmers wouldn't be "bothered" with
ocument.getElememtById. I hold this improvement as a very bad idea,
yet IE6 (always) and IE7 and Firefox (both in quirk mode only) do
implement it.

There is also document.all collection for all id'ed elements, which is
initially proprietary to IE. Now Firefox implements is as well in
quirk mode - btw in a highly sophisticated (aka convoluted) way.
Namely document.all is undefined in either case, but document.all(id)
_call_ does work in quirk mode. Other words:
typeof document.all == 'undefined' // true
// but
document.all('myDiv') // no problem

AFAIK a first ever historical precedence created by this in the
programming, when an object doesn't exist but at the same time can be
successfully called.

The moral: always use document.getElememtById

Hmmm...that really drove home the point for me: "an object doesn't
exist but at the same time can be successfully called"...thanks.

I still like the more convenient way of
"document.imageName.src="hehehe.jpg" though...certainly makes more
sense from a user-friendliness POV...heck, I'm still wondering why
variables can also be functions! As in "var timer = setTimeout("bleh
()", 10000)"....
 
M

Matt Kruse

I still like the more convenient way of
"document.imageName.src="hehehe.jpg" though...certainly makes more
sense from a user-friendliness POV

Until you reach the cases where it blows up.

<img src="" name="forms" id="forms">

document.forms is supposed to be a collection of all forms on the
page. But it's also a name and id above.
So what should document.forms refer to?

Pulling names and id's up into a wider namespace is very bad and
causes all kinds of trouble for lots of people.

See http://www.javascripttoolbox.com/bestpractices/#forms

Matt Kruse
 
P

Prisoner at War

You have a wrong concept of [names of] variables, it seems to me.

Yes, I'm still coming from the POV of algebra and basic
mathematics...guess I have too literal a mindset!
var blah = 3;

blah here "is" not the variable in sensu strictior,

Sorry, what? "Sensustrictior"???
but blah "holds" a pointer to the space in memory
that is made up as a variable.

By that I understand that the variable contains the integer 3 (and not
the string "3").
you could say, "blah points to a variable",
or in dayly use "blah is a variable"

Well, that's what it *is* -- a variable!
blah = {};

now the same pointer points to an object.
you could say, "blah points to an object",
or in dayly use "blah is an object"

Hmmm, see, now I would not have parsed things that way...I would have
thought, "'blah' is a variable that has as its value an
object"...which is reather confusing, yes!!
blah = [];
now it points to an array.

blah = document.getElementById('theId')
now the same blah points to a DOM element.

Hmmm, and now it points to an element *of* an object...good grief!!
... and now to your Q:

blah = function(){alert('Hi!')};
now blah "is" a function.

Indeed! Thanks for "deconstructing" my "interpreter" or "parser" for
me! I will just think of a "variable" as "whatever-the-rules-allow-it-
to-be" from now on...at least I'll feel better when variable "x" turns
out to be a yellow watermelon in a tutu! =)
In general it is all the same "blah"
only once "var"-ed,
changing his [her?]

LOL!! Must be a *her*...oh yes, definitely...la donna e mobile!
pointer
to "be" another javascript "thing",
depending on what is on the right side of the
"let" operator, the "=".

Thanks a lot, truly...I don't know why programming books don't address
the fundamental basics in this way -- when I hear "variable" and
"function" I'm thinking algebra and trigonometry...basically, in
programming, a variable is whatever the language allows it to be, and
a function is a set of commands (and maybe commands on how those
commands are to be executed, like with conditionals and loops).

Sheesh...you think maybe we could just go back to assembly language?
 
V

VK

heck, I'm still wondering why
variables can also be functions! As in "var timer = setTimeout("bleh
()", 10000)"....

I understand what you are asking about though you have used a wrong
sample for your question.

window.setTimeout(functionF, delay) returns numeric timer id so one
could cancel the action before the timeout by using
window.clearTimeout(timer)

So in your sample variable timer gets the result of executing
window.setTimeout method which is a primitive numeric value.

Concerning "variables can also be functions" - Javascript as a
dynamically typed language. It means that at any given moment any
variable is of some particular type, but it can be retyped at any next
moment. It is not a good style of programming, but fully valid.
Javascript was intended to be used by the most wide auditory with very
low programming knowledge. This way some facilitation and "dirt
tolerance" being provided. This is why Javascript doesn't have any
special type markers like say in Perl, where one can tell the type of
variable by just looking at its name:
$foo # literal
@foo # array
%foo # hash
&foo # subroutine
etc.
 
E

Evertjan.

Prisoner at War wrote on 17 apr 2008 in comp.lang.javascript:
Sheesh...you think maybe we could just go back to assembly language?

I started off with assembly around 1962.

Interpreters like javascript engines are only making things a little
easier, but they also make the underlying code into a black box, and,
methinks, that is not a good thing if it makes you forget that there is
code inside that black box.


The assignment statement, called the "Let" statement in antique BASIC:

Dim a3
Let a3 = 20

assigned a value to a variable name, that could only be one letter or one
letter and a number. Then the word Let could be left out, as it became
the "default statement", and the Dim was also skippable:

a3 = 20

confusing lot's of people the same with the comparison statement:

If a3 = 20 Then

The same in javascript:

var myVariable = 20;

where the var has a Dim and a Let functionality combined.

Here the comparison operator is ==, but that is forgotten more often than
not, people using the oldfashioned =

var myVariable = 9;
if (myVariable = 20) alert(myVariable);

displaying 20 in the alert window
to the amazement of the sloppy programmer!

Both BASIC and Javascript are adaptable languages allowing for sloppyness
of the programmer. I like that, as it is fun to play with, like chess
where you cannot know all there is to know but like to do your utmost.
 
P

Prisoner at War

I started off with assembly around 1962.

****1962****!!!!!!!!!

Goodness, they invented you around the time of the silicon chip!!!

Momo's Holy Turban, 1962...that's even before JavaScript's getDate()
zero-hour!!

Well, I tried messing around with assembly language for the Commodore
64 back in seventh grade...didn't get very far, but I do remember
enjoying the thrill of putting up a sprite!
Interpreters like javascript engines are only making things a little
easier, but they also make the underlying code into a black box, and,
methinks, that is not a good thing if it makes you forget that there is
code inside that black box.

Yes, that's the thing...I wish I could understand how the language
thinks, WRT the underlying code...the true programmers are the ones
doing assembly, I think -- everyone else is just "scripting" at
various levels of complexity....
The assignment statement, called the "Let" statement in antique BASIC:

Dim a3
Let a3 = 20

assigned a value to a variable name, that could only be one letter or one
letter and a number. Then the word Let could be left out, as it became
the "default statement", and the Dim was also skippable:

a3 = 20

confusing lot's of people the same with the comparison statement:

If a3 = 20 Then

The same in javascript:

var myVariable = 20;

where the var has a Dim and a Let functionality combined.

I don't know why that should be so confusing to people...I think it's
just the way things are explained...I think it was Euler or Einstein
who said that it wasn't mathematics if you can't explain it to your
grandmother...I see this "egotism" in too many areas of life, where
people just expect others to follow them....
Here the comparison operator is ==, but that is forgotten more often than
not, people using the oldfashioned =

Okay, but these are little things, which are only a matter of "re-
mapping" one's own "visual language"...like understanding that the
worth of one US Dollar is thirty-five New Taiwan Dollars...I think
folks who get that kind of stuff confused are probably just not
interested in learning and re-mapping their preconceived notions of
the world (I have a friend who will eat absolutely nothing but
"American" food: hot dogs, pizza, hamburgers, and such)....
var myVariable = 9;
if (myVariable = 20) alert(myVariable);

Haha, syntax error: you forgot the braces (curly brackets)!
displaying 20 in the alert window
to the amazement of the sloppy programmer!

Actually, JavaScript shouldn't even display "20" -- nothing had
changed myVariable to 20 from 9....
Both BASIC and Javascript are adaptable languages allowing for sloppyness
of the programmer. I like that, as it is fun to play with, like chess
where you cannot know all there is to know but like to do your utmost.

Interesting you think of it as chess...it's more like chemistry to me
-- alchemy, even!

I got a new book on JavaSCript called "Head First JavaSCript"...it
looks like the most promising book yet, more "workbook" than
"textbook" and I expect to learn all I need to make my website really
interactive by summer's end....
 
P

Prisoner at War

Until you reach the cases where it blows up.

<img src="" name="forms" id="forms">

document.forms is supposed to be a collection of all forms on the
page. But it's also a name and id above.
So what should document.forms refer to?

True...but the programmer should simply consider words like "forms"
reserved words, and use "myForms" or some such instead, don't you
think?
Pulling names and id's up into a wider namespace is very bad and
causes all kinds of trouble for lots of people.

Seehttp://www.javascripttoolbox.com/bestpractices/#forms

Matt Kruse

Thanks for that link; I don't plan on being a real programmer at all,
but it's good to learn what I can about good programming practices. I
just think "usability" ought to trump "correctness" -- heck, isn't
that the point of something like JavaScript in the first place?? More
intuitive than not....
 
P

Prisoner at War

I understand what you are asking about though you have used a wrong
sample for your question.

LOL, I wouldn't be surprised!
window.setTimeout(functionF, delay) returns numeric timer id so one
could cancel the action before the timeout by using
window.clearTimeout(timer)

Wait a minute..."clearTimout(timer)"?? Not "cancelTimeout(timer)"???
So in your sample variable timer gets the result of executing
window.setTimeout method which is a primitive numeric value.

Sorry, I'm having difficulty parsing that...seems like our two
examples are the same....

I was just tickled by how JavaScript needs to have a timer function
"assigned" to a variable in order to cancel it...so much is built in,
but this little thing isn't, and has to make use of what seems a round-
about way of doing things! One should just be able to cancel the
function, instead of assigning the function to a variable and then
canceling the variable....

(And now I'm wondering how to do that, assign my swap-images function
to a variable such that I can call a cancelTimeout() on it!)
Concerning "variables can also be functions" - Javascript as a
dynamically typed language. It means that at any given moment any
variable is of some particular type, but it can be retyped at any next
moment. It is not a good style of programming, but fully valid.
Javascript was intended to be used by the most wide auditory with very
low programming knowledge. This way some facilitation and "dirt
tolerance" being provided. This is why Javascript doesn't have any
special type markers like say in Perl, where one can tell the type of
variable by just looking at its name:
$foo # literal
@foo # array
%foo # hash
&foo # subroutine
etc.

Hmmm...yes, I realize JavaScript was supposed to be more for non-
programmers like me, but sometimes its forgiving nature can seem like
arbitrary whim!

Or maybe I'm more of a programmer than I think?? With JavaScript,
it's sometimes hard putting things in neat little categorical
boxes...like how properties can become objects in themselves!!
 
E

Evertjan.

Prisoner at War wrote on 18 apr 2008 in comp.lang.javascript:
****1962****!!!!!!!!!

Sorry, ment 1972
Goodness, they invented you around the time of the silicon chip!!!

Momo's Holy Turban, 1962...that's even before JavaScript's getDate()
zero-hour!!

1964 I got my ham licence and was doing logic with discrete NAND and NOR
chips, the microprocessos being to expensive for me, but long before that
we were experimenting with single transistor logic.
Well, I tried messing around with assembly language for the Commodore
64 back in seventh grade...didn't get very far, but I do remember
enjoying the thrill of putting up a sprite!

Don't know about grades in school, seems a locally variable phenomenon.

Never used the C64,
I went straight from homebuild Signetics 2650 to the Amiga.
 
R

Richard Cornford

Prisoner at War wrote:
Why can't programmers write a good book on programming??
<snip>

Why would you expect programmers to be good at writing books?
Programmers do not tend to be people with high-level language
qualifications (more math and science) and they do not tend to be people
who spend much of their time writing prose.

Then there is the question of why would programmers spend their time
writing books? A good programmer, specialising in any area where there
was significant demand, can earn a very good remittance by programming,
while the market for a specialised programming book (with a subject such
as javascript) has a relatively small market and much completion in that
market. An author will only get a relatively small royalty for the sale
of a single book, and even with heavy promotion the total number of
individual books sold will not be that great. The economics may dictate
that the only people for whom writing books is worthwhile application of
their time are the people in the worst position to put anything
worthwhile into those books.

Richard.
 
E

Evertjan.

Richard Cornford wrote on 19 apr 2008 in comp.lang.javascript:
Prisoner at War wrote:

<snip>

Why would you expect programmers to be good at writing books?
Programmers do not tend to be people with high-level language
qualifications (more math and science) and they do not tend to be people
who spend much of their time writing prose.

Then there is the question of why would programmers spend their time
writing books? A good programmer, specialising in any area where there
was significant demand, can earn a very good remittance by programming,
while the market for a specialised programming book (with a subject such
as javascript) has a relatively small market and much completion in that
market. An author will only get a relatively small royalty for the sale
of a single book, and even with heavy promotion the total number of
individual books sold will not be that great. The economics may dictate
that the only people for whom writing books is worthwhile application of
their time are the people in the worst position to put anything
worthwhile into those books.

Inreresting view, I never yet asked myself why.
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,904
Latest member
HealthyVisionsCBDPrice

Latest Threads

Top