• You are currently browsing the Christian Heilmann blog archives for February, 2006.

  • Archive for February, 2006

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

    Two Viruses for Macs – does this mean we cannot be smug any longer?

    Sunday, February 19th, 2006

    Security Pro News reported about two Viruses spreading on Macs. While one of them is not yet found in the wild and spreads via Bluetooth, the other one is around, but needs a daft user like most of the less subtle PC Viruses.

    Leap.A spreads itself via iChat and originally claimed to be screenshots of Mac OS X v10.5 Leopard with the name latestpics.tgz.

    I blame two reasons for Mac Viruses emerging:

    • The switch to intel, thus making it easier to check the system
    • The smugness of a lot of Mac Users about being Virus-free for life. Yes, OS X is UNIX based, but it has hooks *nix hasn’t got – like iChat.

    Don’t trust anything you don’t know is the Motto, and it might be a good idea to use the console from time to time to know what all these funky icons really are under the hood.

    Update

    The lovely Veerle quantifies the information as malicious software and not a Virus, and she has a point. As stated, it needs an uninformed user to execute it and it is not dormant in your system to become active at a certain date.

    Chat around the Campfire

    Friday, February 17th, 2006

    The clever people who brought us Backpack and Basecamp strike back with Campfire which is essentially like having a chat in an Instant Messenger with several people, but with a fixed URL and logging of the conversation.

    This could be a cool replacement for phone conferences for companies like the one I am working at – as the line quality to the India office always keeps you guessing what the other person meant.

    I’ll give it a whirl…

    via datacircle

    Show love to the object literal

    Thursday, February 16th, 2006

    German Visitors: Zur deutschen Version gehts hier – auf dem Blog von Jens Grochtdreis

    If you are just getting your teeth into JavaScript, or if you used it in the past and re-discovered it in the wake of the AJAX craze you might have been baffled by scripts that come in a new syntax.

    While older copy and paste scripts looked like this:

    var commonSense=null;
    var standardsCompliance="50%";
    function init(){
      // code
    }
    function doStuff(){
      // code
    }
    function doMoreStuff(){
      // code
    }

    Newer scripts inside tutorials tend to look like this:

    awesome={
      commonSense:null,
      standardsCompliance:"50%",
      init:function(){
        // code
      },
      doStuff:function(){
        // code
      },
      doMoreStuff:function(){
        // code
      }
    }

    The new syntax is called the object literal and is pretty close to sliced bread. Here is why: (more…)