Just learning a little about DOM now, and coming to the realization that, apparantly, if you wanted, you could create the entire web site with dom, and don't really need any straight html...
My first question: Am I right about that?
Then, if that's true, What's the best way? What, if anything, are the advantages and/or disadvantages of doing it one way vs. the other?
Yes, you could load a blank page that just looks like this:
and create all the elements on the page. But what's the point? You might as well put the HTML elements in there to start with.
Also, it would mean that users with JS disabled, and search engines, would not be able to view your content. Also, it would make the page load slower and make maintenance a nightmare.
The only reason you would want to do this is as a proof of concept, but nobody would be impressed nowadays.
Simply because it's harder to find things than in an HTML document tree, especially nowadays with things like Firebug, you need to do a lot more typing and the potential for bugs is much larger.
I think if you think about it you'll realise it would be a lot more time-consuming.
Regarding having JS disabled, just search. Felgall's opinion is top of the list.
Thanks again, Raffles,
And thanks for the link re. why people disable js. It appears that folks disable js due to misconceptions re. security issues, or to prevent popups or things happening after the page loads...( I notice sometimes, when I'm composing or replying to google e-mails, that the browser hangs -- now I'm wondering if it's due to something js is doing behind the scenes...)
Yes, I think I've got that point now, Oddz. Thanks!:)
Re. why people might disable JS, I've just gone a little further in my studies, and come across an example where js is controlling the number of items you are allowed to order, and by disabling js, the client is attempting to get around that restriction. Of course I know this should be caught by the server. But this is opens my eyes to another explanation why people might want to disable JS.
All the actual validations on what is or isn't allowed in given fields must be done on the server as that is where the site owner's validation takes place.
Yes, I've got that, Stephen. Thanks!
Well, Oddz, wouldn't you say that you should do it at both client and server where practical?
For instance, isn't is true that a couple of reasons for client side programming are...
1. Quicker response to the user
2. Reduce the load on the server
And, with those things in mind, then, isn't it true that when you do whatever validation you can on the client, ( like checking required fields have something in them, or checking boundaries for numeric entries), doesn't this contribute towards both of those things? Suppose a dollar value should be greater than 4.99 and less than 44.99. I do realize now the need for validating -- or RE-validating this on the server; but, if you initially check it on the client, isn't that going to serve the first goal I mentioned?
I have to admit, I don't see, now, where JS is going to reduce the load on the server -- at least in the area of validation -- since you're going to be validating everything on the server anyway. I guess, if part of the benefit of JS is that it does reduce the load on the server, then it must do this in other ways besides validation.
I think you two are talking about same thing, but are having problems wording it
All validation should be handled server side, once the form is actually submitted for some sort of database-insertion.
If available, JS should / could be used to notify users of common errors so they don't have to wait for the page to reload and notify them about errors and what not (re-enter captcha, that's the most annoying thing if you ask me).
I agree, and I think we have probably beat this poor horse to death! :lol: