The story in short: I installed IE9 mainly because I was curious to see how good is the support for some of the new CSS3 properties — rounded corners, box-shadows, text-shadow, gradients, transitions, and so on.

So, as soon as IE9 was officially released, I installed it, then restarted my Win7 machine, and lo and behold! in one of the first designs I tested in it, I found a new bug (new in the sense: a bug that I never encountered in IE8 or IE7): a strange one-pixel shift in the background image of a page, when (un)certain conditions are met!

Here’s a test page:

http://www.optimiced.com/lab/2011/ie9-background-bug/

Test conditions:

– Internet Explorer 9 (you need Windows Vista or Windows 7; Windows XP is not supported).
– The browser window must be maximized.
– I tested with the following screen resolutions: 1680×1050, 1440×900. (Not sure if bug will happen if your screen is larger or smaller.)
– Open the test page, wait for it to load.
– With the mouse, scroll down to the bottom of the page, then up to the beginning. You have a 50%/50% chance to see a one-pixel shift in some part of the background of the page, in the upper part! (At least, I see such 1px shift…)
– If you refresh the page, bug is gone. If you scroll again down-up once or twice, bug is back again!
– (Update 1) If the Menu Bar is not open in IE9, the bug is not triggered. If the Menu Bar is open, it is triggered! (Just in case: screenshot of the toolbars that are open when the bug can be reproduced: Menu bar, Status bar.)
– (Update 2) If you have AERO disabled, the bug won’t show up (for example, if you use Windows Classic or Windows 7 Basic theme). If AERO is enabled (Windows 7 theme, with AERO = “ON”), the bug is there! (Big thanks to Adam Kiss, who made some tests.)
– (Update 3) “Show tabs on a separate row” should not be enabled (and it’s not, by default). If you select “shows tabs on a separate row”, bug will disappear too (?).
– If you put more Lorem Ipsum text in the main column, bug is gone.
– If you reduce (or increase?) the height of the main column (#content) in which the Lorem Ipsum text is located, the bug no longer appears. Currently, the div#content has a min-height of 500px.
– If you minimize the window of IE9 and then back again to maximized state, the bug disappears (page is re-rendered after a minimize > restore-back-to-maximized operation).
– The 1px shift occurs only in the upper part of the background image, and quite randomly.

Now, the background image is applied to the body element:


body {
background: #8F8F8F url(../img/body-test.png) 0 0 repeat-x;
}


…and there is nothing special in the code.

The left part of this background-image is the original image, the right part is for testing purposes — the horizontal lines help see if there are any shifts in the background image position. Otherwise, that was the original.

After many tries I discovered that the format of the background image does not matter (PNG, JPG, GIF…) as well as its size.

You can scroll with a mouse or the up-down arrows on the keyboard.

Of course, it’s possible that something in my setup (Win7/IE9) is wrong and so any kind of third-party confirmation for the existence (or non-existense) of this bug would be appreciated! (Btw, I never saw such a bug in IE7/8, Firefox, Opera, Safari, Chrome. Only in IE9.)

Here’s how the test page is supposed to look:

And here how it looks after a couple of scrollings down/up:

Also please note that after scrolling down/up, and then mouse-overing the elements in the navigation, another visual strangeness happens:

So, in “ideal conditions”, the page should look like this, but after some scrolling, here’s how it looks like (or even like this).

* * *

Otherwise, testing IE9 is fun — for now I see that CSS3 transitions and text-shadows are not supported. Border-radius and box-shadow are supported, though, which is nice. I’ll be testing more.

Any help is appreciated! Did I discover a bug? If yes, what triggers it?…

Eric Meyer wasn’t late to create an HTML5/CSS3 version:

http://meyerweb.com/eric/html-xhtml/html5logo/
(logo will be displayed very well inside Opera, Firefox, Safari, Chrome…)

Also interesting to take a look at this HTML5 logo generator, made by Daniel, with the <canvas> html element:

http://people.opera.com/danield/html5/html5logo/
(for best design/functionality experience, open in Opera 11.)

:-)

But sometimes this is the easiest (or the only) way to deal with the situation — let’s suppose, for example, that you don’t have access to the HTML but to the CSS files only. In this case, the following 4 lines of code might be useful:


body {
color: red; /* all browsers will see this */
color : green\9; /* IE8 and below */
*color : yellow; /* IE7 and below */
_color : orange; /* IE6 */
}


