Announcing a new online book: Eloquent JavaScipt

[marijnh]

A freely-available online book about JavaScript has just been
launched:
http://eloquentjavascript.net

It attempts to provide a comprehensive introduction to the language,
and a practical environment for practicing your programming skills and
trying out code. Take a look, and let me know if you find anything
that could use improvement (there's a 'react' button in the top-left
corner of most of its pages).

Cheers,
Marijn Haverbeke

 

[David Mark]

A freely-available online book about JavaScript has just been
launched:
http://eloquentjavascript.net

It attempts to provide a comprehensive introduction to the language,
and a practical environment for practicing your programming skills and
trying out code. Take a look, and let me know if you find anything
that could use improvement (there's a 'react' button in the top-left
corner of most of its pages).

For one, I get no scrollbars on the pages in IE7 and horizontal
scrollbars in FireFox.

And why is that resize handle visible when the console is minimized
(closed in the book's parlance.)

And the page on the DOM doesn't explain the difference between
document.body and document.documentElement, other than to say that
sometimes you use one, sometimes the other. The examples that follow
switch back and forth between the two for no apparent reason.

 

[marijnh]

David,

Thanks for the feedback. The adding of a bar at the bottom of the page
requires some 'magic', which I apparantly didn't get quite right
yet...

For one, I get no scrollbars on the pages in IE7 and horizontal
scrollbars in FireFox.

IE7 only seems to show the scrollbar when it is maximized. I had not
noticed this yet, looking into it right away. Which version of FireFox
is giving you problems? It works fine in that browser on my machine.

And why is that resize handle visible when the console is minimized
(closed in the book's parlance.)

Because it is possible to open it by dragging that handle... why would
this be a problem?

And the page on the DOM doesn't explain the difference between
document.body and document.documentElement, other than to say that
sometimes you use one, sometimes the other. The examples that follow
switch back and forth between the two for no apparent reason.

From the book:

""
The object for the root of the document tree, the html element, can be
reached through the documentElement property of the document object.
Most of the time, we need the body element instead, which is at
document.body.
""

Provided the reader knows what the 'html' and 'body' elements of a
document are, which is discussed about earlier in the book, I would
say this is pretty clear. I'll rephrase the sentence about the body
slightly, to make it more clear that this is a piece of the document
that I am talking about.

Cheers,
Marijn Haverbeke

 

[David Mark]

David,

Thanks for the feedback. The adding of a bar at the bottom of the page
requires some 'magic', which I apparantly didn't get quite right
yet...

Use the style rule position:fixed for all but IE6. That browser will
require a bit of script (wrap it in conditional comments with a style
block to override position:fixed with position:absolute) to keep it at
the bottom of the window and it will twitch when you scroll.
Alternative methods that involve turning off the window's scrollbars
cause bigger problems.

IE7 only seems to show the scrollbar when it is maximized. I had not
noticed this yet, looking into it right away. Which version of FireFox
is giving you problems? It works fine in that browser on my machine.

The only problem with Firefox that I was referring to was the fact
that the content was too big to fit at 800x600 and required the
horizontal scrollbar.

Because it is possible to open it by dragging that handle... why would
this be a problem?

It doesn't work very well. I finally got it to work, but it took a
few tries. Try doing it several times in a row without a miss.

""
The object for the root of the document tree, the html element, can be
reached through the documentElement property of the document object.
Most of the time, we need the body element instead, which is at
document.body.
""

Provided the reader knows what the 'html' and 'body' elements of a
document are, which is discussed about earlier in the book, I would
say this is pretty clear. I'll rephrase the

I didn't read the earlier chapters, but it seems like you should add a
reference to the explanation. And "most of the time" is too muddy.
These days I find that most of the time I need the documentElement.

 

[marijnh]

Use the style rule position:fixed for all but IE6.

This has a bunch of issues as well (there will be content under the
fixed element). I seem to have fixed the IE problem by setting the
width of the content area to 100% -- what was happening was that the
DIV was too wide for the window, and thus the scroll bar was outside
of the screen. (Don't ask me why.)

The problem with code (in a PRE tag) being too wide for the page turns
out to be very tricky. The overflow-x style seemed a solution for a
moment (at least in FF and IE), but that is still so buggy that it is
unworkable as well. -- If anyone happens to know some way to limit the
width of an element (adding a scrollbar if necessary) without fixing
its height, let me know!

It doesn't work very well. I finally got it to work, but it took a
few tries. Try doing it several times in a row without a miss.

On second thought, I agree. I'll revise it to be less confusing.

Cheers,
Marijn

 

[Animesh K]

A freely-available online book about JavaScript has just been
launched:
http://eloquentjavascript.net

It attempts to provide a comprehensive introduction to the language,
and a practical environment for practicing your programming skills and
trying out code. Take a look, and let me know if you find anything
that could use improvement (there's a 'react' button in the top-left
corner of most of its pages).

Cheers,
Marijn Haverbeke

Thank you. I will get back with suggestions once I run through some
examples and/or difficulties.

 

[Peter Michaux]

A freely-available online book about JavaScript has just been
launched:
http://eloquentjavascript.net

I mocked up an idea for an online JavaScript book with your example/
console concept a while back. So right there I think you have a great
idea!

I think a big improvement would be if each page had user comments like
the PHP & MySQL docs have.

Peter

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]
glegroups.com>, Thu, 2 Aug 2007 07:12:56, (e-mail address removed) posted:

A freely-available online book about JavaScript has just been
launched:
http://eloquentjavascript.net

Since you have overridden my choice of Browser font, I will not be
reading it much. I prefer a Serif font; you set a sans-serif font - not
even my default Arial, but more squashed-together. NASA and some
Russians are just as bad.

You have also made top-of-page navigation appear in very faded grey.

Your excessive margins waste my screen space.

A wise author leaves the readers' defaults for plain text uncorrupted.


The document is undated, does not identify its author, and provides no
obvious feedback address. Clicking the face gives me three runtime
errors, then provides one of those stupid boxes which are far too small;
if I want to mail you, I will want to use my own mail system, which
properly files everything. And there is no box for my name or address.

The index makes no mention of Date.

In Chapter 4, the description of the getTime values has the standard two
errors.

On date equality - you don't take the opportunity to say that
+new Date(0) == +new Date(0) gives true

Aunt Emily writes dates as DD-MM-YYYY : that is uncommon. Europe uses,
mostly, DD/MM/YYYY or DD.MM.YYYY, and the USA uses MM/DD/YYYY. ISO uses
'-' as the separator; it is IMHO unwise to use the ISO separator with a
non-ISO field order, except when writing only for a locality that
prefers it. Let her be wise and use YYYY-MM-DD.


In Chapter 10, I think you should make it clear that RegExps are not
restricted to JS, and that other implementations are similar but not
necessarily identical.

Chapter 2 - the limit is 2^53, not 2^52. That's over 9e15.
"Calculations with whole numbers (also called integers) that fit in 52
bits are guaranteed to always be precise." Apart from 52->53, that's
not entirely so. Shift and other operations are 32-bit. I think you
don't mention the useful Unary + operator.

 

[David Mark]

This has a bunch of issues as well (there will be content under the
fixed element). I seem to have fixed the IE problem by setting

Well, that is one issue that is easy to fix: put it at the top and use
a suitable top margin on the body.

the

width of the content area to 100% -- what was happening was that the
DIV was too wide for the window, and thus the scroll bar was outside
of the screen. (Don't ask me why.)

I haven't looked at your code or CSS, but I can think of lots of
reasons why. That is why I would avoid trying to simulate window
scrolling with a DIV.

The problem with code (in a PRE tag) being too wide for the page turns
out to be very tricky. The overflow-x style seemed a solution for a

I wouldn't use overflow-x as there are compatibility issues. Use
overflow.

moment (at least in FF and IE), but that is still so buggy that it is
unworkable as well. -- If anyone happens to know some way to limit the
width of an element (adding a scrollbar if necessary) without fixing
its height, let me know!

You just set its width, but as you have seen, a PRE element will not
wrap and overflow will spill out of its borders. Use em units for
your element widths and make them big enough to contain your widest
snippet. Test with multiple font sizes and you will see what I mean.

To minimize horizontal scrolling, tighten up the margins of the page
(for a start.) From the looks of it, that will allow the page to
display without horizontal scrollbars at 800x600. Optimally, a page
shouldn't need a horizontal scrollbar until the width drops below
500. To achieve that goal, you would need to break long lines in your
source code. An example of a site that does this is alistapart.com.
Granted, their pages also require horizontal scrolling (their design
wastes too much screen space), but they do keep their code snippets
from overflowing into the next column.

On second thought, I agree. I'll revise it to be less confusing.

It wouldn't be confusing if it were reliable. The first time I tried
it, I thought it was broken. Only after you mentioned that it should
work did I go back and try again. I didn't look at your script, so I
am not sure what the problem is.

 

[David Mark]

Since you have overridden my choice of Browser font, I will not be

Are you suggesting that pages should not suggest a font family for
their main content? Or to stick with generics only? I can't see
leaving it to the user as most would see a default of Times New
Roman. To me, that would make pages look unpolished, as if the author
didn't bother (or didn't know how) to set the font.

reading it much. I prefer a Serif font; you set a sans-serif font - not

I have always thought that serif fonts read easier on paper and sans-
serif is more legible on monitor screens. Obviously you can't please
everybody in this regard.

[snip]

Your excessive margins waste my screen space.

And causes horizontal scrolling with smaller window sizes (or larger
font sizes.)

 

[Peter Michaux]

In comp.lang.javascript message <[email protected]
glegroups.com>, Thu, 2 Aug 2007 07:12:56, (e-mail address removed) posted:


Since you have overridden my choice of Browser font, I will not be
reading it much. I prefer a Serif font; you set a sans-serif font - not
even my default Arial, but more squashed-together. NASA and some
Russians are just as bad.

You may wish to learn about using CSS, the cascade, !important rules
and reader stylesheets. You may also find that some browser plugins
make using this technology more accessible to you.

https://addons.mozilla.org/en-US/firefox/addon/2108

Peter

 

[marijnh]

I think a big improvement would be if each page had user comments like
the PHP & MySQL docs have.

I have considered this, but the abyssmal quality of most user comments
has made mew decide against it. They mostly just add distraction and
misinformation.

 

[marijnh]

Thanks for the (somewhat grumpy, but useful) feedback.

[stuff about layout]

I know some people prefer pages to keep the default layout. I'm not
one of them, I find it to look ugly and primitive.

The document is undated, does not identify its author, and provides no
obvious feedback address.

Good point about the date and author, I guess I'll add these to every
page. Could you tell me which browser you use and which errors the
feedback system gives you?

In Chapter 4, the description of the getTime values has the standard two
errors.

Which are?

On date equality - you don't take the opportunity to say that
+new Date(0) == +new Date(0) gives true

Yes, as far as I know, applying the + operator will give you the
valueOf of the object, which for Date object is the same as the
getTime

Aunt Emily writes dates as DD-MM-YYYY : that is uncommon. Europe uses,
mostly, DD/MM/YYYY or DD.MM.YYYY, and the USA uses MM/DD/YYYY. ISO uses
'-' as the separator; it is IMHO unwise to use the ISO separator with a
non-ISO field order, except when writing only for a locality that
prefers it. Let her be wise and use YYYY-MM-DD.

DD-MM-YYYY is not uncommon in The Netherlands (where I live), but yes,
slashes are probably a better idea.

In Chapter 10, I think you should make it clear that RegExps are not
restricted to JS, and that other implementations are similar but not
necessarily identical.

It's in a footnote, but I'll try to make it more obvious.

Chapter 2 - the limit is 2^53, not 2^52. That's over 9e15.
"Calculations with whole numbers (also called integers) that fit in 52
bits are guaranteed to always be precise." Apart from 52->53, that's
not entirely so. Shift and other operations are 32-bit. I think you
don't mention the useful Unary + operator.

I didn't know >> and << are 32 bit. (That is a shame.) Does unary + do
anything that the Number function doesn't? -- Apart from being
shorter.

Cheers,
Marijn

 

[marijnh]

Well, that is one issue that is easy to fix: put it at the top and use
a suitable top margin on the body.

It seems to me that scrolling the page will cause text to end up on
the top anyway. Plus, I don't want that console at the top.

I wouldn't use overflow-x as there are compatibility issues. Use
overflow.

I would, except that that requires the height of the content to be
fixed. Fixed-height code-boxes are a clumsy waste of space. Maybe I'll
make my scripts adjust the height of the boxes, though that requires
adding extra space for the scrollbar on IE.

To minimize horizontal scrolling, tighten up the margins of the page
(for a start.) From the looks of it, that will allow the page to
display without horizontal scrollbars at 800x600. Optimally, a page
shouldn't need a horizontal scrollbar until the width drops below
500. To achieve that goal, you would need to break long lines in your
source code. An example of a site that does this is alistapart.com.
Granted, their pages also require horizontal scrolling (their design
wastes too much screen space), but they do keep their code snippets
from overflowing into the next column.

I could reduce the margins a little, but that will make the lines
awfully long in big windows. I tried making the code lines shorter,
but that makes them very awkward to read.

It wouldn't be confusing if it were reliable. The first time I tried
it, I thought it was broken. Only after you mentioned that it should
work did I go back and try again. I didn't look at your script, so I
am not sure what the problem is.

The 'unreliability' that you observed had something to do with the
fact that it would 'snap' closed when you dragged it too small. I
changed this (you can't drag it below a certain size now), and it
seems to behave in a more friendly way.

Regards,
Marijn

 

[David Mark]

It seems to me that scrolling the page will cause text to end up on
the top anyway. Plus, I don't want that console at the top.

Right. Top or bottom will still reduce the available space for
content. But if you want to use position:absolute for the console in
IE6 (without a scripted workaround to simulate fixed positioning), the
top margin is the only option. I definitely don't think you want to
play around with the window's scrollbars.

I would, except that that requires the height of the content to be
fixed. Fixed-height code-boxes are a clumsy waste of space.

No it doesn't.

Try this:

<html>
<head>
<style type="text/css">
body {font-family:sans-serif;margin:0 1em 0 1em;text-align:center}
p {max-width:45em;margin:1em auto;text-align:left}
div.code {overflow:auto;width:25em;margin:0 auto;border:dashed
1px;background-color:#CCCCCC;padding:.25em}
div.code pre {text-align:left;padding:0;margin:0}
</style>
</head>
<body>
<p>
This is some content. This is some content. This is some content. This
is some content. This is some content. This is some content. This is
some content. This is some content. This is some content. This is some
content. This is some content. This is some content.
</p>
<div class="code">
<pre>
function test() {
alert('abcdefghijklmnopqrstuvwxyz');
}
</pre>
</div>
<p>
This is some more content. This is some more content. This is some
more content. This is some more content. This is some more content.
This is some more content. This is some more content. This is some
more content. This is some more content. This is some more content.
</p>
</body>
</html>

Adjust the widths to suit your taste (and the average width of your
code snippets.) You'll still need to implement a CSS expression to
simulate max-width in IE6 and earlier (wrap it in an IE conditional
comment.) You can put the text-align:center rule for the body in
there too (it is an old IE fix too.)

Maybe I'll

make my scripts adjust the height of the boxes, though that requires
adding extra space for the scrollbar on IE.

You don't want to go down that road. Using script to fix layout
issues is a bad idea.

I could reduce the margins a little, but that will make the lines
awfully long in big windows. I tried making the code lines

Define "big."

shorter,

but that makes them very awkward to read.


The 'unreliability' that you observed had something to do with the
fact that it would 'snap' closed when you dragged it too small. I

I don't know. It seemed like the drag didn't take at all as I would
try to drag it half way up the page, release the mouse button and
nothing would happen.

changed this (you can't drag it below a certain size now), and it
seems to behave in a more friendly way.

I'll try it again when I get a chance. Last I looked, the handle was
gone when the console is closed.

 

[David Mark]

On 3 aug, 01:32, David Mark <[email protected]> wrote:

[snip]

code snippets.) You'll still need to implement a CSS expression to
simulate max-width in IE6 and earlier (wrap it in an IE conditional
comment.) You can put the text-align:center rule for the body in
there too (it is an old IE fix too.)

Oops. You are using quirks mode, so you will need to simulate max-
width for IE period. Same for the auto margin workaround. Consider
switching to standards mode.

Also, I left out a color rule for the code DIV.

 

[marijnh]

I definitely don't think you want to play around with the window's scrollbars.

It *seems* to work fine now. Sure, I have to use some kind of hack to
make links to anchors work, and I wouldn't be surprised if there are
still some problematic corner cases on some browsers, but this really
seems preferable to the alternatives.

[html snippet]

That works very well for Firefox, but my obscure-css knowledge turned
out to be insufficient to make it behave properly on IE. Besides,
fixing the width of these things will give long lines a scroll-bar
even when the client has a window that is wide enough to show them. I
tweaked things a bit more (slightly smaller font, narrower margins,
cut down a few more long lines), and now everything displays propertly
on 800x600. People using smaller windows than that are probably used
to horizontal scrolling

You don't want to go down that road. Using script to fix layout
issues is a bad idea.

I know. The console is entirely layed out by scripts and absolute
positions (texareas and iframes don't resize very well on their own),
and it was a major headache.

Thanks again for the remarks and hints, they forced me to take care of
a few sloppy aspects that I had been trying to forget about. Heh.

Marijn

 

[marijnh]

Oops. You are using quirks mode, so you will need to simulate max-
width for IE period. Same for the auto margin workaround. Consider
switching to standards mode.

I tried standards mode, but it seemed to open a whole new can of IE
bugs related to the div-as-scrolling-document trick. It would insist
on showing the body scrollbars, and weirdly underestimate the size of
the div's content, making the scale of its scrollbar way too low, so
that you could only scroll half a page at a time (which would cause
the scrollbar to grow slightly bigger). Bizarre, huh?

Marijn

 

[marijnh]

Clicking the face gives me three runtime
errors, then provides one of those stupid boxes which are far too small;

The stupid box is still way too small (...), but I found and fixed the
errors.

Cheers,
Marijn

 

[Thomas 'PointedEars' Lahn]

On 3 aug, 01:32, David Mark <[email protected]> wrote:

[...] You'll still need to implement a CSS expression to
simulate max-width in IE6 and earlier (wrap it in an IE conditional
comment.) You can put the text-align:center rule for the body in
there too (it is an old IE fix too.)

Oops. You are using quirks mode,

That is called Compatibility Mode in MSHTML.

so you will need to simulate max-width for IE period.

Nonsense. IE < 7 does not support max-width, or min-width, max-height
or min-height for that matter. In no rendering mode. Period.


PointedEars