Javascript DOM Scripting Pain: Whitespace Nodes

coding javascript+DOM is a pain in the ass.

no, am not talking about using those jquery etc libs.

am talking about js+dom raw.

every whitespace in your html code is a node too, by spec. Say, you want to get nextSibling. But what you get is a text node of white space.

This is a pain in the ass. However, there's also a advantage aspect. Because, this spec makes it possible to write a DOM processor that preserve the original formatting, including manipulating comments.

(on the other hand, comment or formatting are lost in most lang's compiler. Suppose you want to write a most advanced {lint, pretty-printer, automatic code formatter}. You might think you'll just use the lang's compiler, since it knows everything about the language. But you can't! you kinda have to write a entirely different tool from scratch. Because the compiler is totally ignorant about the comments and formatting! (this includes so-called “lisp reader”) This also explains, auto formatting tools (aka lint) isn't always available. Even in emacs, formatting source code sucks majorly. Those formatting commands (e.g. indent-region), they go line-by-line manual/guessing methods. And this “no auto formatting condition” encouraged all the hacker type idiots to drivel about “coding style” day and night. (is there a language whose compiler are aware of source code comments and formatting?))

but anyway, normally when doing web app scripting, we don't care for the whitespaces between tags. So, in order to get the real next sibling, it's a pain in the ass. You have to check the returned node's type, then check if its value is all whitespaces (and don't forget the Unicode whitespace characters, kids).

of course, any sane coder will just use a js lib.

Popular posts from this blog

11 Years of Writing About Emacs

does md5 creates more randomness?

Google Code shutting down, future of ErgoEmacs