As you can see, it’s easy to write rules that will be “seen” only by IE8, IE7 or IE6, or a combination of these three IE versions. And let’s hope IE9 will need no hacks! ;)

(via #)

To which I replied: @zeldman I bet it smells like a good cup of coffee! ;-)

And Jeffrey replied: @optimiced How right you are.

This inspired me to quickly create the following illustration in Fireworks:

(NOTE: Coffee cup is re-created from scratch in Fireworks, although it looks like this illustration. The final appearance of my little drawing was also inspired by @molif, for which I’d like to thank her!:-)

As you probably know, users which do not use a mouse but navigate webpages with keyboard only, need to see outlines on links when they tab through them. This helps them visually understand which link they will activate.

A fairly new trend is to remove (suppress) this dotted outline on links to make pages look “nicer” to the eye. While design may look “nicer” and more “Web 2.0″ to some, when this outline is removed, the accessibility aspect of this remains, and it is very serious.

But Roger Johansson suggested a much better approach: remove links from :active state only!

This is the article that he recommends to all Web developers:

Better CSS outline suppression

Basically, what happens:

You remove the dotted outline from links which are only clicked with the mouse, while keyboard users will see the outline normally!

How? Just use this bit of code, and that’s it:

a:active {outline:none;}

Excellent tip!

I promise to myself that if I will ever try to remove the outline from links, I will do it in this, much more accessible way! :-)

You can download it for free from here:

www.ms-studio.com/FontSales/anonymouspro.html

But my personal preference for a monospaced font is Consolas. As far as I know, this new font by Microsoft can be downloaded for free, too; Consolas is readable and suitable for all kinds of code — in my case, I most often see XHTML and CSS code blocks in it:)

{ Some drafts in my blog were hidden really deep, so… ;-) }

{ This story developed somewhere in July 2009… }

Twitter is an amazing… media? Social network? Means for ultra-fast transfer of news, wisdom, stupid things and “important” things like “I am drinking coffee now”? Something like IRC, but with an option for SMS, filtering, search, etc.?

Twitter is all of this simultaneously! :-)

…I am a Web designer and (partially) a geek, so it was very interesting for me to follow the discussion in two of the latest publications of Jeffrey Zeldman:

www.zeldman.com/2009/07/02/xhtml-wtf/
www.zeldman.com/2009/07/07/in-defense-of-web-developers/

…where the consequences of discontinuing the work on the XHTML 2 standard, and what will happen with XHTML 1.0, HTML 4.01, as well as with the new HTML 5, were passionately discussed.

At some point, in the Zeldman’s website, a strange bug appeared (in Firefox 3/Win): somewhere around 3/4 of the page with his last post and the numerous comments below, the content suddenly was disappearing (screenshot). Without a reason. The page itself was validating perfectly and there were no problems with the encoding or the HTML/CSS code.

Jeffrey noticed the problem, too, and was trying to solve it for quite a long time. The assumption that a problematic pingback with UTF-16 encoding was the culprit, was not confirmed.

I tried to investigate, too, out of curiosity, without any positive results, though.

Finally, I assumed that there’s a CSS bug in the rendering engine of Firefox/Win which (maybe) can be fixed with some new CSS rule. One of the readers of Zeldman’s blog mentioned that he tried to check something with Firebug, so I quickly made a test page + CSS file with the rule which (supposedly) was fixing this issue; then I tested in Firefox 3.0.11/WinXP. The problem was gone! :-)

Only one line fixed the problem for Firefox:

div#wrapper {
overflow: visible;
}

Then I’ve spent some more time to test in detail if the change did not affect any other popular browser (Opera 9.6, Safari 4, Chrome 2, IE7, IE6) and finally, I wrote to Zeldman, proposing him the fix for Firefox.

Zeldman replied:

@optimiced Will try as soon as I’m back on my feet. Thanks wise one.

Soon after that, Zeldman implemented the fix, and the design was fixed! :-)

Unfortunately, the fix introduced a new bug — the background of the page was “flashing” for a second or two on each page load because overflow: visible caused the background of the element #wrapper to load with a little delay (before: overflow: auto).

Well, after some more thought invested, I and another reader suggested two additional simple CSS solutions, which at a later stage proved to play very well together and fixed the “flashing problem” in all browsers — Firefox and Safari included! :-)

