The old saying is true! I’m going to Rome with my family tomorrow and we will stay there for eight glorious days! I really need to spend more time with them and less with computers, so it feels good with a break. No blogging, only carrying (extremely heavy) luggage around (and seeing and doing amazing things, of course :-)).
I’ll be writing my next post in the beginning of June, don’t know any exact date. I recommend that you subscribe to my RSS feed to find out when I’m back in the saddle.
While I’m away, I recommend browsing through my categories to find something that interests you. Some of my more popular posts, and the ones I feel most content with, are:
Apparently, Firefox Market Share Gains Continue, and it’s up to a whopping 10% (however, I usually tend to be skeptical to these kind of statistics). Either way, as I’ve said before, a perfect world would be where many major browser players have an equal market share, like back in the beginning of the web browser wars, and that it stays like that. It will keep web browser makers on their toes, and hopefully result in more possibilites and options, and more standards -based code working in them. I really wonder what IE 7 will hold.
Note: Why isn’t Safari mentioned at all in this piece?
Yesterday, I peaked again! Roughly 1270 unique visitors (or around 2100 counting the RSS feed as well), which makes me very happy. Anne, I’m coming for you! 😉
But to be serious:
Yesterday I saw many first-time visitors and I welcome you here! I really hope I will be able to write and discuss things that will make it worth for you coming back here. I write daily Monday to Friday about web developing, and sometimes I share some of my code in RobLab.
Don’t hesitate to contact me with suggestions or questions, or just to have a chat!
Tommy passed the baton to me, and I’m flattered that he chose little me! There are two ways to react to a thing like this: either regard it as a “Send this e-mail to ten friends or lose a leg” kind of thing, or just something fun and different. I choose experiencing it as fun and different!
So, without further ado: Here’s my list!
Total Volume
Usually around 10 GB of widely (well, at least kind of) spread music flavors.
Last CD Bought
Dance of Death, Iron Maiden
Song Playing Right Now
Actually, none. Like Tommy, I usually like it quiet when working with the computer, unless I’m in a loud and crowded environment and need to focus on my things.
Five Songs I Listen to A Lot, Or That Mean A Lot to Me
This will be a mix of both cases mentioned in this part’s heading, and of course it’s very hard to pick just five songs. But here goes, now I reveal my secrets!
All Along The Watchtower, Jimi Hendrix version
Sound of Silence, Simon & Garfunkel
Hallowed Be Thy Name, Iron Maiden
Highway To Hell, AC/DC (I also really like Marit Bergman’s version of it)
Layla, Eric Clapton (both the electric and acoustic version)
Five People to Whom I’m Passing the Baton
This was the fun part, picking interesting people that are very different from each other. Forgive me. 🙂
Last Friday I had the pleasure of meeting Roger Johansson, who was visiting our beautiful capital, Stockholm. He was attending a usability conference (with Jakob Nielsen, amongst others). We met up for a short “fika” (something like having a cup of coffee/tea with optional cookie/cake to go with it), and talked about web development. Roger has gotten some attention here in Sweden recently, bringing up the discussion about (the lack of) accessibility when it comes to web sites in the public sector (article: Webben är inte öppen för alla).
Something we really agreed on is the lack of respect CMS manufacturers show their clients when they create administrative interfaces that only work in IE on a PC. As if that wasn’t enough, their WYSIWYG editors generate terrible and invalid code that cannot be presented as strict HTML or XHTML. We’re talking about editors that generate deprecated tags, upper-case tags, attribute values without quotes, invalid attributes and so on. Basically, worthless code that also (as to top it off) isn’t well-formed, hence impossible to use in a stricter XHTML/XML scenario.
Why do they do this to us? Is it because of a lack of knowledge, or out of laziness, taking the easy way out? Maybe I’m cynical, but I’m apt to believe in the latter. I’ve met many developers that just think it’s a hassle to produce valid code, and their beloved Microsoft makes it oh so easy for them, so why should they bother going the extra mile?
With all the different web browsers on the market now, be it for computers, cell phones or PDAs, the initiative and responsibility to make the web accessible for everyone has to be taken seriously.
For those of you who read this, let’s start with the WYSIWYG editors. Say no to IE-specific ones, and look at the alternatives. One of the best ones I’ve seen so far is the open source alternative, TinyMCE by Moxiecode. It is solely based on JavaScript, which means that it doesn’t require any plug-ins or extra programs to run (the way it should be, in my opinion). For the moment, it works in IE and Mozilla/Firefox, meaning that with the Gecko support it is also available on the Mac and Linux platforms, as well as the PC platform. And, of course, they’re Swedes! 🙂
Another alternative is XStandard, which uses a plug-in for advanced control over the editing. Unfortunately, it only works on PCs.
Using a WYSIWYG tool in your application/-s? Please take your responsibility and make sure that it generates valid (and hopefully semantically correct) code!
Today is the launch of my lab web site, RobLab (yes, it’s a corny name), where I will have code, tips and tricks for anyone to use. For the moment, it only has a few things and I don’t know with what frequency I’ll be adding stuff, but that totally depends on the reception it gets. I hope the web site will act as a resource to you, and will be of use.
This is one of those Fridays where I’ll write about something else than developing, so if that’s what you were hoping for, stop reading now. However, if you feel that there’s more to life than web development and the internet, please keep on reading. Like off-topic posts? Love ’em, hate ’em? Let me know!
As I’ve written before, my girlfriend and I went on a long trip in 2002. One of the places we went to were Easter Island, which is really an amazing place! I had wanted to go there since I was a kid, when I read a “Kalle Ankas pocket” (Donald Duck comics in a paperback format) that took place there. Seeing all those gargantuan ominous-looking stone heads made a shiver ran up my back, and with that tingling feeling I knew I would travel there one day!
Easter Island, also known as Isla Pascua or Rapa Nui, is one of the most isolated places on Earth, located 3700 km from the Chilean mainland. You can go 1900 km in any direction from the island without coming across inhabited land (that’s about 1178 miles for you US readers). The earliest settlers called it “Te Pito O Te Henua”, meaning “Navel of The World”. It’s a tiny island with a population of only around 2000 people. There are also two giant volcanoes on the island, where I really love the immensely beautiful Rano Kau!
We flew there from Santiago, Chile, but unfortunately we didn’t have seats by the window. Of course, everyone wanted to see the statues from the air plane but as I remember it, no one saw them from the plane. Before we left Sweden, we had booked a guide and a three-day programme for seeing and learning as much as possible about the island. When we landed in the afternoon, our guide, Hermann (I don’t think he was originally from Germany, but he spoke German, Spanish and English), met us at the airport, and a driver of his with a mini-van drove us to our hotel.
Once at the hotel, we asked if there were going to be any activities that afternoon, but we got no as a answer. After we had settled at the hotel, I decided to go look for a statue. I mean, I had been longing to see them since I was a child, there was no way I could wait one more day! Fredrika, my girlfriend, wasn’t as eager as me, so she decided to chill by the hotel pool instead. I looked at the hand-drawn map I got earlier (which didn’t have any statues marked on it) and took off in the direction that felt right, with a bottle of water to keep me going. I started walking along the coast, up an enormous hill. After about fifteen minutes of walking I encountered a small run-down fence. There was no way I was turning back now, so I climbed the fence and continued.
I walked further and further up the hill, and every time I reached a ridge that I believed to be the top, another higher part of the hill revealed itself to me. After about two hours of walking, and no water left, I finally fought my way through some bushes and came upon a gravel road. I followed it to the right and came to a stone fence after five minutes of walking. There was a sign that said it was a national park and that I had to pay an entrance fee to the guard in the small stone house. Since I a) didn’t know what was on the other side of the fence, and b) already had paid for a tour, I didn’t think it was a good idea.
Instead I managed to get my way through some shrubbery and got my first, half-obscured, look of Rano Kau (see first picture in this post). After the long walk I was exhausted, and walking the same two hours back the way I came didn’t feel like an option. I could try and walk the gravel road, but I wasn’t sure how far that would be, nor where it would lead me. Standing hesitantly by the end of the road, by the stone fence, pondering my options, I spotted a guy with a cap and a moustache. Seeing the raggedy state I was in, he asked me if I wanted a ride back. Man, did I!
I hadn’t seen any statues after all my efforts, but by then I just wanted to get back to the hotel.
He got into his jeep, and on the way back I learned that he was a photographer, traveling around the world to places like Easter Island, taking pictures and then selling them. That’s a job I’d love to have! He dropped me off at my hotel and I stumbled towards the hotel pool. No Fredrika. I went to our hotel room. No Fredrika. I went around to the back, looking in from the patio door. No Fredrika.
I managed to push the patio door open using my nails, since it wasn’t locked, and got into the room. On the bed lay a note:
Gone on a tour. Don’t know when I’ll be back.
WTF!!! My best bet was to walk to the central part of the small town on the island, which was a 25 minute walk for a dehydrated Swedish tourist. Then, of course, in the city center (where I at that point hadn’t been yet) there was a statue (they’re actually named moais).Not the most impressive one (rather one of the most beaten, worn-down ones), but still, a statue! Mission accomplished! Now I just had to find Fredrika…
I didn’t find her in the city center, so after some moseying around, I walked back to the hotel again. After sitting apathetically on the bed for a while, Fredrika walked in through the door. It turned out that there was indeed a tour that afternoon, and just after I had started on my strenuous walk they had come to the hotel and driven her and some others around to see some moais (statues) and the museum on the island (where I still, to this day, haven’t been…). So much for being the adventurous and ambitious one…
Eventually, though, we got to see a lot of moais and it’s a visit I’ll never forget! It even exceeded my expectations I’d had for twenty years or so!
In a lot of the CSS code I see, people don’t seem to be aware of shorthand properties. They are an excellent way of keeping your stylesheet condensed and it also gives you an easy overview. Basically, it’s a way to write one-liners to affect all sides of an element or all similar properties grouped together.
The general rule is to apply length values for padding, margin and borders. They are to be written in this order, according to the element’s sides: top, right, bottom, left. If you only write two values, it will be for: top/bottom and right/left. Write three values and it will be applied like this: top, right/left, bottom.
NOTE: Remember to always specify a unit, such as px, em, % etc, unless the value is 0.
/* 2 px margin all around */
div#header{
margin:2px;
}
/* 2 px top/bottom margin and 4 px right/left margin */
div#header{
margin:2px 4px;
}
/* 1 px top margin, 4 px right/left margin and 8 px bottom margin */
div#header{
margin:1px 4px 8px;
}
/*
1 px top margin, 3 px right margin, 8 px bottom margin
and 5 px left margin
*/
div#header{
margin:1px 3px 8px 5px;
}
For font values, the shorthand property is applied in this order: font weight, font size/line height, font family.
/*
A bold font weight, 10 px big with a line height of 14 px
and desired font family specified in prioritized order.
The font weight value and the line height value can be omitted.
*/
div#header{
font:bold 10px/14px Verdana, Arial, Helvetica, sans-serif;
}
When it comes to background styles, it comes in this order: background color, background image, background repeat, background attachment, background position. Like this:
/*
The element will get a white background and have
a non-repeated background image that is placed
in the element's top right corner.
*/
div#header{
background:#FFF url(images/funky-pic.png) no-repeat right top;
}
I think it was Eric Meyer who first coined this expression (or at least he did where I read it first), and I think it’s something that describes what I sometimes feel. Whitespace blues is the feeling you experience when HTML tags aren’t written next to each other, resulting in weird effects, margins etc.
Above code can, in some cases/web browsers, generate extra margins and space in the displayed layout. Sometimes the only solution is to re-write it like this:
Sad but true. Personally, I dislike giving up on writing well-structured code just to get rid of strange whitespace. So is taking whitespace into consideration for web browsers really necessary? Or should whitespace only have any affect whatsoever within PRE tags?
I’ve been meaning to write this post for a long time. But, as always when you hesitate, someone else comes along and writes exactly what you were going to write (in this case, Mark Wubben beat me to it). But I’m just going to write it anyway!
First, what is object detection? The general purpose of it is to check in JavaScript if, for instance, a certain method is supported as opposed to relying on detecting what web browser the visitor uses. For example:
// Object detection
if(document.getElementById){
// Use the document.getElementById method
// to access an element
}
// Browser detection
if(navigator.userAgent.search(/MSIE/) != -1){
// Deliver IE-specific code
}
Generally speaking, it is good practice to use object detection, especially given all different web browsers that there are out there in the market. It is also a way of, as good as it can be done, future-proofing your application.
But it’s not the perfect solution that will work in all scenarios. I totally agree with Mark when he says that one has to compliment it with some browser detection, because there are web browsers out there that claim to support one or the other method, hence passing the object detection and then miserably failing on what one is trying to do.
I think it’s a bit narrow-minded to say things like:
Sure, in a perfect world. But the world isn’t perfect, we still have to deal with web browsers that will act like they support what you’re trying to accomplish, but that then won’t support it a 100% or stable enough. Web interface development comes down to experience in web browser behavior, so it’s a bit pig-headed to say to never use something that in some cases will be a necessary complement. Web developers should use object detection as far as they can, but be ready to swallow their pride and use some browser detection to cover up for web browser flaws if necessary.
I mean, what counts in the end is the result, isn’t it?
Sooo…
Last Tuesday I resigned from my job. I will stay with them until May 24th to fulfill some of my obligations, have some vacation and then start working for Know IT June 5th. This is something I really look forward to and I’m really eager about it!
Of course everything is relative, but the plan (for the moment), is that I will be working with packaging their CMS offer where they use the EPiServer product, and I will also be doing some general consulting work developing assorted web GUIs.
I hope to be creating stunning web interfaces that are based on CSS, semantically correct and at the same time addressing accessibility concerns.
Today I want to share a revelation I’ve just had: there are so many talented Dutch developers out there! I just wonder why it is so. Normally, it seems to depend on the climate of people’s country; for a natural reason Sweden has got a higher percentage of web developers than Italy (this is merely an educated guess, I have no numbers to back it up).
But the Netherlands? Sure, they get their fair amount of rain (and flowers, windmills and clogs), but I see no apparent reason why skilled people seem to be concentrated there. They have, as far as I know, a pretty warm climate otherwise.
Dutch developers whose blogs I try to read frequently are:
Two short topics today (see the other one below). This one is about what I wrote about in the beginning of April, how to structure one’s CSS file. Now the more well-known Douglas Bowman has written a post where he explains some of his tricks.
And, as I also wrote in two comments to Douglas’ post, I use Bradbury Software’s TopStyle for writing my CSS, which gives me the possibility to expand or collapse CSS rules by my choice.
Also, one thing I think is missing in CSS is a class-like grouping method. For instance:
Today, a rainy and gloomy day in Stockholm, I thought would be a good day to talk about sIFR. Since the authors of sIFR (Mike Davidson and Mark Wubben) have written extensive and thorough explanations themselves, I won’t write too detailed about it here.
Version 2 is also just released.
However, there are three things I want to cover; Why sIFR has arisen, the concept and my opinion about it.
Why
The different options for using typography on the web are extremely limited to a few basic fonts that can be taken for granted in the visitor’s computer. This has held ADs, Interface Developers and their likes back with fonts like Arial and Verdana. Enter sIFR.
The concept
Basically, it is:
…a method to insert rich typography into web pages without sacrificing accessibility, search engine friendliness, or markup semantics.
The code for this doesn’t lay in the XHTML/HTML file, it is done through a JavaScript and a Flash file. This results in that the code will look something like this: <h3>My heading</h3>. Then, the magic begins: if the user’s web browser supports/has JavaScript activated and the Flash plug-in, it replaces the heading (or several headings, if that’s the case) with a small Flash movie that draws in the text at the desired size but gives you the ability to have any font you want that is also anti-aliased.
For people without JavaScript capabilities or the Flash plug-in, it simply outputs the H3 as normal.
My opinion
All in all I think it’s for a very good purpose, and I really appreciate when people think outside the box. I’m also glad that they have thought of the accessiblity perspective on it, and that there’s no tampering with the XHTML/HTML. As the authors themselves state, it should be used with moderation, mainly for headings and similar elements.
A common objection is: “Why don’t you just use images whose text and size will be dynamically generated on the server?”.
Well, each image is a separate request to the server, and, as opposed to images, Flash movies generated through sIFR will scale accordingly to the font size the user has set in his/her web browser. The downside, however, to that is that it only scales when loading the docuemnt, not when the user resizes his font text on-the-fly. Personally, I use Ctrl+ or Ctrl- all the time in Firefox while browsing web sites that don’t have a font size I like. This is merely a guess, but I think many users surf that way, they don’t just have font-size large for every web page they visit.
Once can argue that you will reach a wider audience if you use images, since it is very likely that more user’s will accept images than JavaScript and Flash.
Images placed directly in the XHTML/HTML code also downgrades nice to screen readers if you use the alt attribute correctly.
What you choose is up to you. I prefer having options, and I will most likely choose using image replacement or sIFR totally depending on the situation and project.
Since most of my readers are very interested in CSS and many of you know who Dave Shea and Molly are, I thought I’d try and write a review of their the Zen of CSS Design book, that I just finished reading. One reason is to give my personal view on it, and another is to maybe give you some idea if this book is for you or not.
First, I just have to say that in the “About the authors” page, it’s hilarious that (to me) Dave looks like Molly’s boy toy… 🙂
With that aside, let’s start from the beginning. I love the cover and the format of the book. Glossy colored pages are so much nicer than the developer books I usually read. When it comes to the format, I’m not sure if the credit should go to this book, or to the New Riders publishing company (I don’t know, since this is the first book from New Riders that I’ve read), but either way, I love it.
The book is about the incredible css Zen Garden web site, which is a showcase for using the same well-structured XHTML file for over 160 different designs, all solely based on the content of their corresponding CSS file. The web site is an invaluable tool to show people what can really be accomplished with CSS, and this book covers some of the different designs’ code, color, images, typography, concept etc.
Maybe this is just me, but I felt that the book is mostly written too much from a designer’s point of view. And to be fair, designers are the ones behind the different designs, but I have never myself, or met any other that has, had the role of being the designer and the one coding the CSS. In “my” world that’s two different roles, normally an AD and an Interface Developer. I don’t know what it’s like in the rest of the world, but here in Sweden the word “Web Designer” has a bad ring to it; to me it symbolizes the first developers in the beginning of the commercial internet era, the ones that were hard-coding the pages and doing everything from the design and copy writing work to the interface coding.
With that said, I have to admit that some of the topics in the book are things that will (probably) never apply to my professional role and I won’t browse through those chapters as a reference in my daily work, but they were still interesting to read one time.
Getting back to the format of the book: every chapter has small boxes in the margin, usually named “tip” or “note”. They turn out to be links to very useful web sites with solutions to and ideas about handling different scenarios. Personally, I’d wish that the content of some of those linked web pages were discussed in the book (some of them are mentioned in the text, but not much more). I think the book would’ve been more interesting if they had been a part of it, instead of only focusing on having a different css Zen Garden design as a starting point all the time. On the other hand, maybe that’s the whole point of this book. I don’t know. But to me it could’ve been the ultimate CSS/interface developing book, but now it’s “merely” a guide to the different designs in the css Zen Garden.
The chapters are:
View Source
Design
Layout
Imagery
Typography
Special Effects
Reconstruction
I think it started off great with the View Source chapter, but after that it just wasn’t as intriguing. Bits and pieces of the other chapters were interesting per se, but not extraordinary. The last three chapters got more interesting though, starting with chapter five, Typography. I don’t regard myself particularly skilled in that area, so I gained something from it. Then chapter six and seven, Special Effects and Reconstruction, respectively, had some nifty things to pique one’s curiosity.
The Closing Thoughts was one of the better parts of the book, with good advice and introducing a link to Dave Shea’s CSS Crib Sheet.
However, there are two things that the book promotes (in some places), which I don’t like:
Pure CSS Menus
I can live with changing the look of a link with :hover, since it’s more of a state, but I think creating menus belong in the behavior layer.
Take, for instance, this sentence in the part about the Tulipe design:
…you can always default to JavaScript for dynamic menus. There’s nothing wrong with that, but CSS allows you to do it more elegantly…
It’s exactly this general attitude, that it’s so easy and elegant to do it in the CSS file, that I personally don’t like. I express my opinion more detailed in my Three separated layers, capisce? post.
Browser elitism
The book is full of mentioning things that won’t work in IE on a PC, and I agree that it’s important that all of IE’s shortcomings are brought up. I also like that it is being addressed in how to write the CSS code to handle them. The thing that bothers me, though, is that there are several designs covered in this book that delivers more stunning designs and effects to more competent web browsers, like Firefox and others, while serving a more bland version to IE. That, to me, is showing a browser elitism attitude, and that way of approaching things is exactly how IE got away with its different proprietary techniques that later resulted in people writing code that only worked in IE. Sure, in the book’s case, the extra effects are written according to the W3C recommendations, but personally I think that one should do it’s best to deliver an equal design and its effects to all of one’s targeted web browsers.
Coding wise, as in all books, there are some minor flaws and typos that aren’t even worth bringing up. One thing, though, that got to me, was a part where catering to IE 5.x incapabilities of centering content with text-align alternatives, instead of the correct way with using width and margin:0 auto;, is refered to as a hack. The code:
Using text-align in a clever way is not a hack to me. The Box Model hack is a real hack. Maybe I’m just nitpicking, but I think its a vast difference between a smart, validating and correct solution and an actual hack.
Another thing:
In some chapters, especially in the last one, there are numerous places with sentences like:
If you go to the web page, you can see the full CSS…
Sure, but what’s the point of buying the book then (except for the explanations)? I understand that the different chapters can’t have CSS code running page up and down, but it would’ve been nice with an appendix of the different CSS files, to get a feel of the whole structure (and not having to resort to a computer, while sitting out in the Spring sun and reading…).
All in all, despite my criticism above, I do like the book. It’s a good read, but not as amazing as I had hoped for. Too much focus on the design, and to little of solving problems all the way, discussed from every angle. Maybe too many designs covered instead of focusing more thoroughly on fewer ones?
However, I’m convinced that many people will gain a lot from reading it, and it shows off some cool CSS.
PS. A little bit over a month ago, Tommy wrote a post about this book and some of his opinions about it. DS.
).
in the