I read an interesting tweet just now by Sergey ilinsky, saying that his bug report to Chromium was being ignored. A bug that let's you include css only for chrome WebKit browsers, like apple's safari and google's chrome. Look here for the example page., the text is red in chromium WebKit and black in other browsers. The HTML is valid in case you're wondering, so you won't catch it that way.

All you have to do is to write a phony include that only chromium WebKit browser ( today ) will detect and act upon. Like this:

<link type="custom/mime+type"
rel="stylesheet" 
href="css/chromehack.css" />

The type="custom/mime+type" is what does the magic. Chromium WebKit browsers will request the file from the server and add it to the document. What should happen is that browser shouldn't fetch the file or process it for that matter. The chrome team responded with a status: WontFix, which is wrong in my opinion. People will use this to write css to over come chromium WebKit bugs instead of learning what it is they are doing wrong.

The reasoning of the chromium team is:

Darin, given the number of web sites this would likely break I don't think we want to be this strict. If you disagree then I will re-open this.

I think that there is something to be said about this reasoning, but I am one of those people that wants browsers to be very, very strict... I understand that browsers don't want to "break the web", after all, who remembers the outrage that ensued when microsoft released version 7 of IE. A lot of people blamed IE for their own sloppy coding, breaking bad websites.

Why should this be fixed?

A lot of people write css to work around browser bugs, when they should go out and read the specifications. Very often I see people complain about bugs, they have done something wrong in their HTML. So when I see a reaction like the wontfix by chromium I think that a lot of people still will take the easy way out and choose the hack, instead of learning to do it the right way. Not knowing that they are walking a fine line, utilizing a "feature" in a browser which may be fixed at any moment, thus rendering their fixes obsolete.

So I hope that they will fix this soon, after all building browsers to allow sloppy coding is encouraging that very thing in my opinion. And yes, I know that the "we render anything you code, even our own front page garbage" is what made IE6 the greatest browser in it's time. But in the end it slowed down the web, as people were not encouraged to write proper code, but got away with building crap.

Update

Kyle made an excellent point in his comment. This is a WebKit bug or feature. The browser does not do anything wrong, as this is not being specified. So browsers can do what they want with it. He even makes some good points on how we could be using this. Still I am not conviced and urge people not to use this, as it will come back and bite you somewhere...

Here is a simple help to get you to choose the right method of prototyping a website:

Prototype method

Is this site being made for the internet?

yes no

HTML Photoshop

• HTML
• CSS
• Test page
• Question

I recently came across a tweet from a friend of mine Roy with an interesting take on marking up discounted product.

How do you guys feel about using - from <del>€ 27,70</del> for <ins> € 25,00</ins> for discounted products?

As I agree upon his approach, I had an extra option for it. In dutch we differ in writing and speaking of currency. In writing the € symbol comes before the amount, in speaking it comes after. So I thought about screen readers and came up with a solution.

Let's always put the € in full, so not as a symbol, after the amount and use CSS to present it in a proper manner.

So I propose we do this:

HTML

<p>
	from
	<del class="money">
		25.99
		<span>euro</span>
	</del>
	for
	<ins class="money">
		15.99
		<span>euro</span>
	</ins>
</p>

CSS

del {
	color: #666;font-style:italic;
}
ins {
	font-weight: bold;
}
.money {
	position: relative;margin: 0 6px;text-decoration: none;
}
.money:before {
	content: '€ ';
}
.money span {
	position: absolute;
	left: -9999em;
}

Test

I made a small example page for you to check out. Yes I know some things a quirky in IE, but for this example I don't care.

It looks quit nice and is in semantically correct, or so I think.

Question

What I am wondering is, is there anybody that reads this that can tell me what my proposed solution does to screen readers and the like. Is this more or less accessible, I think so, but I don't know. My knowledge of assistive techniques is not as good, as I would like it to be.

So please, let me know if I am right or wrong in the comments. I would love to hear your comments, here or on twitter.

• Introduction
• Code HTML CSS
• Results
• Screenshots
• Conclusion
• test page

I recently encountered something in my work that kinda baffled me. Apparently some (make that lot) people don't know one fundamental thing about inline and block-level elements.

The fact is that you are not allowed to nest them.

This seems to be a small matter, but it has all sorts of consequences for the styling of the front end. What a lot of people don't get is that if you serve the browser invalid html, which is what you do if you nest a block-level element ( div) inside an inline element (span), you are at the mercy of it. A browser, and lets not name names, has a though job as it is when rendering valid html. What it is supposed to do with invalid code is anybody's guess.

So to test this I created a small test page with some invalid HTML and some simple CSS. What I did is that I nested a block-level element, in this case a div, inside an inline element, a span. Below that I swapped the div with the span. Both examples got a unordered list with one li.

HTML

<span class="foo">
		<div>
			<ul>
				<li>list item</li>
			</ul>
		</div>
	</span>

	<div class="foo">
		<span>
			<ul>
				<li class="">list item</li>
			</ul>
		</span>
	</div>

CSS