Last (but not least), I would like to say that Jeffrey Zeldman is a cool dude! After the whole story with the CSS bugs in Firefox and the red background flash was over, Jeffrey thanked me personally and added me to his Twitter list, and then promised to send me the new (third) edition of his popular book about Web Standards, as a present! (I think that somewhere in the CSS on zeldman.com there are some more acknowledgments hidden;-)

It’s always nice to communicate with such people, even if with messages only 140 characters long! ;-)

So, I am pleased to say, too: “Jeffrey, thank you!” :-)

* * *

Ah, and finally, why did I start this blog post with the question, what exactly is Twitter?

Because, after using Twitter for at least a few years, I can say that Twitter allows quick, precise communication in a new way. Comments in blogs, feedback forms, emails, allow us to communicate, too, but Twitter is something different. Something, which I cannot define precisely, but something, which fulfills its purpose and is also fun!

This is why you can (still) find me on Twitter (but you won’t probably find me on Facebook)… and, you can find me on my personal blog, of course! ;-p

It’s a fact that:

1) Lately, the HTML 5 standard gains up in speed.

2) XHTML 2.0 probably will never become a successor to XHTML 1.0. In fact, XHTML 2.0 probably will never exist at all.

3) Quite a few prominent Web designers and CSS/HTML coders are abandoning XHTML 1.0 and go back to HTML 4.01 (some of them even experiment very seriously with HTML 5).

What HTML standard for documents do you prefer? And am I the only one who (still) prefers XHTML 1.0 over HTML 4.01? :-)

It followed the interesting discussion at mezzoblue — I managed to read almost all of the comments there!

But, sometimes, it is not very clear to me as to where & why are going the Web Standards, guided by W3C.

After HTML 3.2, HTML 4.01 came, then the XHTML 1.0 standard was adopted, and now HTML 5 is developed? There’s almost no logic behind the versioning; plus, we have first the HTML language (which, in turn, derived from SGML), then W3C decided that it would be a great idea to combine XML + HTML (and so, XHTML 1.0 was ‘born’), and finally, they turn back to the idea of ‘pure’ HTML, and in the new standard (HTML 5), the ‘X’ is missing…

What’s up next? I don’t know.

Personally, I am a bit puzzled by the fact that the first standards, which I’ve learned, when I started doing Web design, were HTML 3.2 and HTML 4.01, then came XHTML 1.0 (“The Next Best Thing Since Sliced Bread”, after HTML 4.01) — at this time I had to learn how to close tags, which you don’t have to close at all (such as img and br, for example)… And now, after XHTML 1.0, it’s HTML’s turn again?

For now, I don’t plan to change my coding style. XHTML 1.0 Transitional & Strict are doing a great job.

Besides, using HTML 4.01 has certain drawbacks (compared to XHTML 1.0):

For example, under HTML 4.01, the closing of some tags is not obligatory at all — <p>, <li> can be opened, but you don’t have to close them after that, so the following two examples are both valid:

example 1:

<ul>
  <li><a href="#">Lorem</a></li>
  <li><a href="#">Ipsum</a></li>
  <li><a href="#">Dolor Sit</a></li>
</ul>

<p>Lorem ipsum...</p>

<p>Lorem ipsum!</p>

example 2:

<ul>
  <li><a href="#">Lorem</a>
  <li><a href="#">Ipsum</a>
  <li><a href="#">Dolor Sit</a>
</ul>

<p>Lorem ipsum...

<p>Lorem ipsum!

This could lead to the situation, when the following example will be perfectly valid for the W3C validator:

example 3:

<ul>
  <li><a href="#">Lorem</a>
  <li><a href="#">Ipsum</a></li>
  <li><a href="#">Dolor Sit</a></li>
</ul>

<p>Lorem ipsum...

<p>Lorem ipsum!</p>

…but it will not look very well as code.

Under XHTML 1.0, there is no such problem. Only example 1 will be valid, when all opened tags are correctly closed. Such code is easier to be checked for any accidental mistakes, and it can be also read much easier by a machine.

Also, you don’t have to use quotes for HTML attributes under HTML 4.01.

example 4:

<div class=container>
  <p>Lorem Ipsum...</p>
  <p class="blue">Dolor sit...</p>
</div>

