

Working with HTML5 & CSS3 - destraynor
http://stuff.contrast.ie/talks/newwebtech2010/

======
bradhe
I decided to dive in to HTML5 and CSS3 in my last project and I'm really happy
I did so. So much so, in fact, that I won't look back -- at least, not for my
own projects.

Previously anything that came out of W3C was more akin to something a company
that didn't listen to its customers would produce but it seems like they broke
that habit with HTML5. There are some technical details that are still up in
the air (i.e. video codec -- but I'm not really sure what the status of that
is) but one certainly good quality of HTML5 is that you have to be almost
stupid to write non-validating markup.

Also, there are a lot of little things that they implemented that are really
valuable to rich apps. For instance, custom data attributes -- which I wrote
about a few months ago (herp derp, self promotion:
[http://bradhe.wordpress.com/2010/08/31/custom-data-
attribute...](http://bradhe.wordpress.com/2010/08/31/custom-data-attributes-
are-your-frien/)) -- finally fixes the coupling (or decoupling, actually)
issue that has been present in HTML + JS apps until now!

------
megaman821
There is a bit of bad advice in here. You would want to do

    
    
        <ul>
        <li>something</li
        ><li>something else</li
        ><li>yet another thing</li>
        </ul>
    

This allows you to use _display: inline-block_. If you put each _li_ on a
separate line there will be a single space between the elements.

~~~
davebarrett
Yes, it does. However, there are other, nicer ways of doing this. For example,
you could use a comment that is broken over the line. Using tags like that is
asking for trouble in editing, particularly if your code is shared.

But this advice was intended more generally. If you look at the code, and
indeed the full source in the spec[1], you'll see that this is a coding style
used for all elements; even elements that will never be rendered. It is ugly
as hell, easy to break, and difficult for many people to parse.

That's why I recommended avoiding it.

1: [http://www.whatwg.org/specs/web-apps/current-work/#the-
secti...](http://www.whatwg.org/specs/web-apps/current-work/#the-section-
element)

------
lhnn
Interesting article.

I wish he hadn't dropped "Why the $f not?" line. I'm not offended, but it
comes off as unprofessional in otherwise well written content.

