Making an iPad HTML5 App & making it really fast

Jun 15, 2010 0 Comments
Tagged: , , , , and

thomasfuchsNow this is really good for us real web craftsman and women. Real knowledge of your field once again proves itself against frameworks. How much I loved the demos of jQtouch at last weeks @media ( or #wdx as it is called now ), I still think that using a library or a framework isn't the thing to do for speed. So Ipad and Iphone development will create a new demand for good old hand coders.

"Don’t rely on frameworks or what standards zealots tell you. In our case, a highly trimmed HTML page, with inline CSS, just some pure JavaScript without a framework and using the capabilities of the target platform (iPad) as much as possible allows for a lean page that loads almost instantly, caches well and works great offline. Yes, we could have used JavaScript and CSS frameworks, but sometimes less is more (and remember, you don’t need all the cross-browser heavy lifting that frameworks do for you)."

(Via Thomas Fuchs.)

chromium bug

May 10, 2010 2 Comments
Tagged: , , , and

images.jpegI 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...

Reasons not to like IE6

Mar 08, 2010 1 Comment
Tagged: and

Doubled Float-Margin Bug
Peekaboo Bug
IE 6 Duplicate Characters Bug
Internet Explorer and the
Expanding Box Problem
Guillotine Bug
The Float Model Problem
Three Pixel Text Jog
IE and Italics
Inherited margins on form elements
Quirky Percentages In IE6's
Visual Formatting Model
IE/Win Line-height Bug
IE6 Border Chaos
Disappearing List-Background Bug
Unscrollable Content Bug
Duplicate Indent Bug
Escaping Floats Bug
Creeping Text Bug
Missing First Letter Bug
Phantom Box Bug

input type=search

Feb 25, 2010 1 Comment
Tagged: , and

In this site I use several html5 elements and attributes. One of them is <input type="search" /> which gives me (for instance) a search button on my Iphone. It degrades to an text kinda input so it's backwards compatible.

What it also does is look kinda ugly in safari, with rounded corners and a frigging shadow and so on.

Default rendering in safari 4 os x
default rendering of search
Custom rendering
custom rendering of search

The way to render this is this one line of css:

input[type="search"]{
-webkit-appearance:textfield;
/* textfield instead of searchbox */
border: 1px solid #39c;
/* and a border of course but that's not relevant :) */
}

But for now that's it, on simple line in your css and apple no longers controls the style of your search field and you can style it (semi) consistent over browsers. A complete list of webkit specific styles can be found on Qooxdoo.org.

As I know, one disadvantage is that the search box does not longer appear as the default one in safari. But in my opinion the search box is not in usage as of now, so people are now more baffled by a strange box than they recognize the search box. In the future, however I think that this trick is no longer needed nor wanted.

@font-face not working without custum .htaccess declaration

Jan 14, 2010 0 Comments
Tagged: , , and

I recently started using @font-face in a major website. The time has come to free ourselves from the shackles of the webfonts. I got the chance to host the fonts on a amazon s3 cloudfront instance. Really fast and with the 'bullet-proof @font-face' solution of Paul Irish I decided to give it a go.

So I started testing and everything looked very promising, even the FOUT wasn't too bad. But when we got around to implementing it in the real templates for the site, my esteemed colleague Maarten found a flaw.

It seems that the .otf file that we use isn't being read properly in Firefox, but instead gives a weird error.

Failed to load source for: http://wnas.nl/fonts/FrescoStd-Normal.otf 

Safari uses the same .otf file and displays it properly. But with this CSS:

@font-face { 
font-family:'FrescoStdNormalRegular';
src: url('http://wnas.nl/fonts/FrescoStd-Normal.eot');
src: local('no local - Fresco Std Normal Regular'),local('no local-FrescoStd-Normal'),
url('http://wnas.nl/fonts/FrescoStd-Normal.woff')
format('woff'),
url('http://wnas.nl/fonts/FrescoStd-Normal.otf')
format('opentype'),
url('http://wnas.nl/fonts/FrescoStd-Normal.svg#FrescoStd-Normal')
format('svg');
}
#test{
font-family:FrescoStdNormalRegular,courier;
}