Code like this will be valid for HTML 4.01, but not for XHTML 1.0. Under XHTML 1.0 only the following example will validate (when attributes are quoted):

example 5:

<div class="container">
  <p>Lorem Ipsum...</p>
  <p class="blue">Dolor sit...</p>
</div>

There are some more differences with HTML 4.01. Special characters like ‘&‘, " (quotes), etc., are not necessarily encoded (under XHTML 1.0, the ampersand sign (&) should be encoded as &, for example).

Let’s not forget also that most of today’s CMS systems are programmed with XHTML 1.0 in mind (and not HTML 4.01), and if you use HTML in such a situation, it’s possible that you’ll end up with some ‘code mix’ — HTML & XHTML together in one page; in such a case, you’ll have to modify the way in which the particular CMS is working, or the code won’t validate at all…

* * *

If you are a good designer, you won’t have any problems using both HTML 4.01 and XHTML 1.0, without any noticeable difference. But even if you have a lot of experience in this area, using HTML 4 might hide certain caveats — it is much easier to allow certain types of mistakes, which the validator won’t find at all (such as opened, but not correctly closed tags, etc.). From there to ending up with some kind of a tag soup, is just one small tiny step… On the other hand, XHTML 1.0 is much more strict in this aspect, and will learn you easier how to write well-formed (and well formatted) code.

I am observing with much interest the development of HTML and CSS, but for now I did not hear any strong arguments so that XHTML 1.0 to be abandoned (in favour of HTML 4.01, for example). As to HTML 5, for now it is only a working draft, and it has a long road to go, before it becomes a mature and well-supported standard…

I prefer to use some new features, present in CSS3, which modern browers already support (like CSS rounded corners — Firefox and Safari have perfect support for them), than trying to start coding again in HTML style, without the ‘X’:-)

I might be wrong, but I prefer the stricter way of coding, which XHTML 1.0 imposes… Just a simple habit?

May be! :-)

But first, a couple of words about the reasons why support for IE6 should be limited.

The Reasons

Dan Cederholm: How I Might Deal with IE6

Roger Johannson: No more pixel perfectionism in IE 6

Basically, the idea is as follows: Limit the time, which you dedicate to IE6, to the possible minimum. Yes, the design will look a bit different in this old browser, but so what? The important thing is that the design should work, and that there are no problems with the accessibility or functionality of the website.

In certain cases, you can even decide, if you wish to ensure a minimum support for IE6, or completely ignore it, in a similar way that Netscape 4.7x was ignored years ago, using the @import command for CSS styles.

For IE6, you can use IE conditional comments, like in this example:

<!--[if gte IE 7]><!-->
  <link rel="stylesheet" type="text/css" media="screen, projection" href="screen.css" />
<!--<![endif]-->

“Translated” to human language, this small piece of HTML code means the following:

If Internet Explorer is version 7 (or higher), the CSS file ‘screen.css’ will be loaded. Otherwise, the file won’t be loaded (IE6 or lower). All other browsers (Firefox, Opera, Safari, etc.) will load the file screen.css quite normally. I have tested this in Firefox 3, Safari 3.2, IE7, IE6, and the code works perfectly.

Here’s the test example

Open this page in Firefox, Opera, Safari or IE7+ — the background of the page should be green, and it means that the ‘screen.css’ file is loading normally.

Open the same page in IE6 (or even older version) — the background should be white, and it means, ‘screen.css’ is not loading for it.

And now about my browser stats.

I decided to check, how many site visitors of my personal blog are using Internet Explorer, how many of them are using version 6, and also, how stand up the numbers for Firefox and a few other popular browsers of today.

The Numbers

As a base for my comparison, I took the last month (Jan. 22 — Feb. 22 2009), and I also compared this period with the same period, but 1 years ago (Jan. 22 — Feb. 22 2008).

Firefox (Jan. 22, 2009 — Feb. 22, 2009): 56.18% of all visits
Firefox (Jan. 22, 2008 — Feb. 22, 2008): 49.79% of all visits
Firefox: +6.39% increase in number of visits, during a period of 1 year

Internet Explorer (Jan. 22, 2009 — Feb. 22, 2009): 33.47% of all visits
Internet Explorer (Jan. 22, 2008 — Feb. 22, 2008): 40.90% of all visits
Internet Explorer: -7.43% decrease in number of visits, during a period of 1 year

