So, after applying some border-radius styling to my navigational hyperlinks, right here on shubox.net, and knowing full well that Opera does not yet support the border-radius property, I check out the look to make sure that all’s well and there are no nasty surprises. But on this occasion there was a remarkable consequence!

You can see from the above image, that Opera somehow splits the background borders on the contact and services links when going to a new line. This behaviour makes no sense at all and I’m surprised at Opera.

Luckily, I immediately wondered what would happen if I used another little-used CSS property: inline-block. This effectively creates a self-contained block-level element while allowing it to remain inline within it’s parent. As you can see from the next image, this did the trick.

You can see that the ‘contact’ link is now happily inline and unbroken. Adding inline block meant that the link became too padded – this is due to the element now occupying it’s own space and taking it’s relative size values from the line-height rather than font-size. A little CSS ‘fixing’ was needed to stop the links looking bloated. Specifying the line-height for the element and removing most of the existing padding was sufficient to regain its previous elegance.

As a matter of interest, those viewing this article, and indeed this website on a browser that doesn’t support the CSS3 border-radius standard (Opera, and all versions IE most significantly), here’s how the rest of us see those links.

So much prettier don’t you think?

Mark Boulton (typography evangelist) responded via twitter by chiming that Web Designers should learn typography and only then can they be worthy of the esteemed title “Web Designer!” Thus disagreeing with Mike.

So this is where I stand. My belief, and one that I’ve held for many a year is that a good web designer should fundamentally know how to ‘design’ and should understand the ‘web’, how it works, who uses it and what it’s for. The nature of the web relates most closely to print design, so some knowledge here would be of benefit as does an understanding typography, layout and crucially how the web differs from conventional print. Ideally the Web Designer should be free to design without too much concern about how the design will be converted into an actual website. He (or she of course) does not need to know the code.

Why do I think this? Well, any type of design, whether it’s for the web or not has a brief – that brief lays out the intended function of the ‘thing’ that is to be designed. So, in designing a website, you must facilitate visually the intended functionality of the website. In a typical website the principle aim is to present information. That information needs to be presented in a way that a.) can be found; and b.) is easily readable. If navigation is needed, it needs to be clear and concise, if not bleedin’ obvious. If a web user needs to be enticed into clicking a button, the designers job is to understand that and to somehow visually entice the user to click that button – either by using existing methodologies or even inventing new ones. A pure web designer does not, in my opinion need to be aware of any coding practices in order to do this design job. Rather, he needs a solid grounding in the principles of design and an acute awareness of how the web is used and can be used.

When coding a website, the nature of the information, or the ‘type’ of data needs to be determined so that it can be coded correctly. Accessibility concerns need to be dealt with using good coding practices. The code needs to be machine readable, the content needs to be discoverable, searchable. Styling needs to be robust, it needs to be coded to accommodate a range of user agents (web browsers to you and me) so that it looks the same. Event coding using javascript needs to degrade gracefully and the site must function fully in case javascript isn’t present… these are problems for the front-end developer. In an ideal and purist world the Web Designer doesn’t and shouldn’t have to concern himself with any of this.

I think Mike Kus has been somewhat naive in his blog post and unfortunately, as a ‘celebrity’ (re: previous post) he won’t ever need to be fully aware of this. His adoring public will convince him he’s right. C’est la Vie.

- Of course, I should qualify this entire post by stating that in this day and age, many web designers do indeed code, and do it well. A freelance web designer is unlikely to be fortunate enough to be allowed the luxury of doing nothing but visually mocking up a website, so at least one of Mike’s ’5 reasons why…’ is valid.

This blurring of roles has led to something of an identity crisis in the web world, as many designers turn to coding, they can no longer be known as ‘designers’ per se. Nor can they be known as web developers because they don’t do back-end scripting. So you may come across titles like “front-end web developer” which is beginning to stick although strictly speaking, that would be the ‘developer’ who specialises exclusively in the website’s mark-up, the HTML/CSS. So it’s no better a description as web designer. Anyway, that’s a topic for another post perhaps.

The responses to his post began fairly sedate, mostly by people who agreed with him  (even some who were arguably those ‘mediocre’ web designers he was talking about) and were glad that he’d written his post. Then some who disagreed but still all was well. Then of course, it soon degenerated into a witch hunt, by the friends of the mediocre web-starlets (who obviously knew who he was talking about) and their shirt-tail grabbing groupies – who see a befriending of those clique members as a way into the glamourous  jet-setting lifestyle that is the provence of todays web design celebrity. Dare I say it, it was the weaker designers who seemed most offended.

Today, I witnessed in small part exactly what Brendan was irked by. Now, let me begin by saying that Mike Kus is one of my favourite web designers, but the keyword here is ‘Web’. Posting on Twitter, Mike made available a link to show off the new 404 page on the recently launched “future of web design” website. Quickly following this posting, I witnessed all the congratulatory comments for his nicely designed (if not one of his best, in my opinion) 404 page that he must have been pretty proud of.

