This talk, first given at Sheffield university UK on March 31st 2011, discusses HTML5 and CSS3 in detail. Starting with the history of HTML and CSS, it goes on to show how HTML5 and CSS3 were developed, why they were necessary, the problems they aim to solve, what the main new features are and why they are so useful, and how we can start using these features in the real world, right now.

1. HTML5 and CSS3
Evolution & Adoption
Chris Mills, Opera Software

2. Who the hell am I?
‣ Opera open standards evangelist and tech writer
‣ Telling the world about open standards & Opera
‣ Improving web education
‣ Drumming in a heavy metal band

3. Today I'll cover
‣ How HTML5 and CSS3 evolved
‣ Why they are good for web developers (and
users!)
‣ New features in action
‣ When (and how) you can start using them

4. Where did they evolve from?
http://www.flickr.com/photos/dyanna/3202542828/

5. Brief history: inception
‣ HTML first proposed around 1990/1 by Tim
Berners-Lee
‣ CSS invented by Håkon Wium Lie and Bert Bos
around 1994/5

6. Brief history:
standardisation
‣ HTML3 first standardised around 1995
‣ CSS1 rec published in 1996, CSS2 rec published
in 1998

7. Brief history: ironing things
out
‣ CSS 2.1 mostly written by about 1999, to remove
errors and inconsistencies (although this is still
not *completely* finished)
‣ HTML 4.01 finished by 2001

8. Finished! What next?

9. There’s nothing wrong with
HTML4 and CSS2...
http://www.flickr.com/photos/birdfarm/519230710/

10. But things don't stand still!
‣ People started to use HTML and CSS for things
they weren't originally intended for:
‣ Applications
‣ Multi-column layouts
‣ Animations and interaction
‣ Browsers began to implement new features
‣ New browsing devices appeared

11. This lead to...
‣ Inefficiency
‣ Inaccessibility
‣ Inconsistency
‣ Incompatibility

12. CSS3
‣ CSS3 work started around the same time as
CSS2.1
‣ Earliest CSS3 drafts published in June 1999
‣ As of March 2011, there are over 40 CSS3
module drafts published
‣ Some a lot more stable than others

13. CSS3 designed to
‣ Build on top of existing CSS1/2 features
‣ Add more efficient, powerful solutions for
common design problems
‣ Degrade gracefully where possible

14. HTML5
‣ W3C decided the future was XHTML
‣ This didn’t go down well, and no-one gave a rat’s
ass about XHTML2
‣ HTML5 (was web applications 1.0) started by
WHATWG in 2004ish
‣ Adopted by W3C 2008
‣ WHATWG version became versionless in 2011

15. HTML5 designed to...
‣ Be backwards compatible
‣ Add more efficient, powerful features to the
language (markup and APIs)
‣ Compete with plugin technologies
‣ Be more in keeping with what web developers
are really doing

16. HTML5 and CSS3 have
more bling!
As if! Not publishing this one...

17. Why are HTML5 and CSS3
so good for us?
http://www.flickr.com/photos/mafleen/3780072133/

18. We've done most of
this stuff before...
http://www.flickr.com/photos/monkeytime/4120229885/

19. ... so why should we care?
http://www.flickr.com/photos/philliecasablanca/2816530573/

20. Many reasons!
‣ Less inconsistent, unsemantic, presentational
markup
‣ Less time spent with JavaScript
‣ Less time spent dicking about with Flash
‣ Better accessibility built in
‣ Less time spent in Photoshop
‣ More time spent in the pub

21. New markup: better
semantics
http://www.flickr.com/photos/zscheyge/49012397/

22. Typical website structure
<div id="header"></div>
<div id="nav"></div>
<div id="main">
<div class="article"></div>
<div class="article"></div>
...
</div>
<div id="footer"></div>

23. Most common classes and
IDs?
Ian Hickson did a study at Google of the most
common classes/IDs on the Web. So did Opera
‣ http://code.google.com/webstats/2005-12/
classes.html
‣ http://devfiles.myopera.com/articles/572/idlist-
url.htm
‣ http://devfiles.myopera.com/articles/572/
classlist-url.htm

24. Most common IDs

