Christian Heilmann

You are currently browsing the archives for the My Articles category.

Archive for the ‘My Articles’ Category

Even more DOMtab updates!

Wednesday, March 1st, 2006

Following feature requests in the comments below via I updated DOMtab once again. You can now link to tabs via the URL and get previous and next links!

DOMtab is a JavaScript that turns a list pointing to different content sections (like an FAQ) into a tabbed interface. Users without JavaScript will still get all the functionality, except they will have to scroll the page. DOMtab automatically removes any “back to top” links when the tabbed interface can be achieved.

  • The look and feel is completely styleable
  • You can use as many tabbed menus in a page as you wish to use.
  • Creation of a link that shows all the sections – for example to print out the page.
  • Automatic highlighting of tabs via anchors in the url (this also allows to use forms in the tabs – just add the anchor name to the action) new
  • Previous and next links for navigating through the tabs – in case you want to have a step by step approach new

Go and check DOMtab version 3.1415927 now

Freddy vs JSON – Lots of noise about OO JavaScript

Tuesday, February 21st, 2006

It is amazing how something dormant for a long time in the developer community emerges simultaneously at different spots.

My own Show love to the object literal was basically intended to explain the OL as a coding style and syntax allowing your scripts to be self-contained.

Dustin Diaz had a similar post cooking for quite a while and released his JSON for the masses a day later. His post is very enthusiastic about the whole subject, but does confuse some matters.

As always, and through the wonders of remote scripting (yes, I coined that term for comments being added at other people’s blogs linking to your own) a lot of discussions arose. Once again the hardliners of OO development tried to get JS to follow the same rules as higher programming languages, whereas JavaScript novices got very excited about some inconsistencies that might actually prevail as a myth for a longer time now. It is amazing how JavaScript sits in the middle of the whole development spectrum and everybody has an own – very fixed – idea about what good JS is. I got one, too, and there is a draft here about that subject (Hint: It does what it is supposed to do, and is easy to maintain by the intended audience).

Read all about how Dustin and me got informed about what is wrong or what is good about what we said:

Now here is my view on the matter:

The object literal

I like the OL as a syntax, and explained why in the post: It could be a signal that a script is more modern and was developed with unobtrusivity (hah! I guess nobody used that one yet) in mind. It is high time to find a mean for JavaScript novices to spot what is good to use these days and what is debris from the DHTML days. We could also call all our scripts “beta”, that’d also make them smack of Web 2.0!

Jason, err JSON

I like JSON as a data format, but it is not the same as the OL. JSON is a subset of the OL, and basically is a scripting syntax version of XML: It is there to hold data to send it back and forth in a readable and easily convertible way. JSON allows and encourages things like:

var data={
‘my wedding’:’fat and Greek’,
‘Plan’:’9 from outer space’,
‘Red Hot Chili Peppers’:’Flea, Anthony, and many random others’
}

This would be quite confusing in a script, although you can read out data['my wedding'] all the same. I’d consider it harmful as part of a script, as it does not quite promote valid variable names.

How about this: Calling JSON and the OL the same thing is as misleading as calling XML and semantic markup the same thing. One is data, the other is good practice (yes, you are allowed a different opinion).

And what about OO JavaScript then?

Now, if you want to go down and dirty with the real OO of JavaScript, then Tim Scarfe comes to your rescue with these two wonderful articles.

CSS Designer and DOM scripter, sitting in a tree

Monday, February 20th, 2006

Hello, I have a question for the CSS folk out there.

Currently I am writing a book for APress on Practical JavaScript and I am right now at the chapter about JavaScript and CSS working together.

Dynamic classes needed for styling JavaScript effects

The idea is to separate CSS and JavaScript completely – as explained in my Unobtrusive JavaScript Course. The JavaScript will dynamically add and remove classes to style effects instead of keeping the look and feel in JavaScript.

The question I was asking myself now is a maintenance one. I tend to separate out the class names as properties – in case that further down the line you need to use other class names as the initial ones. I also tend to comment the classes. Something like this:

