A Newbie's Must-Have Library
Prisoner at War
Well, in case anyone should need to know in the near future, here are
my recommendations for best beginner's books:
** Head First HTML with CSS & XHTML, Head First JavaScript **
If you get only two books for introductory web development, get
these!! They are truly the most effective books around. They are
more "workbook" than "textbook" and "interactive" in that sense -- if
they were college courses, they would be "lab" instead of
"lecture"...much more hands-on and very little theory by comparison
(though enough to tie things together conceptually so that the
exercises make sense). Every three or four pages -- and these pages
are quick, since type is big with lots of illustrations, and even
white spaces for a clean and uncluttered feel -- there is an exercise
to be done that forces you to think actively about the concept covered
instead of passively registering it as just another factoid. This
very effective pedagogy puts in mind the still-in-print classic "Bobby
Fisher Teaches Chess," where theory is at a minimum relative to all
the opportunities for actually putting it into practice -- right away.
The first title has much better production values, being in full-color
and with a slicker (though not exactly magazine-"slick") paper. It's
unfortunate O'Reilly decided to issue the second title in B&W, since a
big part of the whole ethos of its Head First Series is visual impact.
** DOM Scripting **
This is an excellent title in the excellent Friends of Ed series of
books on web design issues from Apress Books. It's almost a necessary
volume for a newbie's library, as it teaches JavaScript in a very
correct way: as an aspect of the Document Object Model. This book
made me understand that JavaScript wasn't some "foreign technology"
that's to be "imposed" on something called the DOM; rather, JavaScript
is an expression *of* the DOM, almost arising out of it...now that's
not what this book says, but that's what I got out of it. I know it's
not a 100% correct view technically speaking, but in a "poetic" sense
that's how it feels to me, and I thank this book for helping stimulate
such ideas in me, that I may be able to see JavaScript and the DOM in
my own ways, thus making them that much more meaningful.
But enough about me; what this book will do for a newbie is teach him
or her the "grammar" of the DOM and some of its most useful
vocabulary. In a very intellectually pleasing manner, the book
proceeds step-by-step in a perhaps unintentional reflection of the
tree-like nature of the DOM, branching out and growing ever more
complex. Though not strictly for total beginners and best suited for
those about halfway towards an intermediate level of knowledge, there
is an intelligent "refresher" of basic JavaScript topics in the
beginning of the book that can serve as a good "executive summary" for
those who are indeed total newbies, giving them a good preview of
sorts that's also detailed enough to be a short one-day crash-course
(!) in JavaScript. This is an extremely useful book and I can't
imagine anyone not being able to benefit from it sooner or later --
and most likely sooner than later!
** The Book of JavaScript, Second Edition **
This is an old title, even though it's been updated with whole
chapters (comprising almost a good third of the book's thickness!) on
Ajax. It's also full of outdated practices, such as the "<!---Hide me
from old browsers" stuff, but I think the chapters on Ajax, DHTML,
XML, and CGI serve as nice little introductions to the subjects for a
newbie. I also like the end-of-chapter projects that test one's
understanding of the material (though not made such an integral part
of the "narrative" that actually doing them is a must in order to read
on), particular towards the end where an Italian-English translation
program is put together. The book is pretty standard in how it
presents the material (though it does not read as dryly as a more
reference-work-like title such as O'Reilly's famous "JavaScript: The
Definitive Guide") but it gets the job done in a more "coherent" way
than many other titles (like "JavaScript for Dummies" which I found a
little too "scatter-brained" or "JavaScript: Your Visual Blueprint for
Building Dynamic Web Pages, 2nd Edition" which I thought was almost
useless).
Unfortunately, O'Reilly (owner, apparently, of the No Starch Press
imprint under which this title is published) has cheapened the
production values in its latest printing of this title, with all-black
text now instead of the formerly elegant blue highlights used, and
thinner pages despite the colophon still listing paper stock as 60-lb.
when it's more like 24 or 26-lb. [noticeably, but still only slightly,
heavier than copier paper]).
** Beginning Web Development with CSS: From Novice to Professional **
This is such a solid if somewhat unremarkable and dry primer on the
subject that a newbie's library would feel slightly incomplete without
it as a kind of reference work. It combines the "progressive
narrative" of a step-by-step tutorial with the breadth of coverage
associated with textbooks, and finishing it felt like an
accomplishment in itself, by which I mean that I was confident I could
solve any styling challenge.
** Pro CSS Techniques **
I recommend this book for a beginner who's about to move onto the
intermediate stage of ability and understanding, but a rank beginner
can get a good sense of what's possible and pick up a light foundation
"eavesdropping" on three famous web designers giving their take on the
subject. Indeed, for many people, this book would be as good an
*introduction* to CSS as any! A big part of the book is just
covering the basics, but because the material is really meant for
someone with an intermediate level of knowledge, some n00bs might want
the meatier explanation of a "dedicated" beginner's tome like the book
above mentioned immediately before this one.
** Web Standards Creativity: Innovations in Web Design with XHTML,
CSS, and DOM Scripting **
Last but not least, this beautiful full-color volume really whets
one's appetite for what's possible and is quite the motivational aid.
Another great title in the Friends of Ed series (who's Ed, anyway?? I
don't think it's explained on the website, either), this book
definitely demands at least an intermediate level of expertise in all
three areas of markup, styling, and behavior -- (X)HTML, CSS, and
JavaScript, respectively -- in order to utilize its wisdom, but it's
worth having on a newbie's shelf for bedtime perusing and creative
inspiration.
Andy Dingley
> Well, in case anyone should need to know in the near future, here are
> my recommendations for best beginner's books:
Or in another universe, where things are understood and site code is
stable and reliable, beginners don't even think about reading
JavaScript books until they've written some HTML and CSS.
You need it _VERY_ rarely. Using it without a foundation of good HTML
understanding leads to trouble. Few people can learn both from scratch
simultaneously, so it's useful to really grok the first first, which
means getting some hands-on and actually building content that way.
I write sites that use JavaScript for a vanishingly small proportion
of pages. They just don't need it. I work (for money) on complex web
apps that are built up almost entirely of JavaScript. We don't write
this by hand, because it's impossible to write large amounts of
JavaScript in an efficient manner. This stuff is all generated server-
side by frameworks like JSF & Facelets.
Ben C
[...]
> We don't write this by hand, because it's impossible to write large
> amounts of JavaScript in an efficient manner.
Why? What's wrong with it?
Henry
> On 15 May, 04:55, Prisoner at War wrote:
>
>> Well, in case anyone should need to know in the near future,
>> here are my recommendations for best beginner's books:
>
> Or in another universe, where things are understood and site
> code is stable and reliable, beginners don't even think about
> reading JavaScript books until they've written some HTML and
> CSS.
Would that also be the universe where novices appreciate that the only
things that they are in a position to sensibly say about a book they
read is how easy it was for them to read and understand, and nothing
about the quality of any advice/examples given or the technical
accuracy of the content? Given that the technical accuracy of
javascript books tends to be low, and the advice they give ranges from
the poor to the actively dangerous, an individual's ability to judge
those types of things seems a reasonable pre-request for taking their
book recommendations seriously.
Andy Dingley
> On 2008-05-15, Andy Dingley <ding...@codesmiths.com> wrote:
> > We don't write this by hand, because it's impossible to write large
> > amounts of JavaScript in an efficient manner.
>
> Why? What's wrong with it?
Crappy architectural model that's about 20 years old, leading to a
piss-poor version of O-O
Floppy syntax, meaning that sloppy coding is hidden, and there's room
for too many semantic errors under that sloppy code.
No clear definition of the language standard, leading to widespread
proprietary extension. When you code "JS" should you be coding to the
ECMAScript standard, JScript, or a JavaScript? If you inherit a body
of code, what is it, and is it conformant to your project standards?
Dr J R Stockton
> On 15 May, 04:55, Prisoner at War <prisoner_at_...@yahoo.com> wrote:
>
> > Well, in case anyone should need to know in the near future, here are
> > my recommendations for best beginner's books:
I think that we have already read enough to learn what your opinion is
worth.
> Or in another universe, where things are understood and site code is
> stable and reliable, beginners don't even think about reading
> JavaScript books until they've written some HTML and CSS.
>
> You need it _VERY_ rarely. Using it without a foundation of good HTML
> understanding leads to trouble. Few people can learn both from scratch
> simultaneously, so it's useful to really grok the first first, which
> means getting some hands-on and actually building content that way.
>
> I write sites that use JavaScript for a vanishingly small proportion
> of pages. They just don't need it. I work (for money) on complex web
> apps that are built up almost entirely of JavaScript. We don't write
> this by hand, because it's impossible to write large amounts of
> JavaScript in an efficient manner. This stuff is all generated server-
> side by frameworks like JSF & Facelets.
You are considering only a minority of the possible types of use of
Javascript in web pages - just, in fact, the commercially-dominant
case.
Observe, for example, the scripting on many of the web pages of NASA
and associates.
--
(c) John Stockton, near London, UK. Posting with Google.
Mail: J.R.""""""""@physics.org or (better) via Home Page at
Web: <URL:http://www.merlyn.demon.co.uk/>
FAQish topics, acronyms, links, etc.; Date, Delphi, JavaScript, ...
Andy Dingley
> Observe, for example, the scripting on many of the web pages of NASA
> and associates.
So do you advocate that newbies should start out with an attitude of,
"Match NASA's complexity from the start" ?
Prisoner at War
You sound like a scorned woman, but I don't know what I've ever done
to you.
On May 15, 7:49 am, Dr J R Stockton <J.R.Stock...@physics.org> wrote:
>
>
> I think that we have already read enough to learn what your opinion is
> worth.
>
>
>
Prisoner at War
>
>
> Would that also be the universe where novices appreciate that the only
> things that they are in a position to sensibly say about a book they
> read is how easy it was for them to read and understand, and nothing
> about the quality of any advice/examples given or the technical
> accuracy of the content?
Did I say these books were technically accurate? In fact, I even
noted that "The Book of JavaScript" contains outdated practices.
> Given that the technical accuracy of
> javascript books tends to be low, and the advice they give ranges from
> the poor to the actively dangerous, an individual's ability to judge
> those types of things seems a reasonable pre-request for taking their
> book recommendations seriously.
These books are for newbies. That means "accessibility," first and
foremost. As a newbie, I know what works for newbies who aren't
programmers.
However, it's an unfortunate consequence of "internet culture" that
books, particularly technical books though increasingly all books, are
released with all kinds of errors, from orthographical to just plain
wrong information.
So, a caveat to my review: LOOK UP THE BOOKS' ERRATA PAGES ON THE WEB
-- AND KNOW THAT NOT ALL ERRATA HAVE EVEN BEEN DOCUMENTED.
Prisoner at War
>
>
> Or in another universe, where things are understood and site code is
> stable and reliable, beginners don't even think about reading
> JavaScript books until they've written some HTML and CSS.
Actually, I'm still awaiting the book that teaches all three right
from the get-go: they are but three aspects of a greater whole, and
thus a holistic approach right from the beginning would be great. I
mean, it wasn't until perusing my third book that I really began to
appreciate the DOM, and what it means for web development....
> You need it _VERY_ rarely.
I would tend to agree, but as per my "Contradiction of Advice?" thread
at
http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/b9b7996315cd6b17/bb0e87cba80582fd?lnk=st&q=prisoner_at_war%40yahoo.com#bb0e87cba80582fd,
I have to wonder whether it's *ever* necessary, then -- I mean, is the
only legitimate use of JavaScript for bra-size calculators?? 8->
> Using it without a foundation of good HTML
> understanding leads to trouble. Few people can learn both from scratch
> simultaneously, so it's useful to really grok the first first, which
> means getting some hands-on and actually building content that way.
(X)HTML can be learned in one day, and mastered in about two or
three. CSS, maybe a week to learn, and months to master. Depending
on just how precisely "simultaneously" is defined, I think it's very
possible to grok them all at once.
> I write sites that use JavaScript for a vanishingly small proportion
> of pages. They just don't need it. I work (for money) on complex web
> apps that are built up almost entirely of JavaScript. We don't write
> this by hand, because it's impossible to write large amounts of
> JavaScript in an efficient manner. This stuff is all generated server-
> side by frameworks like JSF & Facelets.
Wow, that's interesting...I had no idea JavaScript was so
"inefficient"...I thought it was supposed to be "more efficient" (if
less powerful) than CGI???
Andy Dingley
> (X)HTML can be learned in one day, and mastered in about two or
> three.
I've known HTML (to an industry top-percentile level) for abut 5 years
now. I might get round to mastering it one day. There are half-a-dozen
people just in this newsgroup (c.i.w.a.h) who can easily show me up in
it.
> Wow, that's interesting...I had no idea JavaScript was so
> "inefficient"...I thought it was supposed to be "more efficient" (if
> less powerful) than CGI???
If you can even write that, you don't have the glimmerings of a Clue.
Andy Dingley
> So, a caveat to my review: LOOK UP THE BOOKS' ERRATA PAGES ON THE WEB
> -- AND KNOW THAT NOT ALL ERRATA HAVE EVEN BEEN DOCUMENTED.
Errata list _known_ errors.
The trouble with web design books is that the authors sincerely
believe they know what they're doing.
joebloe
> ... We don't write
> this by hand, because it's impossible to write large amounts of
> JavaScript in an efficient manner. This stuff is all generated server-
> side by frameworks like JSF & Facelets.
I suppose that on the one hand you can say that JavaScript is
overused; but on the other hand, there are some of us who believe
(correctly so) that it is a powerful and severely underutilized
programming environment. A general purpose programming language with
little need for boilerplate and with convenient access to the de facto
user interface standard? Sign me up. Oh, wait, I'm already signed up.
Prisoner at War
>
>
> I suppose that on the one hand you can say that JavaScript is
> overused; but on the other hand, there are some of us who believe
> (correctly so) that it is a powerful and severely underutilized
> programming environment. A general purpose programming language with
> little need for boilerplate and with convenient access to the de facto
> user interface standard? Sign me up. Oh, wait, I'm already signed up.
Yeah, that's the spirit!
Though I'm a newbie...so in what ways are JavaScript severely
underutilized?? Just curious.
But yeah, JavaScript has actually revived my long-dormant interest in
computer programming! I've already pre-ordered O'Reilly's "Head First
Programming" (with Python)...I only like computer programming when
it's directly relevant to something I'm looking to do -- learning how
to do math stuff is boring to me, sad to say...but insofar as
JavaScript may be used to create "special effects" for a webpage, I'm
hooked! Yeah, I know that seems to cheapen JavaScript in many a
purist's eye but hey it's how I learn....
Prisoner at War
>
>
> I've known HTML (to an industry top-percentile level) for abut 5 years
> now. I might get round to mastering it one day. There are half-a-dozen
> people just in this newsgroup (c.i.w.a.h) who can easily show me up in
> it.
Well, you obviously have a different standard of "mastery" than I do.
I don't mean "HTML God" or something, ready to answer any HTML
question for a million dollars on a TV game show...but within three
hours of learning, one should be able to look at a "standard" webpage
and have a good idea of its HTML portion, and one should be able to
create something very similar on one's own. HTML is easy to learn,
and easy to master for 99.99% of what's typically required to be done
with it.
> If you can even write that, you don't have the glimmerings of a Clue.
Uh, yeah, thanks for stating the obvious...now do you have something
to actually report, or do you just like posting to a newsgroup showing
off how smart you're supposed to be?
Prisoner at War
>
>
> Errata list _known_ errors.
Indeed. I so can't wait for the day when we just print and bind our
own hardcopies right in our own homes somehow...it really sucks buying
a book only to find out that you've got the earlier print-run with all
the errata intact.
On that note, Simon Collison's book that I just received last month-
and-a-half ago has had all errata corrected on the page; any copy
purchased now will be entirely correct.
> The trouble with web design books is that the authors sincerely
> believe they know what they're doing.
I don't understand something...why don't all you purists on these
newsgroups write the perfect book, then?
I don't mean that in a snarky way; I'm serious: I am inclined to agree
with the general consensus that a lot of these technical books can be
lacking...but then again, I also believe that one simply can't learn
from just a single title, either (unless it's HTML, of course!). I
mean, it helps to think of a subject from different angles..."The Book
of JavaScript" approaches the material with a wholly different outlook
than "Head First JavaScript" -- and I'm not simply referring to
pedagogy or production values, either! I mean, no one here learned
English from simply reading the OED, or learned about girls from one
date with one girl....
Ben C
> On May 16, 9:14 pm, Andy Dingley <ding...@codesmiths.com> wrote:
>>
>>
>> I've known HTML (to an industry top-percentile level) for abut 5 years
>> now. I might get round to mastering it one day. There are half-a-dozen
>> people just in this newsgroup (c.i.w.a.h) who can easily show me up in
>> it.
>
> Well, you obviously have a different standard of "mastery" than I do.
>
> I don't mean "HTML God" or something, ready to answer any HTML
> question for a million dollars on a TV game show...but within three
> hours of learning, one should be able to look at a "standard" webpage
> and have a good idea of its HTML portion, and one should be able to
> create something very similar on one's own. HTML is easy to learn,
> and easy to master for 99.99% of what's typically required to be done
> with it.
Right, and that's how it should be.
I don't know what mastery involves beyond understanding the
(straightforward) syntax, knowing roughly what the DTD is and how to
validate, and some idea of when to use what tag.
You could go into what different broken browsers do with deprecated
presentational attributes or how they repair invalid HTML but it's
easier for the author starting out today just to stay out of that swamp
altogether.
A lot of the bad HTML on the web is because people selling authoring
tools told people HTML-by-hand was too hard (and then their tools output
even more clueless and broken HTML anyway).
Ben C
I don't want to get into a programming language war here, but I like
JavaScript, in fact better than Java (which I think is what JSF &
Facelets are).
AD knows his stuff and JSF and Facelets may be a good way to do what
he's doing but there's nothing intrinsically better about the Java
_language_.
The value of static typing and object-oriented straitjackets as silver
bullets is widely discredited these days.
Andy Dingley
> I suppose that on the one hand you can say that JavaScript is
> overused; but on the other hand, there are some of us who believe
> (correctly so) that it is a powerful and severely underutilized
> programming environment.
JavaScript isn't the environment, it's just the one credible choice we
have to use in that environment. If you want to write client-side
stuff, you're stuck with it.
As a language, it's still ugly.
Andy Dingley
> I don't understand something...why don't all you purists on these
> newsgroups write the perfect book, then?
Because it's a load of work to write a book and the money for doing so
is awful, unless it's the one book that's a runaway success, and it's
not your first book (contracts tend to be tighter for unproven
authors).
As a HTML book, I recommend Head First HTML for learning it and the
W3C spec for reference. That's all the HTML books anyone needs. CSS
needs a few more, as does JavaScript. There _are_ good books out there
already (so why write another one?), it's just that people persist in
buying, reading and believing the crappy ones.
Andy Dingley
> JSF and Facelets may be a good way to do
Pretty much the best current way for high-end server-side work with
lots of UI.
> there's nothing intrinsically better about the Java _language_.
Certainly not. Where Java wins is in the _huge_ volume of stuff around
it that isn't "language" as such. Show me Struts or Hibernate for .NET
or, &deity; forbid, PHP.
Also the level of discourse in Java shops is simply higher - Design
Patterns are a topic of standard usage, not something regarded as
esoteric theory. Maybe Lisp / Scheme or Python have something similar.
How many .NET coders are going to routinely discuss the relative
merits of lambda or closures? To quote Dan Brickley, "...because all
the smart kids are using Java". Good people are using Java, this
encourages the rest of the Java world to keep up.
beegee
> On 17 May, 10:48, Ben C <spams...@spam.eggs> wrote:
>
> Also the level of discourse in Java shops is simply higher - Design
> Patterns are a topic of standard usage, not something regarded as
> esoteric theory.
From web conferences I've attended in the last couple of years, this
is certainly the opinion of java programmers. It's not true though.
What I've seen in Java shops and among Java programmers is a fear of
typeless and dynamic behavior in languages. The belief that as much
programming as possible should be done on the server is one that is
strong in the Java community, almost religious dogma but it is also
held in the .NET community, ROR community and any server side shop.
The most ridiculous conference I went to (Ajaxworld in NYC two years
ago) consisted of 90% java programmers trying to figure out which
framework addon they could use to avoid having anything to do with
javascript. They were on another planet.
>To quote Dan Brickley, "...because all
> the smart kids are using Java". Good people are using Java, this
> encourages the rest of the Java world to keep up.
This might have been true 15 years ago when C++ programmers were
making the jump to Java. Now, though, Java is all that is taught in
CS programs. It's the new Pascal, a teaching language. It's more
like "all the kids are learning Java". In short, Java smugness and
especially the antipathy to javascript comea solely from the deep but
buried knowledge in the Java community that Java has been proven to be
almost useless web client language, IMHO. Kind of language Napoleonic
complex.
I do agree with you that there's a lot of Java stuff out there. How's
that bone taste?
Bob
Andy Dingley
> On May 17, 3:11 pm, Andy Dingley <ding...@codesmiths.com> wrote:
> > Also the level of discourse in Java shops is simply higher -
> this is certainly the opinion of java programmers.
> It's not true though.
> What I've seen in Java shops and among Java programmers is a fear of
> typeless and dynamic behavior in languages.
I'd agree with that. The regular debate is, "Dynamic typing, just how
Evil is this?" As the one Python coder in a big Java shop, I'm right
in the middle of it.
As someone who has to support a multi-customer mega-app with instant-
response "Fix it Right Now!" SLAs, I'm also pretty glad that some of
it _isn't_ using dynamic typing.
>The belief that as much
> programming as possible should be done on the server is one that is
> strong in the Java community,
Less so with Facelets etc. The belief now is that you shouldn't
_write_ client-side code, but that if it's going to be there, it
should be generated automatically on the server.
> 90% java programmers trying to figure out which
> framework addon they could use to avoid having anything to do with
> javascript. They were on another planet.
So what's the problem with this? If it's a _good_ framework (and
they're only starting to emerge now) this gets your code written with
a fraction of the effort and _far_ less debug hassle.
We're an app that began in 2001, with a massively excessive use of
badly-done IE-only client-side JS. This does tend to make us shy of JS
for the simple reason that last time we used any, it sucked badly. As
little has moved forward amongst the people who wrote it then, writing
any more of it in the same way (i.e. by hand) would go the same way.
> Now, though, Java is all that is taught in
> CS programs. It's the new Pascal, a teaching language.
Sadly true - just read Spolsky's infamous "Java schools" tirade.
However this doesn't mean that the smart people aren't using it too.
> In short, Java smugness and
> especially the antipathy to javascript comea solely from the deep but
> buried knowledge in the Java community that Java has been proven to be
> almost useless web client language,
I'd disagree with that though. Today's Java generation don't even know
that there were Applets in the past.
VK
> The most ridiculous conference I went to (Ajaxworld in NYC two years
> ago) consisted of 90% java programmers trying to figure out which
> framework addon they could use to avoid having anything to do with
> javascript. They were on another planet.
They are not on another planet: they are in another camp and they are
fighting for their orders aka job positions aka the current way of
life. This fight is not bloody but very intensive with all available
tools being used. Can you really blame them for that? I cannot though
I am in the different camp. And reach web applications are getting
really mature during the last couple of years - and it means the death
to distributed Java applications which is by far the only segment of
the market left where Java retains some noticeable stock of shares -
plus some amount of corporate solutions from 90's being still on
amortization.
So I would expect the amount of users with Javascript disabled and
Flash player not installed "growing" worldwide every month in biased
stats as currently it is the only viable propaganda tool left.
beegee
> We're an app that began in 2001, with a massively excessive use of
> badly-done IE-only client-side JS. This does tend to make us shy of JS
> for the simple reason that last time we used any, it sucked badly. As
> little has moved forward amongst the people who wrote it then, writing
> any more of it in the same way (i.e. by hand) would go the same way.
There were very few javascript programmers in 2001, the preponderance
of javascript users were webbies who had no knowledge of design
patterns, best practices, data structures, OOP design etc. The folks
on this user group should have convinced you that things are different
now. My company has a legacy of badly written server side code, ASP
Visual Basic. We became convinced that a better user experience was
possible with an SOA architecture where .NET is used to write web
services and javascript in a MVC framework is used to write the client
side.
> I'd disagree with that though. Today's Java generation don't even know
> that there were Applets in the past.
I agree that the newer java generation doesn't have the unfortunate
knowledge of applets but the older generation does and I believe
that's where most of the 'smugness' comes from. Remember, the raison
d'etre for for Java at one time was "write once, compile many".
VK
> Remember, the raison
> d'etre for for Java at one time was "write once, compile many".
Correction: the motto was WORA ("Write Once Run Anywhere"). And then
signed applet with extended privileges NN4/IE4 compatible. Rghhh...
Still hate to recall...
Andy Dingley
> AD knows his stuff
Thanks! On CSS, you're one of the people I'd defer to - especially on
good aesthetic design with it.
Prisoner at War
>
>
> Right, and that's how it should be.
>
> I don't know what mastery involves beyond understanding the
> (straightforward) syntax, knowing roughly what the DTD is and how to
> validate, and some idea of when to use what tag.
Indeed, "mastery" is perhaps an inappropriate word to use with
something like HTML -- almost like applying the word to such
activities as house-cleaning or doing laundry...it was meant to be
accessible by one and all.
> You could go into what different broken browsers do with deprecated
> presentational attributes or how they repair invalid HTML but it's
> easier for the author starting out today just to stay out of that swamp
> altogether.
Yeah, I don't bother at all 'cause sooner than not just about everyone
will be using updated browsers that are standards-compliant.
> A lot of the bad HTML on the web is because people selling authoring
> tools told people HTML-by-hand was too hard (and then their tools output
> even more clueless and broken HTML anyway).
Yes, I actually did Hunter College's German Department's homepage back
in 1998, all ten or so pages of it, in HTML 3.2 with some publicly-
available JavaScript 1.1 code. No big deal, and I was surprised that
software was being sold to do something so easy.
Returning to this stuff after a ten-year hiatus has been very amusing,
seeing what's changed and what's remained the same. HTML is so easy
that after ten years of not having done any, I was able to scan
through my copy of one of Laura's Lemay's old titles and start doing
markup in about ten minutes, only occasionally referring to the web
for information on a few deprecated tags and attributes.
Prisoner at War
>
>
> Once Upon a Very Long Time Ago it was found that the number of bugs
> in programs was proportional to the number of program statements, and
> therefore Higher Level Languages were better than Good Old Assembler
> because HLLs required fewer statements.
You know, I wonder...is there anyone programming in machine language
at all?? Well, surely somebody is, since someone has to help
"translate" zeros and ones into even assembly language....
> Large numbers of modestly-talented Assembler programmers were perforce
> turned into modestly-talented HLL programmers. AFAIK the number of bugs
> stayed the same, they just got more strange and obscure.
Well, that's a very strange situation. The number of bugs stayed the
same? You mean proportionally, right? Hmm, maybe some kind of
principle or even law involved....
> I've been taking Web Design classes at the local Tech School. After
> suffering through Mucho Wordage and other M$-specific stuph I finally
> got to do some HTML coding, using Dreamweaver as a highly specialized
> text editor.
>
> After finishing the final project
> (http://enthusiasts.dyn-o-saur.com/MK-HTML-final/e_commerce.html)
Cute! You should use a JavaScript setTimeout() on the audio, though.
I like military music and horn signals but such things are annoying if
repeated when browsing back and forth. I've got an animated .gif on
my webpage that only run for about eight seconds and then stops -- and
I'll be writing a cookie function sooner or later to make sure the
animation is not played again (at least not during the current visit).
> I was told that now I had to do another batch of projects concentrating
> on using Dreamweaver's "Design" Feechur. I'm trying but I keep dropping
> into hand coding 'cause that's so much easier.
Yeah, I only use an HTML editor (KompoZer) to add text. That's all I
do with it! I like the word-processor-like aspect of content creation
in a WYSIWYG environment. But it's all strictly limited to text. I
much much much prefer adding in my own HTML tags and whatnot.
> When I use the design
> feature to do something the code it generates is large and *ugly* .
You know, I wonder why that is...I mean, I'm no programmer at all but
even I can "see" how it's possible to write an WYSIWYG HTML editor
that generates clean standards-compliant code that's also "elegant."
I mean, it's HTML, ferchrissake!
> Maybe I'm old-fashioned but I've found that a pretty program runs
> better.
> (By the way, I can read a text label a lot faster than I can figure out
> what those damned little icons are supposed to represent. And, of
> course, that's not one of the available options.)
Makes me think of Chinese...you know, that's what Chinese characters
were, originally -- just icons, pictures, representing various objects
and actions....
> --
> -- Marten Kemp
> (Fix name and ISP to reply)
Prisoner at War
>
>
> I don't want to get into a programming language war here, but I like
> JavaScript, in fact better than Java (which I think is what JSF &
> Facelets are).
>
> AD knows his stuff and JSF and Facelets may be a good way to do what
> he's doing but there's nothing intrinsically better about the Java
> _language_.
>
> The value of static typing and object-oriented straitjackets as silver
> bullets is widely discredited these days.
I really like JavaScript, too, though at first I was confused by the
lack of "straitjackets" because that's what I had had experience with
ever since a course in Commodore Pet-32 BASIC as a kid and then
another programming course in college in Turbo Pascal. (Yep, that's
all the "programming" experience I'd ever had; I did good in those
courses but it was clear even to me that I'm no programmer as things
take a very long time to sink in and the only reason I got good grades
[and not great grades -- "B" as opposed to "A"] was because I studied
a lot.)
But even though I'm only like half-way to a merely intermediate level
of competency in JavaScript I'm already looking forward to PHP,
Python, and even Java. I'm not sure how "serious" I'd get about them
but I'm interested in how they may help me do things with my upcoming
website. For example, PHP because I want to host a PHP forum...Python
and Java to see if I can add some kind of interactive gaming to the
site (though I plan on using JavaScript for an interactive game, too
-- only, a very simple and simplistic one)....
Prisoner at War
>
> <SNIP>
>
> So I would expect the amount of users with Javascript disabled and
> Flash player not installed "growing" worldwide every month in biased
> stats as currently it is the only viable propaganda tool left.
Huh??
What do you mean "propaganda tool"??
And why would the amount of people disabling JavaScript and not having
Flash player installed be growing every month??
Prisoner at War
>
>
> <SNIP>
>
> Sadly true - just read Spolsky's infamous "Java schools" tirade.
> However this doesn't mean that the smart people aren't using it too.
Something is definitely in the air...I mean, we had G.W. for President
twice....
I can relate to Spolsky's rant because I remember in a college
creative writing course professors no longer penalized would-be
writers for their spelling and grammar (and they weren't trying to be
"experimental" on those counts, either). Simple stuff like not
distinguishing between "your" and "you're" and "Nazis" and
"Nazi's"...and mistaking "should of" (no such term) for
"should've"...or not knowing a run-on sentence from merely a *long*
sentence full of commas, semi-colons, and colons (and, speaking of
which, not know when to use a colon, semi-colon, comma, or
period!)....
It's definitely something in the air...the whole culture is
changing...the funny thing is, people will most likely continue to be
smarter and smarter, for all our justified complaints about lax
standards....
> I'd disagree with that though. Today's Java generation don't even know
> that there were Applets in the past.
You know, I was just wondering in that other thread on Java in CLJ why
I don't see applets no more....
Peter Michaux
> On May 16, 9:15 pm, Andy Dingley <ding...@codesmiths.com> wrote:
> I don't understand something...why don't all you purists on these
> newsgroups write the perfect book, then?
I wondered the same thing when I first started reading c.l.js.
Browser scripting is such a complex topic to treat fully. Just writing
a cross-browser, gracefully degrading JavaScript menu widget would
take an entire book on it's own if the book was written for a novice.
I doubt anyone will buy that book because the don't learn enough
widgets and the depth of the content would be too deep for a novice.
There is still a perception that browser scripting is supposed to be
easy and if the author doesn't make it seem that way then the book
must be the "wrong" one to buy.
John Resig posted a payment statement for his first book. If I
remember correctly, he had made something like a couple thousand
dollars for the months he spent writing the book. It just isn't worth
it when you consider an experienced JavaScript contractor may be
making up to $150/hr.
Peter
Peter Michaux
> Well, in case anyone should need to know in the near future, here are
> my recommendations for best beginner's books:
>
> ** Head First HTML with CSS & XHTML, Head First JavaScript **
Get it from the library. I cannot imagine needing to own an HTML book.
There are plenty of good references on the web. Understand that XHTML
is not for the general web. HTML is a better option.
I own Eric Meyer's "CSS: The Definitive Guide" and am glad that I do.
It is the best definitive guide I've read on any web topic.
"Bullet Proof Web Design" is the best book I've seen for learning
semantic HTML and separation of HTML and CSS. It is a really good
book. I borrowed it from the library.
Borrow "CSS Zen Garden" for some nice inspiration about what
separation of content and presentation can do.
Bookmark the w3c HTML and CSS validator web pages. Also bookmark the
HTML and CSS specifications.
David Flanagan's "JavaScript: The Definitive Guide" is still the best
JavaScript/Browser scripting reference I've read even with the errata.
There are lots of good ideas in other books but there are so many
flaws in all of the one's I've seen.
Print a copy of ECMAScript third edition pdf and study it at least
enough so you can find information when you need it.
Use JSLint for a while until you know what rules you like and don't
like.
Peter
Prisoner at War
> On 17 May, 03:24, Prisoner at War <prisoner_at_...@yahoo.com> wrote:
>
> > I don't understand something...why don't all you purists on these
> > newsgroups write the perfect book, then?
>
> Because it's a load of work to write a book and the money for doing so
> is awful, unless it's the one book that's a runaway success, and it's
> not your first book (contracts tend to be tighter for unproven
> authors).
>
> As a HTML book, I recommend Head First HTML for learning it
But I'd mentioned just that!
> and the
> W3C spec for reference. That's all the HTML books anyone needs. CSS
> needs a few more, as does JavaScript. There _are_ good books out there
> already (so why write another one?), it's just that people persist in
> buying, reading and believing the crappy ones.
I'm not sure how people can "believe" in a "crappy" one...I think
people "persist in buying" because they're still looking for a good
one that will enlighten them, which hardly suggests "belief"....
But I *believe* in the titles I'm recommending, even David Thau's
work, "The Book of JavaScript, Second Edition" which is problematic in
purist terms but which is the most helpful "semi-traditional-approach"
sort of text I know (and I've been heavily browsing a lot of 'em at
the bookstore and the library).
But the two Head First titles and "DOM Scripting," definitely. In
fact, it would be absolutely wonderful to see an "Head First"
treatment of the "DOM Scripting" book....
Prisoner at War
>
>
> I wondered the same thing when I first started reading c.l.js.
LOL! I'm surprised this question isn't in the FAQ!
> Browser scripting is such a complex topic to treat fully. Just writing
> a cross-browser, gracefully degrading JavaScript menu widget would
> take an entire book on it's own if the book was written for a novice.
> I doubt anyone will buy that book because the don't learn enough
> widgets and the depth of the content would be too deep for a novice.
> There is still a perception that browser scripting is supposed to be
> easy and if the author doesn't make it seem that way then the book
> must be the "wrong" one to buy.
That's what's especially appealing about the Head First series...while
not perfect ("don't-worry-about-this-right-now-we'll-cover-it-later-
just-ignore-it-while-I-use-it-to-make-something-work"), its genius is
in keeping the newbie awake (and by "newbie" I mean "programming
newbie" and not a programmer that's simply new to JavaScript)...you're
much better able to grok things when you're awake, after all....
"DOM Scripting" is also a very, very, very, very good book -- though
not quite for a complete newbie (though I would recommend it as a kind
of "reference companion" to the Head First titles), it really lays
things out in a very clear way, with none of that annoying don't-worry-
about-this-right-now-we'll-cover-it-later-just-ignore-it-while-I-use-
it-to-make-something-work stuff so often encountered in other titles.
I think those three books make things look easy while cultivating an
appreciation of powerful possibilities...I'm really impressed with
them because they don't read like manuals or textbooks but truly as
introductions, almost love letters (!), if I may be so bold...I think
a newbie with an interest in the subjects covered by those books will
wind up even more interested and motivated. That's the thing most how-
to books don't seem to understand: they presume interest on the part
of the reader but then take that interest for granted and go on to
kill the interest by failing to cultivate it. I mean, imagine
learning English by reading the dictionary...that's how a lot of books
seem to teach things (and no, simply writing in a style like your my
buddy e-mailing me isn't all there is to cultivating interest).
Frankly, a lot of books teach like a lot of professors -- they just
regurgitate. Just goes to show what true stupidity is!
> John Resig posted a payment statement for his first book. If I
> remember correctly, he had made something like a couple thousand
> dollars for the months he spent writing the book. It just isn't worth
> it when you consider an experienced JavaScript contractor may be
> making up to $150/hr.
I really wonder about this "worth it" mentality...first of all, you
simply don't know; there's just no telling. I mean, can you say
"Harry Potter"?? I still can't get over how such ridiculous garbage
(which I would have loved as a kid) can win over so many adults.
But more to the point, what ever happened to labors of love? I mean,
heck, look at all the free consulting given on these newsgroups,
then! ^_^
Many -- maybe even most -- such books seem to be just "me-too" knock-
offs by publishers greedy to make money off hot trends. But many are
genuinely helpful and instructive. Like the ones I'd listed. Though
I think the authors deserve a nice profit, maybe from a "bird's-eye-
view" it's actually a good thing that not much money is to be made
from writing...helps keep out the riff-raff, of which there is enough
already.
I mean, look at all the free programs available, like KompoZer, GIMP,
Inkscape, Audacity...the list just seems to go on and on and on and on
and on...I really do look forward to a Star Trek future of plenty
where people no longer do things for money -- and though that won't be
for another 300-500 years, it's some consolation to have a very small
glimpse of it right now through the best of what the internet has to
offer.
> Peter
Prisoner at War
>
>
> Get it from the library. I cannot imagine needing to own an HTML book.
> There are plenty of good references on the web.
Yes, but that's like saying, get your free meals at a soup kitchen.
Plenty of places where you can get free food.
It just isn't the same having a real book with you on the toilet, in
the subway, by the beside...and no, printouts won't cut it, either. I
think the very feel of paper, and all the other sensory stimuli, help
learning (or can, anyway, if only people wisened up to the fact). And
yes HTML is easy, and so is CSS, really (though much "harder" than
HTML, to be sure), but unless you have photographic memory or
something, it's good to have a resource handy which doesn't require
booting up the computer or waking it up from hibernation.
> Understand that XHTML
> is not for the general web. HTML is a better option.
HTML itself is supposed to be deprecated sooner or later...XHTML seems
similar enough (at least with regards to the markup I need to do for
myself) that I don't see what the problem is....
> I own Eric Meyer's "CSS: The Definitive Guide" and am glad that I do.
> It is the best definitive guide I've read on any web topic.
>
> "Bullet Proof Web Design" is the best book I've seen for learning
> semantic HTML and separation of HTML and CSS. It is a really good
> book. I borrowed it from the library.
I've heard about these, and will check them out in the library. Mind
you, I'd first checked out most of these book that I own at/from the
library before purchasing them.
> Borrow "CSS Zen Garden" for some nice inspiration about what
> separation of content and presentation can do.
Yep, already on my list!
> Bookmark the w3c HTML and CSS validator web pages. Also bookmark the
> HTML and CSS specifications.
Already done!
> David Flanagan's "JavaScript: The Definitive Guide" is still the best
> JavaScript/Browser scripting reference I've read even with the errata.
I browsed this at the library but because it did not seem much of a
"tutorial" but a "reference work" I decided I would consult it later.
> There are lots of good ideas in other books but there are so many
> flaws in all of the one's I've seen.
Have you seen "Head First JavaScript" and "DOM Scripting"? Not too
many "flaws" -- I don't think there's even one in the latter!
> Print a copy of ECMAScript third edition pdf and study it at least
> enough so you can find information when you need it.
Hmmm, "ECMAScript Third Edition"?? Oh, you mean the "language
specifications"...the "white paper"...thanks, but that's too
"clinical" for me -- and the typical newbie!
> Use JSLint for a while until you know what rules you like and don't
> like.
Hey, cool! A JavaScript validator??? How's that work, I wonder!
But what do you mean by "what rules you like and don't like"?? It's
JavaScript 1.3, init -- take it or leave it!
> Peter
Peter Michaux
wrote:
> On May 19, 12:12 am, Peter Michaux <petermich...@gmail.com> wrote:
>
> > Get it from the library. I cannot imagine needing to own an HTML book.
> > There are plenty of good references on the web.
>
> Yes, but that's like saying, get your free meals at a soup kitchen.
> Plenty of places where you can get free food.
>
> It just isn't the same having a real book with you on the toilet,
The last guy who borrowed the book from the library probably read it
on the toilet too.
> in
> the subway, by the beside...and no, printouts won't cut it, either. I
> think the very feel of paper, and all the other sensory stimuli, help
> learning
My printouts are on paper.
> (or can, anyway, if only people wisened up to the fact). And
> yes HTML is easy, and so is CSS, really (though much "harder" than
> HTML, to be sure), but unless you have photographic memory or
> something, it's good to have a resource handy which doesn't require
> booting up the computer or waking it up from hibernation.
I do like paper references. I have two feet of books on my desk now. I
just think that after reading an HTML book for a three week loan
period the online references are handy enough.
> > Understand that XHTML
> > is not for the general web. HTML is a better option.
>
> HTML itself is supposed to be deprecated sooner or later
Nope. Google "HTML 5".
> ...XHTML seems
> similar enough (at least with regards to the markup I need to do for
> myself) that I don't see what the problem is....
It is quite similar but not the same as many people think.
> > I own Eric Meyer's "CSS: The Definitive Guide" and am glad that I do.
> > It is the best definitive guide I've read on any web topic.
>
> > "Bullet Proof Web Design" is the best book I've seen for learning
> > semantic HTML and separation of HTML and CSS. It is a really good
> > book. I borrowed it from the library.
>
> I've heard about these, and will check them out in the library. Mind
> you, I'd first checked out most of these book that I own at/from the
> library before purchasing them.
>
> > Borrow "CSS Zen Garden" for some nice inspiration about what
> > separation of content and presentation can do.
>
> Yep, already on my list!
>
> > Bookmark the w3c HTML and CSS validator web pages. Also bookmark the
> > HTML and CSS specifications.
>
> Already done!
>
> > David Flanagan's "JavaScript: The Definitive Guide" is still the best
> > JavaScript/Browser scripting reference I've read even with the errata.
>
> I browsed this at the library but because it did not seem much of a
> "tutorial" but a "reference work" I decided I would consult it later.
>
> > There are lots of good ideas in other books but there are so many
> > flaws in all of the one's I've seen.
>
> Have you seen "Head First JavaScript" and "DOM Scripting"? Not too
> many "flaws" -- I don't think there's even one in the latter!
While in a bookstore, I read a book called "Bulletproof Ajax" by the
author of "DOM Scripting". I thought that Bulletproof Ajax does have
errors and suggests poor practices. I don't have a copy so I can't
provide examples. I do know I can go to the Bulletproof Ajax website
and create errors by clicking on things too early. I believe in Hijax
and that Jeremy Keith has explained the concept well but the
window.onload problem wasn't handled correctly in the code.
> > Print a copy of ECMAScript third edition pdf and study it at least
> > enough so you can find information when you need it.
>
> Hmmm, "ECMAScript Third Edition"?? Oh, you mean the "language
> specifications"...the "white paper"...thanks, but that's too
> "clinical" for me -- and the typical newbie!
Yes but you can ease into it.
> > Use JSLint for a while until you know what rules you like and don't
> > like.
>
> Hey, cool! A JavaScript validator??? How's that work, I wonder!
It parses the code and analyses it instead of executing it.
> But what do you mean by "what rules you like and don't like"??
Douglas Crockford wrote JSLint. I think some of the things he
classifies as warnings are actually good practices. For example,
assignment in an if statement's conditional is a very nice thing to do
sometimes. He suggests eval is evil but there are quite a few advanced
things you cannot do any other way efficiently.
> It's
> JavaScript 1.3, init -- take it or leave it!
More likely JavaScript 1.5. JSLint is not just a validation tool. It
is Douglas Crockford standing over your shoulder wagging his finger at
you when you do something he thinks is a poor practice. This sort of
peer review is great as it makes one reflect on his own practices. The
advice should not be taken without thinking about it first.
Peter
Ben C
> On May 17, 5:48 am, Ben C <spams...@spam.eggs> wrote:
> (though I plan on using JavaScript for an interactive game, too --
> only, a very simple and simplistic one)....
Just to give you an idea of what's possible:
Henry
> On May 19, 12:12 am, Peter Michaux wrote:
<snip>
>> There are lots of good ideas in other books but there are
>> so many flaws in all of the one's I've seen.
>
> Have you seen "Head First JavaScript" and "DOM Scripting"?
> Not too many "flaws" -- I don't think there's even one in
> the latter!
So you did fail to grasp the point about what exactly it is about
these books that you (as someone who is 'learning' form these books)
are in a position to judge. How would you recognise a flaw? Where
would you get the knowledge and experience necessary? Because you will
not getting that from the books themselves.
Consider that you posted the mark-up:-
<img name="image" id="image" src=pic1.gif"
onMouseOver="document.getElementById('image').src='pic2.gif';"
onMouseOut="document.getElementById('image').src='pic1.gif';" />
- in a recent thread here. And even though the scripting there is
minimal that code is still a formulation for which there are two
better alternatives. You have not used the better alternatives because
your books have failed to inform you that they exist or failed to
inform you of how/why they would be better. That is a flaw, but it is
a flaw of omission, and you will not learn about an omission from the
text that omits.
joebloe
> John Resig posted a payment statement for his first book. If I
> remember correctly, he had made something like a couple thousand
> dollars for the months he spent writing the book. It just isn't worth
> it when you consider an experienced JavaScript contractor may be
> making up to $150/hr.
The reason you write a book is for recognition, or just because you
feel like it. As a matter of personal experience, Effective Perl
Programming got me years of onsite training gigs paying gross in
multiple hundreds of dollars per hour.
joebloe
> On 2008-05-19, Prisoner at War <prisoner_at_...@yahoo.com> wrote:
>
> > On May 17, 5:48 am, Ben C <spams...@spam.eggs> wrote:
> [...]
> > (though I plan on using JavaScript for an interactive game, too --
> > only, a very simple and simplistic one)....
>
> Just to give you an idea of what's possible:
>
> http://www.janis.or.jp/users/segabito/JavaScriptMaryo.html
This is cool, but Javascript is capable of supporting *much* more
complex games than that. In particular, code that doesn't manipulate
the DOM now runs quite quickly (I mean, with a multiple GHz CPU, how
would it not? There's only so much overhead you can layer onto
arithmetic, strings, and loops), and you can put a whole lot of logic
in 100k+ bytes of minified code. Also, how you make your DOM updates
makes a big difference. And finally, the next generation of browsers
are going to have much more efficient JS interpreters.
Thomas 'PointedEars' Lahn
> On May 18, 9:01 pm, Peter Michaux <petermich...@gmail.com> wrote:
>> John Resig posted a payment statement for his first book. If I
>> remember correctly, he had made something like a couple thousand
>> dollars for the months he spent writing the book. It just isn't worth
>> it when you consider an experienced JavaScript contractor may be
>> making up to $150/hr.
>
> The reason you write a book is for recognition, or just because you
> feel like it.
Yes, competence seldom enters into it.
F'up2 cljs
PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>
Andy Dingley
> The reason you write a book is for recognition, or just because you
> feel like it.
You've still got to pay the rent in the meantime.
Andy Dingley
> On May 19, 12:12 am, Peter Michaux <petermich...@gmail.com> wrote:
> > Understand that XHTML
> > is not for the general web. HTML is a better option.
>
> HTML itself is supposed to be deprecated sooner or later...XHTML seems
> similar enough
I thought you'd read Head First HTML? It's one of the few books that
gets this aspect right, and it certainly isn't how you describe.
joebloe
If you can't write your first book or three in your spare time, you're
probably not going to write a book.
joebloe
> On May 18, 10:24 pm, Prisoner at War <prisoner_at_...@yahoo.com>
> wrote:
> > HTML itself is supposed to be deprecated sooner or later
>
> Nope. Google "HTML 5".
>
> > ...XHTML seems
> > similar enough (at least with regards to the markup I need to do for
> > myself) that I don't see what the problem is....
>
> It is quite similar but not the same as many people think.
XHTML was DOA. Hard to figure what the point was anyway. Does less,
broken in every browser.
Being able to flow text between DIVs would beat the heck out of a new
arrangement of /'s. Just my $.02.
Thomas 'PointedEars' Lahn
> On May 18, 11:22 pm, Peter Michaux <petermich...@gmail.com> wrote:
>> On May 18, 10:24 pm, Prisoner at War <prisoner_at_...@yahoo.com>
>> wrote:
>>> HTML itself is supposed to be deprecated sooner or later
>> Nope. Google "HTML 5".
"HTML 5", however, is a subject of its own.
>>> ...XHTML seems
>>> similar enough (at least with regards to the markup I need to do for
>>> myself) that I don't see what the problem is....
>> It is quite similar but not the same as many people think.
>
> XHTML was DOA. Hard to figure what the point was anyway. Does less,
> broken in every browser.
Is this just a statement or is it an argument for which you can provide
evidence to back it up?
> Being able to flow text between DIVs would beat the heck out of a new
> arrangement of /'s. Just my $.02.
This would be presentational, so nothing a markup language should provide.
For example, Gecko supports the -moz-column-count property in CSS (used in
Wikipedia) that goes in that direction.
Followups trimmed to ciwah/s.
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
Andy Dingley
You can't write (most) IT books in your spare time, publishing
timescales don't permit it. They need that ms _now_, before the
competition gets their book out on the hot new topic.
Maybe for HTML, CSS or JavaScript this timescale is more relaxed.
They've been around 10 years and most of the decent books have only
emerged fairly recently.
Andy Dingley
> > Sadly true - just read Spolsky's infamous "Java schools" tirade.
> > However this doesn't mean that the smart people aren't using it too.
>
> Something is definitely in the air...I mean, we had G.W. for President
> twice....
You blame Bush being an idiot on him having learned _Java_?! That's
pretty extreme.
joebloe
> You can't write (most) IT books in your spare time, publishing
> timescales don't permit it. They need that ms _now_, before the
> competition gets their book out on the hot new topic.
>
> Maybe for HTML, CSS or JavaScript this timescale is more relaxed.
> They've been around 10 years and most of the decent books have only
> emerged fairly recently.
This is entirely untrue in the case of reputable publishers like A-W
and PH. I've dealt with editors there for 10 years and they do *not*
work like that. You are simply wrong. I can't overemphasize how wrong
you are. You can't even do tech reviews, copy editing, proofreading,
cover (which the author will approve), and layout (which the author
also will approve) in that amount of time. Quality publishers do
produce books on emerging technologies on a timely basis, but that's
because the experts who are creating that technology are the ones
writing books for them.
If you're talking about books with thick fluorescent green spines,
yes, those publishers do work that way and they want books written in
about 3 months. But on the other hand they don't care if the book is
accurate or even if it makes sense. They really don't do technical
review, and the copy editing and proofreading are cursory. I used to
informally measure the quality of that kind of book by counting the
number of pages per major error, as in, something the author got wrong
in a way that would mislead a reader and/or demonstrated the author's
lack of understanding. Somewhere between 4 and 10 pages was typical.
Usually 4.
Andy Dingley
> I've dealt with editors there for 10 years and they do *not*
> work like that. You are simply wrong. I can't overemphasize how wrong
> you are.
Can I give you my editor's email address? 8-)
All I know is that _I'm_ under pressure with a deadline. As my Mother
died recently and my elderly Dad has now decided he's a teapot, this
isn't making life any easier.
Prisoner at War
>
>
> The reason you write a book is for recognition, or just because you
> feel like it. As a matter of personal experience, Effective Perl
> Programming got me years of onsite training gigs paying gross in
> multiple hundreds of dollars per hour.
Hey, congrats! I've always thought that the reason people write
technical how-to books was the same reason people put up technical how-
to websites: as a kind of calling card, or "interactive resume"....
Prisoner at War
>
>
> You blame Bush being an idiot on him having learned _Java_?! That's
> pretty extreme.
Whot??
I'm just saying that it's probably the Zeitgeist that folks are no
longer required to do the "hard stuff" -- even one of the most
powerful people on the planet! The American voter doesn't do anything
intellectually rigorous him or herself, so naturally s/he doesn't
think to inquire whether a candidate has done it either...that was
Spolsky's point, only as related to CS grads, whereas I'm saying "it's
something in the air" 'cause almost everyone's like that....
Prisoner at War
>
>
> Just to give you an idea of what's possible:
>
> http://www.janis.or.jp/users/segabito/JavaScriptMaryo.html
OMG!!! That's **JavaScript**?????
Hey, what the hell, how come none of 'em JavaScript books cover this
stuff???
I might not need Python for anything after all! ^_^
BTW...how am I supposed to play this thing?? Any keyboard controls??
Everything's in Japanese....
Prisoner at War
>
>
> >http://www.janis.or.jp/users/segabito/JavaScriptMaryo.html
>
> This is cool, but Javascript is capable of supporting *much* more
> complex games than that.
Hey, any JavaScript game-programming books you know??? How cow, and I
thought Ben's little help balloon was cool.... ;-)
>In particular, code that doesn't manipulate
> the DOM now runs quite quickly (I mean, with a multiple GHz CPU, how
> would it not? There's only so much overhead you can layer onto
> arithmetic, strings, and loops), and you can put a whole lot of logic
> in 100k+ bytes of minified code.
I never did understand all that stuff about "overhead" (not that I'm a
programmer at all)...**multi-billions** of calculations a second and
we're worried about "overhead"???
> Also, how you make your DOM updates
> makes a big difference. And finally, the next generation of browsers
> are going to have much more efficient JS interpreters.
Damn, wish I could follow the conversation....
Any books on programming JavaScript to do games??
So is JavaScript a "full-fledged" programming language now?? I always
thought it was just a glorified macro for web-browsers, like macros in
word-processors.
joebloe
wrote:
> So is JavaScript a "full-fledged" programming language now?? I always
> thought it was just a glorified macro for web-browsers, like macros in
> word-processors.
JavaScript has been a real programming language for years, but for a
variety of reasons (the most obvious of which being the hobbled,
incompatible IE implementations) it has rarely been used for anything
exotic. Gmail was the first app that caught the mainstream attention.
But at the same time the rich text editors like Writely (http://
www.techcrunch.com/2005/08/31/writely-process-words-with-your-browser/
now part of Google apps - but they still call it "Writely" inside
Google) were being written.
Jason S
> More likely JavaScript 1.5. JSLint is not just a validation tool. It
> is Douglas Crockford standing over your shoulder wagging his finger at
> you when you do something he thinks is a poor practice. This sort of
> peer review is great as it makes one reflect on his own practices. The
> advice should not be taken without thinking about it first.
>
> Peter
...which brings up his new book "Javascript: the Good Parts"
http://www.amazon.com/exec/obidos/ASIN/0596517742/wrrrldwideweb.
Maybe not a book for novices, but it does point out a number of
(possible) best practices + some interesting core-language arcana.
I also have a copy of "PPK on Javascript" which is just about at the
other end of the spectrum: very focused on practical website use of
Javascript (whereas "Javascript: the Good Parts" is almost a pure
language book w/ next to nothing about websites) w/o much complexity.
Both point out subtleties about the language, but in different ways. I
like both because they are *not* like many of the alternatives, which
are usually just a bunch of code listings for stupid little useless
web pages, and which seem to expect you to learn by copycat techniques.
Ben C
First click on the green writing on the centre left (it says "shortest
clear DEMO"). DEMO is in English.
Then you get taken to another screen full of instructions in Japanese.
Press the big button in the middle with blue writing on it. It says
"Watch the shortest course replay (7317 frames)!".
Now it appears to go back to the main screen, but "Maryo" (which I take
it is the cat's name) runs off to the right and starts dashing through
the level. You're watching a replay of someone who's had far too much
practice.
But now if you click the button in the top left with red writing on it
that stops the replay, and you can actually play the game yourself.
There may some other way in but I haven't found it.
Use the arrow keys or S,F,E,D for left right up and down (up to climb
things, down to go down pipes or to duck).
SHIFT or SPACE is jump. Ctrl is the button for running fast and throwing
fireballs (if you manage to get your hands on a flower).
Prisoner at War
>
>
> The last guy who borrowed the book from the library probably read it
> on the toilet too.
Ah, the interconnectedness of one and all!
> My printouts are on paper.
Speaking of toilets, that's really wasteful, don't you think? ;-)
No, seriously, printing things out have got to be really wasteful,
compared to a book (heck, just look at how many unworthy books there
are out there, not even counting the self-published ones!).
> I do like paper references. I have two feet of books on my desk now. I
> just think that after reading an HTML book for a three week loan
> period the online references are handy enough.
They are -- but you've got to go boot up the computer first...just to
look something up?? Nah. Even when solid state hard drives are the
norm and we get somewhat of an instant-on as a result, I'd think it's
still an inelegant solution. I mean, we're talking about the
equivalent of looking up a word in the dictionary.
> Nope. Google "HTML 5".
Yes, I know HTML will still be around for a while, at least, but the
W3C's plan, from what I understand, is that ideally HTML would be
deprecated.
> It is quite similar but not the same as many people think.
Depends on what you mean by "the same"...as simple markup, in practice
it certainly feels the same (and I don't mean anything fancier than
plain markup -- no server-side what's-its and so forth).
> While in a bookstore, I read a book called "Bulletproof Ajax" by the
> author of "DOM Scripting". I thought that Bulletproof Ajax does have
> errors and suggests poor practices. I don't have a copy so I can't
> provide examples. I do know I can go to the Bulletproof Ajax website
> and create errors by clicking on things too early. I believe in Hijax
> and that Jeremy Keith has explained the concept well but the
> window.onload problem wasn't handled correctly in the code.
Hmmm, that does sound awful.
God, why is it so hard to write something *right*?? Jeez, I mean how
hard can it be -- people agree on standards and best practices and
things are all documented...no one ever complains about a nuclear
physics textbook being full of technical flaws, do they...how come
computer programming books are full of errors????
> Yes but you can ease into it.
Not as a n00b! I don't even understand it!
> It parses the code and analyses it instead of executing it.
But...it can't be very reliable, can it...I mean, sounds like some
artificial intelligence would be needed to really parse something
(that is, deal with semantics, intent)....
> Douglas Crockford wrote JSLint. I think some of the things he
> classifies as warnings are actually good practices. For example,
> assignment in an if statement's conditional is a very nice thing to do
> sometimes. He suggests eval is evil but there are quite a few advanced
> things you cannot do any other way efficiently.
Hmmm, computer science stuff, eh...can't wait until I understand the
issues one day!
> More likely JavaScript 1.5. JSLint is not just a validation tool. It
> is Douglas Crockford standing over your shoulder wagging his finger at
> you when you do something he thinks is a poor practice. This sort of
> peer review is great as it makes one reflect on his own practices. The
> advice should not be taken without thinking about it first.
Well, I don't plan on doing anything too fancy...simple if/else sort
of adventure games, no big deal from a technological perspective --
but many thanks for the ref; it's really good to know.
> Peter
Prisoner at War
>
>
> XHTML was DOA. Hard to figure what the point was anyway. Does less,
> broken in every browser.
Wow, really?? DOA?? Does less??? Broken in every browser????
I'm not sure about the point myself, but then again I'm a n00b so all
technical details just don't register with me.
> Being able to flow text between DIVs would beat the heck out of a new
> arrangement of /'s. Just my $.02.
See, there you go again with those technical details!
Prisoner at War
>
>
> <snip>
>
> So you did fail to grasp the point about what exactly it is about
> these books that you (as someone who is 'learning' form these books)
> are in a position to judge. How would you recognise a flaw? Where
> would you get the knowledge and experience necessary? Because you will
> not getting that from the books themselves.
True. My perspective of a "flaw" as a newbie, however, is somewhat
different than yours: I count the highest good of a how-to book to be
that it teaches me things which work. If the code runs, it's not a
flaw, though certainly one may argue that it's an inelegant solution
or even a dangerous one leading to problems in other contexts (etc.).
My second criterion for such a book, WRT "flaws," concern intangibles
like whether I am inspired to learn more, whether I feel like I can
tackle more learning, and whether I feel like I've been given a "fair
picture" of what's involved. And those things just can't be
quantified or pointed to...it's a gut feeling. So, for example, a
reference manual like David Flanagan's definitive guide may be full of
correct information and best practices, but it does me no good if it's
in Swahili -- which JavaScript to a real ("complete" -- i.e., non-
programmer) n00b may as well be.
> Consider that you posted the mark-up:-
>
> <img name="image" id="image" src=pic1.gif"
> onMouseOver="document.getElementById('image').src='pic2.gif';"
> onMouseOut="document.getElementById('image').src='pic1.gif';" />
>
> - in a recent thread here. And even though the scripting there is
> minimal that code is still a formulation for which there are two
> better alternatives.
I'm glad you brought this one up; you see, as a n00b I am impressed
that the thing works at all. I would say that that there is
"flawless," whatever "less-intrusive" CSS solution there may be. To
me, that bit of code/script/markup/whatever is the equivalent of
telling a girl "I want to fuck you now" instead of "so what are you
doing this weekend?" and other such beating around the bush (uh, no
pun intended). A n00b wants things direct. (Well, a guy n00b,
anyway, if we're talking about sex -- but computer programming seems a
vaguely equivalent situation!)
> You have not used the better alternatives because
> your books have failed to inform you that they exist or failed to
> inform you of how/why they would be better. That is a flaw, but it is
> a flaw of omission, and you will not learn about an omission from the
> text that omits.
Yes, you're right, but that's why these books are for newbies -- they
address a newbie's biggest concern, how to get something up and
running. If you're hungry, really hungry, you usually don't
particularly care how many calories something's got, or that it's
deficient in many micronutrients, or that it's not the gourmet
version, or even that it was cooked half an hour ago....
Prisoner at War
>
>
> I thought you'd read Head First HTML? It's one of the few books that
> gets this aspect right, and it certainly isn't how you describe.
No, I didn't learn that from "Head First HTML"...I learned that from
the W3C! Isn't that their aim, to deprecate HTML?
dorayme
<8ccc69cf-c1d7-4db9...@z66g2000hsc.googlegroups.com>,
Prisoner at War <prisone...@yahoo.com> wrote:
No, it was not their aim to deprecate HTML. The only people I know that
want to do this are Iranian mullahs.
--
dorayme
Scott Bryce
Prisoner at War wrote:
> On May 19, 2:22 am, Peter Michaux <petermich...@gmail.com> wrote:
>> I do like paper references. I have two feet of books on my desk
>> now. I just think that after reading an HTML book for a three week
>> loan period the online references are handy enough.
>
> They are -- but you've got to go boot up the computer first...just to
> look something up??
If I need to look up something in an HTML reference, it is because I am
writing HTML. In all likelihood, my computer is already booted up.
Scott Bryce
> True. My perspective of a "flaw" as a newbie, however, is somewhat
> different than yours: I count the highest good of a how-to book to be
> that it teaches me things which work. If the code runs, it's not a
> flaw, though certainly one may argue that it's an inelegant solution
> or even a dangerous one leading to problems in other contexts (etc.).
If the book you are using teaches bad practices that "work," then the
book is flawed. A newbie wouldn't understand why the code is flawed.
That can lead to newbies, who don't know better, writing insecure code,
or code that breaks with unexpected input.