25. Most common classes

26. The HTML5 shizzle
<header></header>
<nav></nav>
<section id="main">
<article></article>
<article></article>
...
</section>
<footer></footer>

27. <aside>
<aside>
<h2>About the author</h2>
<p>Chris Mills is a front‐end bling junkie
working for Opera Software...</p>
</aside>

28. <time>
<p>Article published on the
<time datetime="2011‐03‐12T09:48" pubdate>
12th March 2011, at 9:48am
</time>
</p>

29. <hgroup>
<hgroup>
<h1>Top level heading</h1>
<h2>This is a really descriptive subtitle</h2>
</hgroup>

30. <figure> and <figcaption>
<figure>
<img src="bear.jpg"
alt="this is the bear that I wrestled" />
<figcaption>This is the bear that I
wrestled.</figcaption>
</figure>

31. Where does this leave the
humble <div>?
Use it for anything that isn’t covered by other new
elements, and is just a general grouping, e.g. for
styling purposes, for which you don’t want to
create a new section. An intro <div>, perhaps?

32. The HTML5 outlining
algorithm
Heading/section hierarchy based on sectioning
element hierarchy, not <hx> elements used
‣ No longer limited to six heading levels
‣ Hierarchy stays correct when syndicated
‣ You can retain HTML4 heading levels for
backwards compatibility

33. The HTML5 outlining
algorithm
<h1>My title</h1>
<div>
<h2>My subtitle</h2>
</div>
<h1>My title</h1>
<section>
<h2>My subtitle</h2>
</section>

34. Lax syntax?
Some say that HTML5 syntax is really lax — you:
‣ don’t need to quote or self-close attributes
‣ can minimize attributes
‣ Have a really small doctype: <!doctype html>
‣ can mix upper and lower case
‣ You don’t even need to include <html>, <head>
and <body>!

35. Lax syntax?
This more accurately reflects what real developers
do, rather than what the XHTML spec THINKS they
should
‣ You can use the style you want (although you
should stick to some best practices)
‣ The browser fills in a lot of this stuff
‣ The HTML5 spec defines how errors should be
handled

36. Less Flash, more control:
<video>, web fonts and
more!
http://www.flickr.com/photos/zscheyge/49012397/

37. <video> and <audio>
New elements, plus new API for controlling audio
and video

38. The old school way
<object width="425" height="344">
<param name="movie" value="http://www.example.com/
v/LtfQg4KkR88&hl=en&fs=1"></param>
<param name="allowFullScreen" value="true"></param>
<embed src="http://www.example.com/v/
LtfQg4KkR88&hl=en&fs=1"
type="application/x‐shockwave‐flash"
allowfullscreen="true" width="425"
height="344"></embed>
</object>

39. The badass sexy new way
<video width="480px"
height="283px"
controls
poster="poster.png">
<source src="video.mp4" type="video/mp4">
<source src="video.webm" type="video/webm">
<p>Your browser doesn’t support HTML5 video. <a
href="video.webm">Download the video instead</a>.</
p>
</video>

40. Native video rocks!
‣ Plays nicely with other open standards
‣ Better accessibility features
‣ Don't need to use Flash
‣ API for easy customization

41. Web fonts
‣ Download custom fonts along with your web
pages
‣ Solve our typography nightmares, without having
to worry about hackish solutions like siFR and
Cufon

42. Include the font
@font‐face {
font‐family: 'ActionIsRegular';
src: url('actionis‐webfont.eot?') format('eot'),
url('actionis‐webfont.woff') format('woff'),
url('actionis‐webfont.ttf')
format('truetype'),
url('actionis‐webfont.svg#webfontg3JxrxOm')
format('svg');
font‐weight: normal;
font‐style: normal;
}

43. Then use it in your page as
normal
p {
font‐family: “My font”;
}

44. Going offline
http://www.flickr.com/photos/zscheyge/49012397/

45. Offline apps!
‣ Generally, the web doesn't work very well
without a web connection!
‣ What can we do about this?

46. Offline applications
‣ AppCache: Save an offline version of your web
page files and use those to display your web
page when you lose network.
‣ Web storage: Like cookies, but more powerful.
Store things such as form data and user
preferences
‣ WebSQL: A fully-functioning database in your
browser. Store a user's data so they can
continue working with it when the network goes
down