But none of the comments seemed to take into account that, as pretty as it might be, it must first and foremost perform its function (the definition of ‘design’ after all). A 404 page’s function is to make the visitor aware that they’ve entered or followed an incorrect URL – they’ve attempted to view a section of the website that doesn’t exist. That’s it. To make the page more helpful, a web designer might include a link back to the main menu of the website. So, short and sweet – in/out. The load time for this kind of page should be milliseconds and it’s size needn’t be any greater than 2kb.

The 404 page offered up by Mike Kus and Carsonified to such adulation and fanfare weighed in at 600kb! Not only that, but the site rendered in its entirety on an iPhone, where over half a megabyte has serious implications for those fair-usage mobile internet users.

So, the comments coming from the ‘crowd’ should have indeed been congratulatory on the look of the page and its cute if utterly unnecessary animation – that’s fine, but they also should mention these fairly fundamental shortcomings (as I did). Curiously, Mike didn’t reply. Hmmm.

The morale of this story:

By all means, congratulate your peers or respected betters when you have opportunity, but remember what the web is for when you’re making that judgement. Always keep in mind the function and purpose of the page you are designing/critiquing and make sure it’s accessible to all of that group of web users that wish to access it. If you are going to give an opinion or a pat-on-the-back to someone for their efforts on a website, please try to be objective about the absolute success of the site before blindly pumping their ego. This way, we can all help to create a beautiful, accessible and functional web.

I want one, but I’m not going to be drawn in by the hype just yet – I’m gonna test one out…somewhere. Leeds doesn’t have an Apple Store, so whenever KRCS gets them in. They’d better hurry though!

UPDATE! Well, I did manage to have a play with Apple’s new Magic Mouse in both PCWorld and the Manchester’s Arndale Centre Apple store and… I don’t like it. Once again apple have proved that they really cannot make a good mouse. I found it ergonomically awkward and the whole thing moved when I swiped across it.

A lovely idea, but just the wrong size and shape to make it a usable mouse for me. Such a shame.

Ok, many web developers might be prepared to revisit old sites and add in this meta tag and conceivably might not find it too much of a hardship adding it to current developments. Web designers and developer are after all, conscientious souls who would like to see the web ‘just work’ for everyone, irrespective of browser.

The biggest flaw in Google’s master pan here is IE6 users. These are people who either don’t upgrade or install anything ever, or institutions, which have such a complex or large framework (like being stuck a win2000 server) that makes it impractical or too expensive to upgrade – and given that their system works just fine with IE6, their argument would be why upgrade?

If these institutions were to be so bothered about their staff using the web that they would use valuable resources to install this Chrome frame plugin, then they’d be as well to simply install Firefox and have a secure web browser that renders sites as they should be. An IE6 plugin can be installed in Firefox for intranet sites that require it and would make much better sense than adding a new plugin to an old un-secure browser when there’s a perfect opportunity to add a legacy plugin to a modern, secure one.

It’ll be interesting to see how Chrome Frame develops from here, but I found it perplexing that google would have devoted such resources to such a non-problem.

Further reading: http://code.google.com/chrome/chromeframe/developers_guide.html , http://www.sitepoint.com/blogs/2009/09/28/google-chrome-frame-technical-details/

The image below shows the problem a little better than my previous post I think.

You can clearly see the blurring in firefox.

It’s an odd problem, and one which I suppose doesn’t rear it’s head very often. In fact once I’ve converted these list items into links, it won’t be a problem for me either, because the border-top will be placed on the link and not the list item – thus solving the problem. But curious never the less.

Related posts: The curious case of ‘bleeding’ CSS borders

Safari 4.0

FireFox 3.5

This phenomenon is also evident on the Windows version of FF3.5.

IE8, Camino (effectively FF2) and Opera all display the borders ‘correctly’ like Safari 4.0.

This is an irritation for me, and with Firefox fast becoming the second most widely used web browser, I hope it doesn’t begin to suffer from the same idiosyncrasies as the dreaded IE6! Of course, it might be that FF3.5 is the only browser that’s displaying the borders accurately – but somehow I doubt it. Further research is needed…

Update:
After a little more experimentation, it appears that this phenomenon isn’t quite unique to Firefox 3.*. Using good old browsershots.org I tested my CSS is a huge variety of web browsers, including Konquerer and Seamonkey on Linux, Safari, Chrome, Opera, and Firefox on all platforms. Firefox 2.0 renders the border edges seamlessly, but in all FF browsers from FireFox 3.0 to Firefox 3.5.1 the bleed is evident. The only other browser to exhibit this bleed is Google Chrome – which is odd considering that it’s a Webkit browser akin to Safari.

In a further experiment, I tried re-ordering the border properties in the CSS file (placing the border-right rule after the border-top and vice-versa’), in case it was a curious cascade problem, but that made no difference. Next I used CSS’s specificity feature to leave no doubt as to how I wanted what to render. But still no change. Finally I removed the relative positioning I was using when I first noticed this problem… but that had no effect either (besides moving its position of course) and the bleed remained.

This effect may not be a bug at all, but merely a curiosity and is somewhat idiosyncratic of those two browsers. It’s certainly annoying, I know that!

Related posts: Firefox and its Blurry edges.