Denilson F. de Sá

[after many IRC conversations]

One thing you should add to this page. This I have learnt from first C
classes I had.

http://www.howtocreate.co.uk/tutorials/javascript/variables

The newline is represented as:

\n   -> Unix
\r   -> Mac
\r\n -> Dos/Windows

So, althought I'm not sure if this will ever happen with JavaScript, I feel
that people will need to recognise \r as line break in Macs.

See ya!

In fact, I never used a Mac. (ok, I touched one once, but I didn't 'use' it)
So, I have completely no idea about Mac world. I only know what people says
and what I read.

So, I never used JavaScript on Mac, and I don't know what would happen.
Anyway, I feel this note is useful for even non-JavaScript programmers.
This is an important information that many programmers don't know.

Thanks for adding it.
See ya!

http://www.howtocreate.co.uk/tutorials/javascript/dombasics

"Note also that all element nodes have the getElementById and
getElementsByTagName methods to help reference elements within them."

I checked now the W3C DOM 2 Core and Element objects only does have
getElementsByTagName (and also getElementsByTagNameNS).

getElementById is only available to Document object.

Hello, Tarquin.

As you may know, I know some JavaScript. But I learnt JavaScript in 199x,
when DOM0 was the way to access form data.

Now I ask you: how should we access form data today? The same way? Should we
stop using DOM0? (I think yes, because "name" is deprecated in <form>)

I would like to ask you some tutorial (IOW, a new page at your JS section -
http://www.howtocreate.co.uk/tutorials/javascript/) about accessing form
data.

I would like to know how to access each form data (read and change it).
Browser compatibility would be nice too (and it will keep the very
high-quality level of your pages, as many other pagea has browser
compatibility list).

It worthes noting how changing form data affect DOM tree (both using W3C DOM
and innerHTML). I have a guess that IE changes DOM tree when you (the
programmer) or the user changes the form data, while I guess FireFox don't
do so. (I say this because a friend had a problem using innerHTML... well,
too complicated and off-topic to explain in this mail)

Finally, some nice "requeriments" ;) for your JS form page:
- How to access value from text/password/hidden/textarea fields.
- How to access check status for checkboxes.
- How to know if one specific radio box is checked or not.
- How to know which radio box is checked (from a radio box set).
- How to do the same things about radio boxes in select.
- How DOM tree behaves.
- [little off-javascript-topic] Mention about <label> element, and maybe
link to a page describing it (BTW, IE requires "for" attribute to make it
work; very dumb IE...).

Extra useful info (maybe on another page/section, yet in same subject):
- Explain about onSubmit, and why it is far better than using <input
type="button" onClick="">
- Explain about multiple submit buttons (ok, this is not exactly
JavaScript-related, but I always wanted to know about it)
- Explain how to validate forms before submitting (and add "ALWAYS CHECK
YOUR DATA ALSO ON SERVER, NEVER RELY ON JAVASCRIPT-ONLY VALIDATION")
- Explain how to restrict textboxes to some formats (like "000,000,000.00",
dd/mm/yyyy, etc.).

About the last item, maybe would be better to convert "000,000,000.00" to
"000000000.00" on focus (optionally), and re-convert back to human-readable
when blur. Just one idea. I think doing such validation/restriction on
keypress-like event is much more difficult, and much less cross-browser. The
onfocus/onblur idea looks easier and very good for me.

Well, thanks for reading this long e-mail. :) I hope this brings you some
ideas about new JavaScript tutorial pages (remember, in tutorial section,
not examples or libraries; at least not only there), I also hope to read
this new tutorial section sometime.

Thanks again. (and could you mail me when you write this tutorial? It will
be useful for me and for my friends)

Thank you for the answer again.

I first wanted you to ask "a javascript forms tutorial". Then I kept
writing and writing with ideas about what to put there. (sorry if it
was too much)

The objective: discover what is the best way to treat forms with
JavaScript using HTML 4 Strict (or XHTML).

Since forms don't support NAME attribute in strict DTD, I thought I
couldn't use directly the DOM0. Do you have any idea? Any solution?

Is it just me or you also find this all messy. Looks like people who wrote
HTML strict, XHTML strict and DOM did forget form handling by JavaScript.

Anyway, thanks for this answer. I think using transitional + DOM0 might be
good, or using solution 3 if we want strict DTDs. I will tell this to my
friends, when they ask.

<URL: http://www.howtocreate.co.uk/browserSpeed.html >

You said at #updating :
"Additionally, with some browsers (such as Konqueror), testing new versions
requires me to upgrade my entire operating system."

Well, that's not true. The Operating System itself is only the kernel (maybe
plus a few userland tools, like init and a shell). To test a new Konqueror
version, you need "only" to update KDE (in other words, update only the
desktop environment, not the operating system).