47. Offline applications
‣ For more information, check out http://
dev.opera.com/articles/view/taking-your-web-
apps-offline-web-storage-appcache-websql/

48. Scriptable graphics with
<canvas>

49. <canvas>
Scriptable graphics
‣ Standard API for drawing
‣ Supporting across all modern browsers

50. The basic idea
<canvas id="canvas" width="400" height="300">
...fallback...
</canvas>

51. <canvas> examples
‣ http://dev.opera.com/articles/view/html-5-
canvas-the-basics/
‣ http://ejohn.org/blog/processingjs/
‣ http://www.hakim.se/experiments/
‣ http://www.canvasdemos.com/
‣ http://people.opera.com/patrickl/experiments/
canvas/particle/3/

52. Cutting down on Photoshop

53. We need less Photoshop!
Doing things programmatically is so much more
flexible.
Classic examples:
‣ Drop shadows
‣ Gradients
‣ Rounded corners
‣ Transparency

54. Examples
div {
text‐shadow: black 3px 3px 5px;
box‐shadow: black 4px 4px 5px;
background‐image: ‐o‐linear‐gradient(top
left,rgba(0,0,0,0),rgba(0,0,0,0.6));
background‐color: rgb(204,204,204);
border‐radius: 10px;
// opacity: 0.6;
}

55. Less JavaScript needed
with HTML5 forms
http://www.flickr.com/photos/zscheyge/49012397/

56. HTML5 forms
Filling up the gaps in HTML4 (and so cutting down
on JS and hacks) with:
‣ More powerful form controls
‣ Built-in validation
Not relying on JS can mean smaller downloads,
and better compatibility

57. Date-time controls
<input type=date>
<input type=datetime>
<input type=week>
<input type=month>

58. color
<input type=color>

59. Datalist
<input type=text list=mydata>
<datalist id=mydata>
<option label=Mr value=Mister>
<option label=Mrs value=Mistress>
<option label=Ms value=Miss>
</datalist>

60. Other new input types
<input type=email>
<input type=url>
<input type=tel>

61. Validation
Form validation used to be horrendous

