Hello all!
For me, this has been a year of ECMAscript and DOM. For everyones reading
pleasure the list of books I've read is at the bottom of this mail. They are all
good and the list is included as a tip...
Now, for my concern. (Warning: long post to follow!)
*ABSTRACT*
There are major inconsistencies between browsers as it comes to the handling of
DOM and to a lesser degree core ECMAscript. The best approach to handle this
seems to be *browser abstraction* - using code that equalizes the differences.
Trying to "elevate" the lesser browsers (read MSIE, Safari(?)) to the better
ones (FFox, Opera) is IMHO better than writing completely new functions.
There is also a need for utility-functions that expands upon core ECMAscript and
the DOM. Finally there is a need for "powerfunctions" for AJAX, widgets,
drag-and-drop, fade in/out, form validation, custom events, etc.
There are many toolkits out there (Dojo, Prototype, JSAN, etc.) but I'm a
teacher first and a developer second, so I like to reinvent the wheel as a
learning experience...
Final step: Is it possible to add support for MSIE and CANVAS to MSIE through
some 3d-party solution and make it scriptable?
*STRATEGY*
1. Core ECMAscript abstraction
2. DOM abstraction
- event handling
- XMLHttpRequest
- (perhaps) getClass/setClass
3. BOM abstraction
4. XHTML/HTML abstraction
5. ECMAscript extensions (more string and array methods)
6. DOM-extensions (utility functions)
7. Components of more "powerful" nature
*1. CORE ECMAscript ABSTRACTION*
As of version 1.5 Firefox has picked up speed in its support of core JavaScript
functions. With version 2.0 there will be more, and JavaScript 2.0 is on the
horizon.
Some functionality can be backported to older versions and other browsers:
if (typeof Array.map == 'undefined') {
Array.prototype.map = function() { /* code here */
}
At this step we are extending existing objects. That means we must take care and
not deviate from standards.
*2. DOM abstraction*
Similar problem and similar goal as in step 1. If it is not possible to produce
an equal solution, it might be better to add a function to my toolkits
DOM-namespace.
Example1: Event handling.
Scott Andrews "addEvent" has gotten a ton of follow-ups lately. IMHO the best
solution is David Flanagan's:
http://www.davidflanagan.com/javascript5/display.php?n=17-2&f=17/Handler.js
Question: is if it's really necessary to introduce a function name for this?
Couldn't it be feasible to make this workaround for MSIE behave so alike the
real addEventListener that we simply could go with that name? That would mean
that we'd go with prototyping again. My answer is no, because we can't get MSIE
to support the capturing phase.
Example 2: AJAX
For similar reasons it would probably be best to stick with the idea of using a
factory function for XMLHttpRequest. Additional needs may arise further on that
makes that option even more appealing. Tracking different outstanding requests,
coping with latency (the forgotten aspect
http://www.sitepoint.com/blogs/2006/02/10/ajaxlocalhost), etc.
Third example: get-/setAttribute
This functions is broken in MSIE: See
http://en.wikipedia.org/wiki/Talk:Comparison_of_layout_engines_%28DOM%29#Bugs_in_Trident_.28resolved.29
Is it possible to overwrite an existing function with a new one using the
prototype object?
As in
if ( browser detection - is MSIE ) {
Element.prototype.getAttribute = function(name) {
/* Code here */
}
}
*3. BOM abstraction*
BOM = Browser Object Model
Few standards exist so it is probably best to use a toolkit-specific namespace.
*4. XHTML/HTML ABSTRACTION*
Goal: Make all (or at least most) features work regardless of the document is
served as text/html or as application/xhtml+xml
Considerations: The folks who said that we should have namespace aware functions
in the DOM probably did so for a reason. This is a bad idea:
if (typeof document.createElement == 'undefined'
&& typeof document.createElementNS == 'function' ) {
document.createElement = document.createElementNS;
}
But if I introduce yet another function in my DOM-namespace I must continue to
use them in all functions instead of the normal ones, which also seems like a
hassle.
*5. ECMAscript EXTENSIONS (more string and array methods)*
I want my PHP functions! Viva strstr, strrchr, str_pad, ltrim, rtrim and
ucfirst! Not to mention sprintf and the plethora of array-functions!
*6. DOM EXTENSIONS (utility functions)*
Example 1:
The way PHP handles createElement is nonstandard, but oh so convenient:
http://se.php.net/manual/en/function.dom-domdocument-createelement.php
(The way PHP handles nodeValue is also convenient, but very confusing if you
switch a lot between PHP and JavaScript.)
Example 2:
Most toolkits tend to come up with a function to "push" and "pop" class names.
That's a must have.
Example 3:
There might also be a need for some utility functions to handle CSS-shortcomings
or browser specific CSS-implementation shortcomings... Perhaps that's a category
to itself, though.
*QUESTION*
What do you think of my strategy?
Let me summarize it:
A. Abstraction (support for standards)
1. Feature detect core and DOM functions.
2. If they are non-existent (or known to be broken in their implementation) add
them, preferably through the prototype object.
3. If that is not possible, add an equalizing utility function.
B. Extending (building on top of standards)
From simple convenience functions to exclusive power functions.
My 7 steps should no be defendant on each other in any other way but downwards.
I.E. DOM-abstraction might use Core-abstraction functions, but not the other way
around. DOM-extensions might use DOM-abstraction functions, but not the other
way around, etc.
Lars Gunther
P.S.
I've yet to get PPK's book, but so far my reading list contains (in no
particular order):
The JavaScript Anthology : 101 Essential Tips, Tricks & Hacks
ISBN: 0-9752402-6-9
http://www.sitepoint.com/books/jsant1/
Could not be better!
DOM Scripting (Web Design with JavaScript and the Document Object Model)
ISBN: 1-59059-533-5
http://domscripting.com/book/
Really good introduction to the DOM.
DHTML Utopia:Modern Web Design Using JavaScript & DOM
ISBN: 0-9579218-9-6
http://www.sitepoint.com/books/dhtml1/
Served a purpose when it came, but not top notch today.
JavaScript: The Definitive Guide (5th edition)
ISBN: 0-596-10199-6
http://www.oreilly.com/catalog/jscript5/
http://www.davidflanagan.com/javascript5/
Definitive! Do get the fifth edition.
Beginning JS with DOM Scripting and AJAX
ISBN: 1-59059-680-3
http://www.beginningjavascript.com/
Best introduction to JavaScript *and* the DOM.
Ajax Patterns and Best Practice
ISBN: 1-59059-616-1
I did not like it. It often suggest bad methods performance-, accessibility- and
usability-wise. Some tips are good though.
Pragmatic Ajax - A Web 2.0 Primer
http://pragmaticprogrammer.com/titles/ajax/index.html
ISBN: 0-9766940-8-5
Usable and good, but not outstanding.
Foundations of Ajax
http://www.apress.com/book/bookDisplay.html?bID=10042
ISBN: 1-59059-582-3
The best introduction to AJAX per se, that I've read.
PPS. No I haven't read *all* books from cover to cover.
*******************************************************************
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
*******************************************************************