But yes, that is a "big" update.

--Denilson F. de Sá

Interesting. Some comments about above e-mail conversation:

1. Most linux distros only allow one version of each package to be
installed at same time. This happens because most of time users will
want to *update* their programs, instead of installing multiple
versions.

2. I don't know about other distros, but Gentoo allows *some* packages
to have more than one version installed. gcc and kde are examples of
this. However, only "major" versions can be installed at same time
(gcc 3.3, 3.4 and 4.1 can all be installed at same time, but not 4.1.0
and 4.1.1). This allows the user to have kde 3.3, 3.4 and 3.5 at same
time.

3. Even if a distro does not allow multiple versions of same package,
the user always can manually install from sources. The binary packages
are generated from source, with "configure" options to make it install
at same directory of older versions. So, you will never* be able to
install multiple versions using binary packages.

* Never say never. :)

4. Firefox and Opera are "small" and "self-contained". They were
written so they can be run from a single directory. Konqueror,
however, uses lots of shared KDE libs, and most of Konqueror itself
are libraries (so they can be used in another KDE programs).

Although you can easily install multiple program versions, is not so
easy to install multiple libraries versions (have you thought about
installing multiple libc versions?)

Well, most of this you already know. And I understand that you, as
"web developer", would like to test multiple versions. And... How do
you test multiple IE versions? (unfortunately sometimes I feel KDE
looks too much like Windows ;) )

> It is an attempt to give an analogy that normal users will understand,
> so they realise how much work it is, just to update a browser.

Yes, I understand that "normal" users won't know the difference. They
would not even know what is a Desktop Environment, a shell, a kernel
or an Operating System.


See ya.

>> So, you will never* be able to
>> install multiple versions using binary packages.
>
> I just don't see why they can't do it. it just feels like a cop out to
> me.

Hum... Most distros don't allow that because it would be too much work
and many more new bugs for little gain (for most users).

> Web developers do not want to have to compile multiple versions. Most
> Linux users do not use Gentoo. they use distros based on RPMs or Debian
> packages.

Maybe you could try to uncompress an rpm to some directory (I once did
that on "maxima" package, by using rpm2tgz and then untarring it), and
try to run the application from there. Probably you will need to set
LD_LIBRARY_PATH variable before running it, to ensure the program will
use first the provided libs, and then the system libs.

>> Konqueror,
>> however, uses lots of shared KDE libs, and most of Konqueror itself
>> are libraries (so they can be used in another KDE programs).
>
> They could make a downloadable .gz that contained all of them as a
> single bundle, without relying on installed libraries. They just choose
> not to. See Opera's static QT release for what I mean.

True. That will be useful for people like you.

I guess you can have two options (for now):
1. uncompress the rpm to some dir, set a custom PATH and
LD_LIBRARY_PATH and hope the program does not have any absolute
hard-coded path.
2. compile from source and install somewhere else.

> > Well, most of this you already know. And I understand that you, as
> > "web developer", would like to test multiple versions. And... How do
> > you test multiple IE versions?
>
> With IE, I download the zip packages. I have IE 4, 5, 5.5, 6, and 7 on
> the same computer. No compiling needed (admitedly, MS did not publically
> release the packages, but open source people should be trying to be
> better than their closed source cousins).

And they do. :) Package management is wonderful, and far better than
Windows. I mean, you can install any package by using "emerge
program", or "apt-get install program", or "yum install program" or
something similar. And with one or two commands, we can update all
installed software. Windows cannot do that. :)

And, hey, if you have IE zip packages that were not publically
released, you have bypassed the "standard" way of installing it. And
you don't want to bypass "standard" way to install packages into your
distro.

BTW, I never liked RPM-based distros. I don't like RPM package
management. I guess they are too easy to get messed-up. <irony>And now
I use Gentoo.</irony> ;-)

(This will always be a never-ending discussion... I promise I won't
extend me too much on next replies!)