62. var elements = document.getElementsByTagName('input');
// loop through all input elements in form
for(var i = 0; i < elements.length; i++) {
Who wants to write this?
// check if element is mandatory; ie has a pattern
var pattern = elements.item(i).getAttribute('pattern');
if (pattern != null) {
var value = elements.item(i).value;
// validate the value of this element, using its defined pattern
var offendingChar = value.match(pattern);
// if an invalid character is found or the element was left empty
if(offendingChar != null || value.length == 0) {
// add up all error messages
str += elements.item(i).getAttribute('errorMsg') + "n" +
"Found this illegal value: '" + offendingChar + "' n";
// notify user by changing background color, in this case to red
elements.item(i).style.background = "red";
}
}
}
if (str != "") {
// do not submit the form
alert("ERROR ALERT!!n" +str);
return false;

63. HTML5 gives you...
<input type=text required
pattern="[A‐z]{1,20} [A‐z]{1,20}">

64. Other new attributes
autofocus
placeholder
min
max
step

65. New output mechanisms
<output>
<progress>
<meter>

66. CSS form pseudo-classes
input:valid { ... }
input:invalid { ... }
input:checked { ... }

67. Controlling behaviour with
CSS...

68. ...again, means less
JavaScript
Designers don't like scripting!
Obvious behavioural stuff:
‣ Animation
‣ Showing/hiding

69. Animation
‣ CSS keyframe animations allow you to create
animations that run independently
‣ Transitions allow animation that is dependant
on state changes

70. Showing/hiding
‣ :target pseudo-class: apply CSS depending on
whether the element selected is the target of a
fragment identifier
‣ So when links are clicked you could make
panels, etc. appear.

71. Controlling layouts

72. Controlling layouts
‣ Media queries allow you to apply CSS
depending on browser/device attributes such
as resolution, screen width and height, etc.
‣ Viewport allows you to customise the initial
display of your pages on mobile devices
‣ Multi-column layout allows you to easily put
your content into columns

73. Media queries
Media types on steroids
‣ Apply CSS depending on value of certain media
features
‣ (http://people.opera.com/danield/css3/vangogh/
index.php)
‣ http://mediaqueri.es

74. Media features
width color
height color-index
device-width monochrome
device-height resolution
orientation scan
aspect-ratio grid
device-aspect-ratio

75. mediaqueri.es

76. mediaqueri.es

77. Viewport
‣ Meta tag introduced by Apple to control display
of web apps on the iPhone
‣ Adopted by other vendors too
‣ Control initial zoom level, maximum zoom, width
or displayed area, etc.
‣ Functionality available as CSS @-rule too
‣ http://dev.opera.com/articles/view/an-
introduction-to-meta-viewport-and-viewport/

78. Viewport: the premise
‣ It's all about physical versus virtual pixels
‣ Desktop computers are fairly simple
‣ But mobiles lie
‣ Viewport suggests sizing to mobiles

79. Viewport example
<meta name="viewport"
content="width=480">
<meta name="viewport"
content="width=480, user‐scalable=no">

80. Viewport properties
width initial-scale
height minimum-scale
user-scalable maximum-scale

83. CSS viewport
@viewport {
width: device‐width;
}
@viewport {
width: 320px;
zoom: 2.3;
user‐zoom: fixed;
}

84. CSS viewport properties
width/min-width/
user-zoom
max-width
height/min-height/
orientation
max-height
zoom/min-zoom/
max-zoom

85. CSS multi-col
div {
column‐width: 100px;
column‐count: 4;
column‐gap: 20px;
column‐rule: 2px solid #33c;
}
section {
break‐after: column;
}

86. Less presentational markup

87. Less presentational markup
‣ CSS3 includes a wide variety of new selectors
to allow you to select what you want more
easily, with less classes/ids
‣ Features like multiple background images and
rounded corners allow you to get rid of some of
those nested divisions!

88. CSS3 selectors
[attr*=str] :nth‐last‐of‐type(n)
[attr^=str] :nth‐last‐child(n)
[attr~=str] :only‐child
:first‐child :only‐of‐type
:last‐child :checked
:first‐of‐type :valid
:last‐of‐type :invalid
:nth‐child(n) :enabled :target
:nth‐of‐type(n) :disabled And more!

89. Multiple backgrounds
header {
background: url(icon.gif) top left no‐repeat,
url(pattern.jpg) repeat,
url(center‐spine.png) top center
repeat‐y;
}

90. When (and how) can we
start using these tools?
http://www.flickr.com/photos/bre/552152780/

91. We've already looked at the
spec development history
‣ But what really matters?

92. Browser adoption
‣ The specs don't matter if the browsers don't
follow them consistently
‣ We don't have a browser war anymore like the
days of old
‣ But there is still lots of competition

93. Developer adoption
‣ Browser adoption doesn't matter if developers
don't care...
‣ ...although more often this isn't exactly the case
‣ Often we are not in the position to use new
features

94. Stuck between a rock and a
hard place
‣ Older browsers don't support this stuff
‣ Some of us are forced to support them
‣ Many clients are still obsessed with "pixel perfect
layouts" across all browsers

95. However...
‣ ...most browsers support most of this stuff now,
even IE9!
‣ (well, the semantic elements need a little help,
but not much)
‣ Most of it degrades gracefully
‣ And you can work around problems
‣ Depends on what your client needs
‣ By "identical", how similar do you mean??

96. Try to argue the case...
..."identical in every browser" is outdated
‣ Especially with mobile phones, iPad, tablets...
‣ And IE6 is a decade old now
‣ Flash doesn't even work on iDevices!
‣ Surely providing an acceptable experience in
each browser is, well, acceptable?
‣ Then you can spend more less time on hacking

97. Selectivizr

98. CSS3 pie

99. Modernizr

100. I say use them now, as
much as possible!
http://www.flickr.com/photos/ilamont/5538511847/

101. Thanks for listening!
‣ cmills@opera.com
‣ @chrisdavidmills
‣ http://dev.opera.com
‣ http://www.opera.com/wsc