At the present moment, Opera is around 5%, Chrome is around 3.2% and Safari around 1.5% (of all visits to my site). All other browsers (Mozilla, for example) have so low numbers, that they can safely be ignored.

The tendency is clear. Firefox slowly, but constantly is increasing its influence, while Internet Explorer makes exactly the opposite. Safari, Opera, and also Chrome, are present in the whole picture, but quite modestly. Firefox and IE are the “big players”, or at least, this is true for my blog visitors… :)

Now let’s see the numbers for the different versions of IE.

IE7/IE8 vs. IE6

IE7 (Jan. 22, 2009 — Feb. 22, 2009): 55.22% from the total share of IE in the stats
IE7 (Jan. 22, 2008 — Feb. 22, 2008): 41.59% from the total share of IE in the stats
IE7: +13.63% increase in number of visits during a period of 1 year

IE6 (Jan. 22, 2009 — Feb. 22, 2009): 43.64% from the total share of IE in the stats
IE6 (Jan. 22, 2008 — Feb. 22, 2008): 57.18% from the total share of IE in the stats
IE6: -13.54% decrease in number of visits during a period of 1 year

The trend here is also clear: IE6 slowly loses grounds, while IE7 is becoming more and more widespread.

IE8 Beta also appears in the stats, but the numbers are very low — around 1%.

The Verdict

Firefox: 56.18% from all visits to the website
Internet Explorer: 33.47% from all visits to the website
— IE7: ~ 55% (of all IE visits)
— IE6: ~ 43% (of all IE visits)

In total, my users, which are using IE6, are less than 15%. All others use Firefox, IE7, Safari, Opera and Chrome.

Is 15% too low a number, so I can apply the CSS “filtering” for IE6? No, it is too early for that, I think.

But I guess that in 1-2 years the share of IE6 will become so low, that there really won’t be any point in trying to fix the XHTML/CSS code for it.

And then IE6 will become history, in a much similar way that Netscape Navigator 4.7x became history a few years ago — something which made me very happy at the time! :-)

Windows:

Microsoft Sans Serif: 99.61%
Arial Black: 97.82%
Franklin Gothic Medium: 97.58%
Palatino Linotype: 97.54%
Verdana: 97.54%
Arial: 97.13%
Courier New: 96.96%
Comic Sans MS: 96.83%
Tahoma: 96.79%
Lucida Console: 96.76%
Impact: 96.49%
Trebuchet MS: 95.97%
Sylfaen: 95.00%
Lucida Sans Unicode: 94.34%
Georgia: 92.97%

Mac:

Monaco: 96.91%
Arial: 96.62%
Courier: 96.48%
Helvetica: 96.48%
Arial Black: 95.78%
Verdana: 94.37%
Georgia: 93.53%
Helvetica Neue: 93.07%
Trebuchet MS: 92.69%
Geneva: 92.41%
Courier New: 92.12%
Gill Sans: 91.58%
Comic Sans MS: 91.42%
Times New Roman: 90.58%
Arial Narrow: 90.44%
Apple Chancery: 90.15%
Skia: 90.15%
Lucida Grande: 90.01%
Futura: 89.73%
Hoefler Text: 88.47%

*nix:

DejaVu Sans Mono: 92.31%
Bitstream Charter: 90.77%
URW Chancery L: 89.87%
Nimbus Mono L: 89.35%
Century Schoolbook L: 89.09%

In bold above I have marked 7 font families in total. They are those fonts, which are found often on Windows and Mac (simultaneously), and these are (in mixed order):

1. Verdana (sans-serif font family)
2. Georgia (serif font family)
3. Courier New (monotype font family)
4. Arial (sans-serif font family)
5. Arial Black (sans-serif font family)
6. Trebuchet MS (sans-serif font family)
7. Comic Sans MS (sans-serif font family)

Unfortunately, none of these 7 fonts can be found among the most widespread fonts on Linux/Unix. Looks like I was wrong, when I assumed, that Verdana, for example, is one of the most popular fonts on Windows/Mac/Linux — the full stats show that Verdana is available on more than 90% of Windows/MacOS systems, but only on ~ 50% of the Linux systems…

More interesting conclusions can be made from the two available lists (short and long), for me it is enough to know that there are at least a few font families, which can be found on Windows and Mac systems at the same time.

Or, at least, your chances are quite high that one of these 7 fonts will be available… :-)