scriptstuff={

// CSS classes
hideClass:’hide’, // hide elements
currentClass:’current’, // current navigation element
hoverClass:’over’, // hover state

[... lots of dark magic, voodoo and other code…]
}

Note: If you are confused by the syntax, check the show love to the object literal post.

This does the trick quite nicely for a few CSS classes, but I wondered about sites with several different scripts and sections.

The first set of questions are:

  • Do you feel comfortable with this arrangement?
  • Would you know how to change the CSS class name if necessary?

Now, if there were a lot of dynamic classes to be defined in a site, would you feel more comfortable if all of them were in an own document in JSON, for example named cssclasses.js:

css={
‘hide’:’hide’, // hide elements
‘current’:’current’, // current navigation element
‘hover’:’over’, // hover state
[... and so on for a lot of them…]
}

As the DOM scripter, this would make it easier to spot what is CSS related, as you’d use css.hide,css.hover and so on.

Another more complex approach would be to use AJAX and parse a CSS file exclusively for dynamic classes (f.e. dynamicstyles.css) – thus leaving the commenting and the syntax to you. The CSS could be something like

/* hide */ .hide{
[... CSS settings …]
}

/* current */ .current{
[... CSS settings …]
}

/* warning */ .warning{
[... CSS settings …]
}

All the DOM scripter would have to provide you with are the comment names.

Defining the scripting enabled and scripting disabled look and feel

I normally tend to apply a single class to the body when JavaScript and the DOM is available. something like:

if(!document.getElementById || !document.createElement){return;}
cssjs(‘add’,document.body,’jsenabled’);

This allows you to define two states in the CSS for every element:

#nav li{
[...settings…]
}

body.jsenabled #nav li{
[...settings…]
}

Would it be more useful to have two totally separate style sheets, like lowstyles.css and highstyles.css

It would be easy to remove the original styles and replace them with the dynamic ones via the DOM.

Or is all of this overkill? :-)

Graded Browser Support

Tuesday, February 14th, 2006

Yahoo just released their idea of modern browser support entitled Graded Browser Support . I have been advocating this in my company for a while, although it sometimes is tricky as it is also dependent on the client and their visitors (I had this wonderful degrading CSS-layout with awesome DOM Scripting effects just to realise that the main user group is IE5 and – god forbid – Netscape Communicator).

I was also pretty chuffed to see them linking to my unobtrusive JavaScript course :-)

PureDOMExplorer update – what is Safari’s issue with Off-Left?

Monday, February 13th, 2006

I just decided to celebrate the sale of a commercial license for my tree menu script pureDOMexplorer by creating a new version, which fulfils the change requests I had in the past. The new version of pde now

  • turns a nested list with the class “pde” into a tree menu – which means you can use it more than once on a page
  • uses fully unobtrusive JavaScript, including addEvent and encapsulation of all functionality in one pde object.
  • creates collapse and expand links and allows the section links to link to a landing page
  • allows for both keyboard and mouse to expand the sections (I still have to fix the tabbing issue over hidden elements)
  • keeps all the look and feel in the CSS - you don’t need to know JavaScript to change the look and feel
  • does not collapse lists that contain a STRONG element – to allow for a “you are here” state in your trees.

You can check and see the new version at the new pureDOMExplorer demo page

Now, it all works fine in MSIE/Opera/Firefox on PC, but on Safari I cannot make the hiding and showing to work without resorting to the inaccessible display block/none solution.

Currently my demo CSS uses the “Off Left” technique, as recommended to be most accessible :


/* The class to hide nested ULs */
.hide{
position:absolute;
top:0;
left:-4000px;
width:1px;
}

/* The class to show nested ULs */
.show{
position:relative;
top:0;
left:0;
width:auto;
}

Update
Ingo Chao took on the challenge and fixed the Safari issue. All working fine now.

Update
Following the requests in the comments to make the parent link also collapse and expand the nested list, I changed the script and added a new parameter called linkParent. If the parameter is false the parent link will point to the document it links to, if it is true, it will collapse and expand the same way the arrows do.