Denilson F. de Sá

Navigation

Skip navigation.

Search

Site navigation

Email conversation

FromDenilson F. de Sá
ToMe
SubjectSpecial string characters
Date11 December 2004 01:20
[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!
FromMe
ToDenilson F. de Sá
SubjectRe: Special string characters
Date12 December 2004 15:39
ah, true, they _did_. Mac OS 9 and before used \r
Mac OS X does not. it is unix based so it uses \n

However, as far as my tests showed, browsers use \n even on these old Mac
versions. However, I will add a note to that page just in case I missed
something.

Cheers
FromDenilson F. de Sá
ToMe
SubjectSpecial string characters
Date12 December 2004 16:11
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!
FromDenilson F. de Sá
ToMe
Subject[please fix] JavaScript tutorial - Manipulating DOM nodes and the DOM tree
Date18 December 2004 02:14
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.
FromMe
ToDenilson F. de Sá
SubjectRe: [please fix] JavaScript tutorial - Manipulating DOM nodes and the DOM tree
Date20 December 2004 09:10
doh! oops :) thanks for pointing that out.

I have updated the relevant pages
FromDenilson F. de Sá
ToMe
SubjectHelp with JavaScript forms
Date17 March 2006 00:51
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)
FromMe
ToDenilson F. de Sá
SubjectRe: Help with JavaScript forms
Date17 March 2006 09:13
> I would like to know how to access each form data (read and change it).

The "browser inspecific referencing" gives details. Basically, if you want
compatibility, continue the way you always used to, and use HTML
transitional. Browsers will never stop supporting the DOM 0.

http://www.howtocreate.co.uk/tutorials/javascript/browserinspecific
See the section on "forms" for more details.

> It worthes noting how changing form data affect DOM tree (both using W3C
DOM and innerHTML).

Since the tutorial is intended to teach compatibility, I will not cover this
at all. Basically because the support for W3C DOM in forms sucks.

1. IE gets the add method wrong for select inputs.

2. Opera and Firefox do not have the correct childNodes for textareas.

3. Opera does not have the correct innerHTML for textareas.

4. The DOM does not recognise dynamic changes. When you change the value of
an input, you are _not_ changing the source code, so the innerHTML,
childNodes, and value attribute should not change, meaning you are stuck.
The only way to do this is with DOM 0.

The DOM 0 methodology has been incorporated in the Web Applications 1.0 spec
(meaning it will become the standard at some point), and is the right way to
go when dealing with forms.

> - [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...).

covered in the HTML tutorial.
http://www.howtocreate.co.uk/tutorials/html/forms

> 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 how to validate forms before submitting (and add "ALWAYS CHECK
> YOUR DATA ALSO ON SERVER, NEVER RELY ON JAVASCRIPT-ONLY VALIDATION")

One of the examples partially covers this, but I should put a more prominent
link somewhere:
http://www.howtocreate.co.uk/tutorials/jsexamples/formcheck.html

> - Explain how to restrict textboxes to some formats (like
> "000,000,000.00", dd/mm/yyyy, etc.).

See the example, or the HTML tutorial. This is what Web Forms 2 is designed
for. Workarounds are always ugly.

> 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.

http://www.howtocreate.co.uk/emails/AvijitKumar.html *sigh* :)

FromDenilson F. de Sá
ToMe
SubjectRe: Help with JavaScript forms
Date17 March 2006 15:01
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?
FromMe
ToDenilson F. de Sá
SubjectRe: Help with JavaScript forms
Date17 March 2006 15:16
> 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?

You can choose;

1. ignore the DTD and use it anyway (do _not_ do this if you are serving
pages as application/xhtml+xml - it is ok if you use text/html, because they
will allow it, even if you claim to be using XHTML with a doctype [if you
serve it as HTML, it will be treated as HTML])

2. Use transitional

3. give the form an ID, and use document.getElementById to reference the
form (equivalent to document.nameOfForm) - this will not work in non-DOM
browsers

4. use the forms collection with a numeric index.

Once you have a reference to the form, it is the same as in DOM 0 to
reference the inputs, since inputs are allowed to have the name attribute
with strict doctypes.
FromDenilson F. de Sá
ToMe
SubjectRe: Help with JavaScript forms
Date17 March 2006 15:20
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.
FromDenilson F. de Sá
ToMe
SubjectBrowser speed comparisons
Date6 October 2006 02:30
<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á
FromMe
ToDenilson F. de Sá
SubjectRe: Browser speed comparisons
Date6 October 2006 09:55
> To test a new Konqueror version, you need "only" to update KDE (in other
> words, update only the desktop environment, not the operating system).

Unfortunately no. KDE has trouble updating on my SuSE installs. Sometimes it
works, sometimes it just makes a mess instead of installing properly, and
screws up the dependencies and breaks YaST. I mentioned this to one of the
konq devs:
http://www.howtocreate.co.uk/emails/AllanSandfeldJensen.html

But in GNU systems, the kernel may be treated separately, but to a user, the
DTE _is_ the operating system (with the exception of those of us who know
better, of course). Windows ME was basically just an upgrade to the
Windows98 DTE. They both used DOS as the kernel (95 was the same, but
without several drivers and 32 bit support). However, you would not think of
ME as just a DTE upgrade to 98 - it was a new operating system.

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. Only Safari and
Konqueror are that difficult - even IE allows you to do updates of the
browser without upgrading your OS; within limits of course.
FromDenilson F. de Sá
ToMe
SubjectRe: Browser speed comparisons
Date6 October 2006 19:52
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.
FromMe
ToDenilson F. de Sá
SubjectRe: Browser speed comparisons
Date6 October 2006 20:09
> 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.
Opera manages to make a downloadable .gz that contains a working binary. You
just unpack and run. Konqueror may not be able to do that, but that in
itself is a problem.

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.
That should say something about how linux people like things to be. They do
not want to have to upgrade their DTE to see if a certain behaviour has
changed in the next incremental release. They want to be able to check if
the previous version will work, as well as just the latest.

Right now, konqueror is relegated to being extremely unfriendly to
developers. It does itself a disservice. Developers will not go to the
effort of testing anything more than is currently installed. Users will
suffer as a result.

> 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.

> 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).
FromDenilson F. de Sá
ToMe
SubjectRe: Browser speed comparisons
Date6 October 2006 20:30
>> 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!)
This site was created by Mark "Tarquin" Wilton-Jones.
Don't click this link unless you want to be banned from our site.