Christian Heilmann

You are currently browsing the archives for the Experiments category.

Archive for the ‘Experiments’ 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

Google Pages – Google enters the WYSIWYG page editing market

Saturday, February 25th, 2006

I just stumbled upon Google Pages, which seems to be a cleaner geocities/myspace/homestead. You can create web pages in a live editing WYSIWYG environment and choose a style and a layout. The resulting code is not as grim as I expected it:

Googlepages creates CSS layouts with embedded styles, which is not really perfect, but a step in the right direction. You can edit, publish and unpublish pages quite easily. It seems even adult content is all right to publish, but I will not test that now! I created the demo page in FireFox 1.5 on PC, as Googlepages so far does neither support Safari, Camino nor Firefox on my Mac.

I’d like to see a chance to submit templates…

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? :-)

Large clickable boxes as navigation with CSS and DOM

Monday, February 13th, 2006

A client asked for a proof of concept how you could create large clickable boxes as a navigation. They wanted the whole box clickable, and if the link is a section link with child elements they wanted an indicator that there is more. The links without children should simply send the user to the site, the parent links should not follow the main link, but expand the children.

Check out the demo page: large boxes as links and feel free to get inspired. If wanted, I can write a quick explanation on how it is done and you could send sexier styles.

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.