Christian Heilmann

You are currently browsing the archives for the Odds & Ends category.

Archive for the ‘Odds & Ends’ Category

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…

Using position:fixed and transparency in a creative way

Thursday, February 23rd, 2006

Some time ago, design for CSSZenGarden using a knife that slashes through the document was all the rage.

Now I stumbled upon a referrer in my stats that got me sniggering: blether.com has a much more subtle gimmick like that, and I am sure that if you open this site on public terminals you’ll encounter a lot of people scratching the screen.

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

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.