FrescoStdNormalRegular,courier;

Firefox, as you can see, just doesn't render the font, can anyone help me and point out what I am doing wrong? Please let me know in the comments...

Update

It seems that this does work on my website, but not locally... Here is a test page where I get two different responses from firefox 3.5.7 on os X 10.6.2.

  • on the Imac it says : The resource from this URL is not text: http://wnas.nl/fonts/FrescoStd-Normal.otf
  • And the macbook pro says: Failed to load source for: http://wnas.nl/fonts/FrescoStd-Normal.otf

Get the source from here and let me know what happens on your machines through the comments or twitter.

#WIN

Thanks to Jeroen who at least does some research, before asking the rest to help, we have a cause and a solution. On the mozzilla page about font-face it states:

By default, Firefox 3.5 only allows fonts to be loaded for pages served from the same site.

So you should set this in your .htaccess file and you're right as rain.

# example Apache .htaccess file to add access control header

<FilesMatch "\.(ttf|otf)$">
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin "*"
</IfModule>
</FilesMatch>

Thanks everybody for helping, I hope someone else benefits from this as well. I just learned something new, the main reason I really like my job!

another jQuery plugin

Jan 11, 2010 0 Comments
Tagged: , and

A nice and small plugin to create a semanticly step list.

Javascript

(function($) {
$.fn.extend({
steps : function() {
$(this).find('li').each( function ( i ){
$(this).prepend('<span class="step">'+(i+1)+'</span>');
})
}
});
})(jQuery);

$('ol.steps').steps();

CSS

ol.steps li { 
float: left;
padding: 5px;
}
ol.steps li span.step {
border: 1px solid red;
-webkit-border-radius: 20px;
-moz-border-radius: 10px;
line-height:18px;
width: 20px;
height:20px;
margin-right: 5px;
display:inline-block;
text-align:center;
color:#fff;
font-weight:bold;
background-color:#f00;
}

example of steps in action

Inline JavaScript

Nov 25, 2009 0 Comments
Tagged: and

As we all know, or should know, the usage of inline JavaScript is not done. For various reasons, it blocks the rendering of your page, it is bad for maintenance and so on.

There is however, one notable exception to this rule. Sometimes it can be usefull to know if you have JavaScript enabled, so you can hide certain elements that depend on a user action. For instance, you have a login button that, when clicked, shows you a box for your username and password with a login button. You don't want to hide this with CSS, so you would do that with javascript. Which you have put at the bottom of your html, just as sir Souders ordained. So at document ready the script kicks in and hides the right element. As this is not noticable on a fast site, sometimes the user can see a Flash of Unstyled Content.

So to countermand that, you can set a class on the HTML element to let the CSS know that it has to hide the correct stuff.

<script type="text/javascript">
document.documentElement.className += ' js-on';
</script>

With this in place you can write CSS to rely on the JavaScript and not have a Flash of Unstyled Content. In my opinion this is the only correct usage of Inline JavaScript.

Prototyping

Oct 19, 2009 2 Comments
Tagged: , , and

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?

HTML Photoshop

Money mark up

Oct 16, 2009 2 Comments
Tagged: , , and

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.

Invalid HTML

Oct 02, 2009 0 Comments
Tagged: , , , and

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 os x

    Safari 4 XP and Safari 4 os X

  • opera 10 os x

    Opera 10 os X

  • camino 1.6 os x

    Camino 1.6 os X

  • firefox 3.5.3 xp

    Firefox 3.5.3 XP

  • firefox 3.5.3 os x

    Firefox 3.5.3 os X

  • Internet Explorer 8 xp

    Internet Explorer 8 XP

  • Internet Explorer 7 xp

    Internet Explorer 7 XP

  • Internet Explorer 6 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.