I than gave it some simple css, which is below:

	body {
		margin: 0 auto;
		width: 40em;
		font-size: 1.2em;
		font-family: helvetica,arial,sans-serif;
	}
	#test {
		border: 4px dotted #ccc;
		width: 200px;
		height: 200px;
		margin-top: 5em;
	}
	.foo {
		border: 1px solid red;
		padding: 1em;
		position: relative;
	}
	.foo div,
	.foo span {
		background: #dee2ee;
		margin-bottom: 1em;
		padding: 1em;
	}
	span.foo li {
		background-color: #ccc;
	}
	.foo li {
		position: absolute;
		left: 100px;
		top: 5px;
	}
	div.foo {
		border-color: blue;
	}

The results

The results where surprising, some browers tried to interpret the css and succeeded ( in a way ), while others failed in nice and surprising ways. Mind you, I am not blaming browsers here. Let me repeat that:

I AM NOT BLAMING BROWSERS HERE
not even ie6, really not this time.

If you serve a browser invalid HTML, you get everything you deserve, in my not so humble opinion

Screen shots

Let's get on with the screen shots, which I will present without any comment. Again, if you serve a mess to a browser, you deserve all the trouble you get...

• 

  Safari 4 XP and Safari 4 os X

• 

  Opera 10 os X

• 

  Camino 1.6 os X

• 

  Firefox 3.5.3 XP

• 

  Firefox 3.5.3 os X

• 

  Internet Explorer 8 XP

• 

  Internet Explorer 7 XP

• 

  Internet Explorer 6 XP

Conclusion

Always validate your code, it will help you. I know that proper front end developers will do this without thinking and I will agree that using stuff like WAI-ARIA tags will invalidate your code, but when you do that stuff I hope you know your basics. Stuff like this I see primarily in html rendered by some back end system put together by someone who doesn't know what they are doing. I will tell (and have told) you what you're doing, you're overly complicating the work of the front end developer.

I mean, we could work around these quirks, but why should we work to correct mistakes easily avoided? It would only mean adding extra lines of code to the css, thus making it harder to maintain...

My proposition is that we, as front end developers, simply refuse to work with invalid code. It is only a source of trouble and will cause more work which will cut into the budget and so on.

Now my question to you all, do you see this and/or have any nice examples you would care to share in the comments or tell me about on twitter I would love to see them.

As I write this, I'm on my way to @media 2009 in London. This is my 6th visit to an @media event, including the to Ajax ones. I hope to see a lot of old friends and to make new ones.

I will try to update this post as the event goes on, so if your not there and want to know what happens: follow me on twitter to get short updates, a year ago I would have been live blogging but with this twitterthingy.....

Here are some photos, I took those instead of taking notes...

bing.com is the new search engine of microsoft. It could be great with the amount of smart people at Microsoft and the amount of money thrown at it. The search results are what you expect from any decent engine (a search for wnas puts me on top). But what got me baffled is the markup of the page, which comes in at a hefty 26,708 bytes. And that for a page which has one input field and some links... Me as a front end developer, I'm baffled by that size and kinda insulted. I have to wait longer because they used front page or what ever, no way, not in 2009 I don't.

The real fun comes when you do a certain magic trick called view source. Most of the size of the HTML is being formed by inline css and javascript. There even is a table in there, along with inline script handlers...

1999 called and it want's it's markup back, guys.

The numbers

Still I get back to the size of the page, a whopping 26,708 bytes with all the bells and whistles. If you strip the javascript alone, you're still left with just 13,462 bytes.

Thats 13,246 bytes of inline javascript for you.

So no javascript solves the size and the waiting time? Not quite, we have inline css too. So if we get rid of that, we are left with 5,524 bytes.

So the css alone is 7,722 bytes.

It seems that were getting there, no. No way, the html is very much too much and can be optimised to I think half of it's current size.

That size being 5,524 bytes for HTML alone.

If they got the correct markup and got their CSS and JavaScript from external sources, the user would only had to download that once. And would get a better experience, because faster is better.

Conclusion

I think that the front end of this page was build by a .net developer, who thinks everybody got a broad band connection. Maybe that is the case, but I know that my patience is less now than it was when I had a 14k4 modem. If I have to wait, even for a few seconds, it's not my fault and the chance that I navigate away from that page would be greater now than it was back in the 14k4 days.

So Microsoft, please clean up your act and hire a decent front end developer. Maybe you could look at this awesome presentation from Nicole Sullivan at yahoo. It shows you how much speed matters.

This is one to see.

A great interview with jeffrey zeldman about web standards. He talks about his view on them and how the adoption came around. A nice piece is around the 6th minute, where he explains why he started doing standards. Turns out he had the same reason I did, he just didn't want to build 4 versions of each page but wanted to focus on the content and the design.

So In other words, if you use web standards you get to go to the pub earlier :.

As we did in 2007, A List Apart and you teamed up to shed light on precisely who creates websites. Where do we live? What kind of work do we do? What are our job titles? How well or how poorly are we paid? How satisfied are we, and where do we see ourselves going?

Great survey, with the results marked up in an extra ordinary manner by Eric Meyer. The data is presented in a series of tables as plain data and than styled masterfully with css.

<tr>
	<th scope="row">Definitely not</th>
	<td>
		<div>
			<p style="width: 27%;">
				<span>27.0%</span>
			</p>
		</div>
	</td>
</tr>

This very simple table looks like this, after some css.

So if you want to see who makes websites and learn a thing or two about proper markup and styling, go and see for your self.