We currently have no means to provide information about what’s happening or being said in the video, which means the video isn’t very accessible and the user can’t easily navigate to a particular section of the video. Thankfully, there’s a new format specification in the works called WebVTT (Web Video Text Tracks). As of now, it’s only in the WHATWG spec, but the recently established W3C Web Media Text Tracks Community Group should introduce a WebVTT spec to the W3C soon.

You may recall a similar format called WebSRT (Web Subtitle Resource Tracks) that was recently under discussion. WebSRT was renamed to, and has been replaced by, WebVTT.

A WebVTT (.vtt) file is simply plain text containing several types of information about the video:

Subtitles

The transcription or translation of the dialogue.

Captions

Similar to subtitles, but may also include sound effects and other audio information.

Descriptions

Intended to be a separate text file that describes the video through a screenreader.

Chapters

Intended to help the user navigate through the video.

Metadata

Information and content about the video, which isn’t intended to be displayed to the viewer by default, though you may wish to do so using JavaScript.

This article will mostly be talking about subtitles and captions, but it will briefly touch on chapters too.

Beyond the scope of this article but worth mentioning is the text track API, which, amongst other things, denotes how many text tracks there are and which ones have loaded and are ready for use. If you have used this API, let us know.

WEBVTT

<video width="640" height="480" controls>
  <source src="video.mp4" type="video/mp4" />
  <source src="video.webm" type="video/webm" />
  <track src="subtitles.vtt" kind="subtitles" srclang="en" label="English" />
  <!-- fallback for rubbish browsers -->
</video>

WEBVTT

1
00:00:01.000 --> 00:00:10.000
This is the first line of text, displaying from 1-10 seconds

2
00:00:15.000 --> 00:00:20.000
And the second line of text
separated over two lines

1
00:00:01.000 --> 00:00:10.000
Never gonna give you up <00:00:01.000> Never gonna let you down <00:00:05.000> Never gonna run around and desert you

Styling Options #

The previous examples specify the minimum configuration you need for subtitling and captioning, but you can style your captions too. Let’s start with the cue settings, which are done on the same line as the time settings:

D:vertical / D:vertical-lr

Display the text vertically rather than horizontally. This also specifies whether the text grows to the left (vertical) or to the right (vertical-lr).

L:X / L:X%

Either a number or a percentage. If a percentage, then it is the position from the top of the frame. If a number, this represents what line number it will be.

T:X%

The position of the text horizontally on the video. T:100% would place the text on the right side of the video.

A:start / A:middle / A:end

The alignment of the text within its box – start is left-aligned, middle is centre-aligned, and end is right-aligned.

S:X%

The width of the text box as a percentage of the video width.

To make use of these settings, put them alongside the time settings, like this:

00:00:01.000 --> 00:00:10.000 A:middle T:50%
00:00:01.000 --> 00:00:10.000 A:end D:vertical
00:00:01.000 --> 00:00:10.000 A:start T:100% L:0%

which would result in something like the following:

Along with the above cue settings, you can use inline styles for text:

Bold text

<b>Lorem ipsum</b>

Italic text

<i>dolor sit amet</i>

Underlined text

<u>consectetuer adipiscing</u>

Ruby text

<ruby>見<rt>み</rt></ruby>

You can even apply a CSS class to a section of text using <c.myClass>Lorem ipsum</c>, giving us many more styling options.

Finally, you can add a declaration representing the name of the voice: <v Tom>Hello world</v>. This declaration accomplishes three things:

1. The caption will display the voice (Tom) in addition to the caption text.
2. The name of the voice can be read by a screenreader, possibly event using a different voice for male or female names.
3. It offers a hook for styling so that, for example, all captions for Tom could be in blue.

Chapters

You can provide a chapter list for the video the same way you would provide subtitles or captions. Start with the same WEBVTT declaration, and then for each cue, declare the chapter number, the start and stop times, and the chapter title:

<track src="chapters.vtt" kind="chapters" srclang="en" />

WEBVTT

Chapter 1
00:00:01.000 --> 00:00:10.000>
Introduction to HTML5

Video Subtitling and WebVTT originally appeared on HTML5 Doctor on November 29, 2011.

We’ve come a long way in the HTML5 specification’s steady march towards ratification and implementation. The WHATWG’s energy has recently been more on post-HTML5 features that are being added to “HTML The Living Standard”, plus tidying up HTML5 for Last Call. However we’re still not past losing (or gaining) an element, with last week seeing the removal of <time> and the addition of <data>.

<time> was originally added to allow dates and times to be machine readable, via the datetime attribute. This gives us human-readable content (“yesterday”) plus hidden machine-readable content (“2011-11-02”) with no accessibility problems. It allows for e.g. browsers to offer to localise dates. The pubdate attribute indicating an article’s date of publication was added for HTML to Atom conversion (also removed from HTML5 in this change), and would make it easy for search engines to sort by date. Having permitted dates and times specified in HTML5 (a subset of ISO 8601) allows a validator to check a datetime value is valid.

<time> has been one of the easier elements to understand for authors, as it’s semantically obvious. By comparison the microformats Class-Value pattern for datetimes is clunky.

HTML5 <time> element:

<time class="dtstart" datetime="2011-10-05T09:00Z">9am on October 5</time>

Microformats Value-Class pattern:

<span class="dtstart"><abbr class="value" title="09:00">9am</abbr> on <abbr class="value" title="2011-10-05">October 5</abbr></span>

<time> has been pretty widely used for weblog article publication dates, and has made it into WordPress and Drupal plus being used by Google for search results.

The issues raised about <time> by authors were mainly that it didn’t do everything: it didn’t cover ancient and vague times, time durations, and there was no “last updated” attribute equivalent to pubdate. The other problem is there are a bunch of other less common but similar kinds of data that would also benefit from being machine readable and validatable, such as weights and prices. Minting a new element for each one would (arguably) be a lot of work, so Ian Hickson has added a generic element for these use cases instead — the <data> element, with a required value attribute.

The data element represents its contents, along with a machine-readable form of those contents in the value attribute.

The value attribute contains the machine-readable equivalent of the element’s content. The <data> element can be used as-is as an element equivalent of data-* for marking up private data for scripts (although without the dataset API). It can also be used in conjunction with microdata vocabularies (and potentially microformats), in which case the format of the value attribute is specified by the vocabulary.

This is a welcome addition as it gives us an easy way to duplicate microformats’ Value-Class pattern for more than just the datetimes <time> allowed. However as part of introducing <data>, <time> together with datetime and pubdate have been dropped.

This is controversial, with our own Dr Bruce writing:

I think this is a bad decision

Steve Faulkner has requested this change be reverted, and comments on the Twitters and blogs (Bruce, WebMonkey, Zeldman) have been mostly ranging from shock to outrage.

This is because while <time> is semantically obvious, <data> is seen as an equivalent to <div> or <span>. However, “semantics for the sake of it” isn’t enough to justify being in the spec, despite the benefits. Another reason for the dismay is many people have had trouble pushing to use HTML5, and having an element removed gives fuel to anyone arguing HTML5 isn’t suitable for production.

<article>
 …
 <footer>Published <time pubdate datetime="2011-11-03">today</time>.</footer>
</article>

<article itemscope itemtype="http://schema.org/BlogPosting">
 …
 <footer>Published <data itemprop="datePublished" value="2011-11-03">today</data>.</footer>
</article>

Goodbye time, datetime, and pubdate. Hello data and value. originally appeared on HTML5 Doctor on November 2, 2011.

With Dan’s blessing, we’re running an occasional series of HTML5 Simplequizzes.

HTML5 offers a way to associate a figure (which can be an image, a video, a graph, a table, a pull-quote) with a caption using the <figure> element. This is very common in print, but there has been no way to do this in HTML4, as there is no element that groups a figure and a caption (other than a semantically-empty <div>).

Our question this week is about alternate text for images that are captioned. I’ve gotten this wrong before (in print, embarrassingly), as have two highly-clueful friends of mine. The man who set us right will be your moderator and quizmaster this week, Steve Faulkner of The Paciello Group, possibly the most respected accessibility agency out there.

We have an image as a figure in a story simply about a dignitary opening a new branch of Mr Lidl’s marvelous emporium. The caption will be “Mayor of Casterbridge opens a new Lidl supermarket”.

What’s the best markup for this? Show your working out.

A:

 <figure>
 <img src=blah.png
  alt="A portly gent cuts a ribbon. He is with five small children, and is watched by two middle-aged woman, a very tall smiling man, and a small crowd">
  <figcaption>
  Mayor of Casterbridge opens a new Lidl supermarket.
  </figcaption>
 </figure>

B:

<figure role=img aria-labelledby=lidl>
<img src=blah.png alt="">
 <figcaption id=lidl>
  Mayor of Casterbridge opens a new Lidl supermarket.
 </figcaption>
</figure>

C:

<figure>
<img src=blah.png>
 <figcaption>
 Mayor of Casterbridge opens a new Lidl supermarket.
 </figcaption>
</figure>

D:

<figure>
<img src=blah.png alt="">
 <figcaption>
 <p>Mayor of Casterbridge opens a new Lidl supermarket.</p>
 </figcaption>
</figure>

E:

<figure>
<img src=blah.png alt="Mayor of Casterbridge opens a new Lidl supermarket.">
 <figcaption>
  Mayor of Casterbridge opens a new Lidl supermarket.
</figcaption>
</figure>

Steve will wrap up the quiz next Thursday.

HTML5 Simplequiz #4: figures, captions and alt text originally appeared on HTML5 Doctor on November 5, 2010.

<track> is a child of a <video> or <audio> element that links to a timed track, or time-based data. The kind of data is set via a kind attribute, which can take values of subtitles, captions, descriptions, chapters or metadata, depending on the type of information you’re adding to your media. These point to a source file containing timed text that the browser will expose via some kind of user interface, if the visitor requires additional data.

This will allow for “write once, use everywhere” accessibility; anyone linking to that file with a <video> or <audio> element that includes the element can access your information.

<track kind=captions src=blah.srt>

The file format is a new format called WebSRT, which competes with about 50 other timed formats, including some W3C formats (hence the omission of <track> from the W3C spec).

Added 9 July 2010: Here’s a readable overview of the SRT format.

Given that the format itself isn’t fully specified yet, it will be a while until we see implementation in browsers. But it’s good to know that there will be an official way to add accessibility information to media. Until then, I have a JavaScript hack to take timed <span>s out of an in-page transcript to superimpose over a video.

WebM video format

The big news of the last month is that Google open-sourced the VP8 video codec that it acquired when it took over On2 Technologies. When combined with the Vorbis audio codec (that Spotify uses) and wrapped in a subset of the Matroska container format, it’s collectively known as WebM.

All YouTube videos are being transcoded to WebM, and Adobe have also announced they will include it in their Flash player. It’s available in an Opera 10.60 beta, a Firefox testing build, and a Chromium dev channel. Even Microsoft have said that IE9 will support it if the codec is installed on the computer.

The VP8 video codec itself is high-quality (Google had said that Ogg Theora wasn’t good enough compression-to-quality for YouTube, but Theora was based on the VP3 precursor to VP8). It’s available for streaming too.

If you want to encode to WebM, you can try the Miro Video Converter utility. Although it doesn’t allow you to optimise settings, it’s very easy to use. As the codec becomes more widespread, expect to see many more tools for content creation, editing, and transcoding.

Once production versions of the browsers are available, you should encode your videos with WebM as the first option, Ogg for older versions of Opera, Firefox and Chrome, falling back to royalty-encumbered H.264 for Safari and links to downloads or a Flash player for legacy browsers:

<video controls>
<source src=video.webm type='video/webm; codecs="vorbis,vp8"'>
<source src=video.mp4 type='video/mp4; codecs="avc1.42E01E, mp4a.40.2"'>
<source src=video.ogv type='video/ogg; codecs="theora, vorbis"'>
<!-- embed Flash here -->
<p>Your browser does not support video; download the <a href="video.webm">WebM</a>, <a href="video.mp4">mp4</a> or <a href="video.ogg">Ogg</a> video for off-line viewing.</p>
</video>

If, however, you’re having problems with the iPad, put the MP4 version first in the <source> element; apparently there’s a bug that causes the iPad only to see the first <source> element.

It’s a long haul, and it’s not over yet, but <track> and .webM show significant progress towards our goal of accessible, open, and royalty-free video playing natively in the browser.

Video: the track element and webM codec originally appeared on HTML5 Doctor on June 24, 2010.

They aren’t a “standard” per se, but they are a widely adopted convention within the geek community. And since they use an agreed-upon set of class names, they are as compatible with HTML5 as they are with HTML4 or XHTML.

HTML5 offers one potential addition to the microformats arsenal. Because earlier versions of some microformats presented accessibility problems in the way they encoded dates and times (see an article called hAccessibility that I co-wrote with James Craig), HTML5 offers a new element for unambiguously encoding dates and times for machines while still displaying them in a human-readable way.

The time element represents either a time on a 24 hour clock, or a precise date in the proleptic Gregorian calendar, optionally with a time and a time-zone offset.

The format is very simple:

<time>2009-11-13</time>
 <!-- without @datetime content must be a valid date, time, or precise datetime -->
<time datetime="2009-11-13">13<sup>th</sup> November</time>
 <!-- when using @datetime the content can be anything relevant -->
<time datetime="20:00">starting at 8pm</time>
 <!-- time example -->
<time datetime="2009-11-13T20:00+00:00">8pm on my birthday</time>
 <!-- datetime with time-zone example -->
<time datetime="2009-11-13T20:00Z">8pm on my birthday</time>
 <!-- datetime with time-zone “Z” -->

When using the datetime attribute you can have whatever you want between the tags.

Note that the last two examples show the use of a timezone offset, which is required for a date + time. Timezones range from -12:00 to +14:00. You can use “Z” to represent Universal Coordinated Time (UTC), which is the same as +00:00.

The fly in the ointment

The only trouble with <time> is that it must contain a positive date on the Proleptic Gregorian calendar, meaning you can’t encode a date before the Christian Era. Neither can you encode imprecise dates such as “July 1904″. Microformats, however, aren’t subjected to this restriction and are often employed to mark up, for example, very old events on Wikipedia or imprecise dates on museum websites. It’s likely that authors will continue using the current, more flexible microformat patterns unless the restrictions on the <time> element are lifted. (The HTML5 working group has been continually petitioned to remove their arbitrary restrictions and widen the scope of time, but with no success).

Unfortunately current microformat clients can’t consume microformats such as hCalendar if they’re coded to use <time>. Stefan Schipor wrote to us saying:

The problem is that I need to parse the site with H2VX or any other similar thing for exporting. Sadly, H2VX doesn’t seem to read the datetime attribute in the <time> elements. Nor does the FF add-on Tails. I tried the microformats IRC channel and the microformateers twitter account but I didn’t get any response. Do you know if there is any support for this? It would kill me to add <abbr> elements just for it to work.

For more on this problem refer to Oli’s comment below, and our article Extending HTML5 — Microformats.

Incorporating the pubdate attribute

This doesn’t mean that <time> is an a waste of time, or that it’s more trouble than it’s worth (a white element, as it were). It has a great deal of scope outside microformats, too.

On my personal blog, I use it to mark up publication dates of articles. There is a boolean attribute pubdate specifically for this:

<article>
  <header>
  <h1>My brilliant blogpost</h1>
  <p>Published on <time datetime="2010-01-20" pubdate>20 January 2010</time> in the Sexysocks category.</p>
  </header>
  <p>I'm wearing sexy socks! Here's a picture.</p>
  ...
</article>

The spec says:

The pubdate attribute is a boolean attribute. If specified, it indicates that the date and time given by the element is the publication date and time of the nearest ancestor article element, or, if the element has no ancestor article element, of the document as a whole.

Note that with pubdate we must use a date or a precise datetime + timezone.

You might be wondering why the pubdate attribute is needed at all. Why not just assume that any <time> element in an <article>‘s <header> is its publication date?

Consider this example:

<article>
  <header>
  <h1>Come to my party on <time datetime="2010-03-01">1 March</time></h1>
  <p>Published on <time datetime="2010-01-20" pubdate>20 January 2010</time> in the Sexysocks category.</p>
  </header>
  <p>I'm throwing a sexy socks party at Dr Naughty's Ladyboy Cabaret Roller-disco Bierkeller Pizza-parlour-a-gogo! Do come.</p>
  ...
</article>

You’ll see that there are two dates within the <header>: the date of the actual party and the publication date of the article. The pubdate attribute is required to remove any ambiguity.

Where could time be used?

The uses of unambiguous dates in web pages aren’t hard to imagine. A browser could offer to add events to a user’s calendar. A Thai-localised browser could offer to transform Gregorian dates into Thai Buddhist era dates. A Japanese browser could localise <time>16:00</time> to “16:00時”. Content aggregators can produce visual timelines of events.

Search engines can produce smarter search results. For example, in the recent heavy snow in the UK, I searched for school closures in my town and discovered my kids’ school was closed. After receiving a phone call from the school asking me where my kids were, I re-examined the webpage. In small print at the bottom of the page were the words "Published 5 January 2008". I expect that operators of search engines would rank more current pages more highly on searches connected with current events.

Please note that since this was written, <time>, datetime have been made more powerful, and pubdate is (possibly) to be dropped. Doctor Bruce has the low-down in his blogpost The best of <time>s.

The time element (and microformats) originally appeared on HTML5 Doctor on February 9, 2010.

We also want to know what areas of HTML5 you’d like us to cover in future articles, so let us know!

Older browsers and XHTML

Brett Prichard asked:

If I were to use one of the new tags in HTML5, (i.e., <video> or <header>) what would happen when the page is rendered by an older browser?

The other question I have is will there be an XHTML equivalent? XHTML 2.0 breaks off compatibility with HTMLs 1-4, but will it be compatible with HTML5? I prefer to code in XHTML.

Thank you for reading.

To answer your first question: nothing special. The content nested within the element is displayed. (In the case of video, the fallback content is shown.)

Regarding your second question, I wrote about the XHTML serialisation of HTML5 a while ago.

— Thanks, Bruce

ARIA

Joseph Chapman asked:

My colleagues and I wish to switch our doctype to the streamlined <!doctype html> and implement several things we learnt from Jeremy Keith last Wednesday, primarily ARIA.

We know that support is good as long as we add an extra DTD, but we can’t find the appropriate doctype declaration to stick on the end of ...html> Any ideas? We are really keen to kick this off and use a new piece of technology that will help springboard our site to a new level of accessibility.

Any answers appreciated.

Thanks for your help.

It’s okay to add ARIA to HTML5 now without using a different doctype. I suggest you give this part of the spec a read.

I believe a task force has been created to more closely align ARIA to HTML5. We plan to cover ARIA more in a future post.

Hope this helps

— Rich

Attribute Minification

Nick Leon asked:

Hey there HTML5Doctor,

I consider myself a strong POSH developer. One of the requirements for valid XHTML is that “attribute minimization” is not allowed. HTML permits “attribute minimization”, where boolean attributes can have their value omitted entirely, e.g., <option selected>. All XML attributes must have explicit quoted values, so in XML this would be written as <option selected="selected">.

I was wondering where HTML5 stands with attribute minimization. I noticed in some of your example code, you provided the minimized form of the attribute, e.g., <audio src="elvis.ogg" controls autobuffer></audio>. Is this valid in HTML5? Would this be the valid version for XHTML5:

<audio src="elvis.ogg" controls="1" autobuffer="0"></audio>?

Those are both valid HTML5 structures (however, controls=”1″ isn’t legal; you need to say controls=”controls”).

In HTML5, you can format attributes as you please. In XHTML5 (the XML serialisation), you need to obey the XML rules.

— Cheers, Bruce

Offline storage

Kevin Searle asked:

I’m having a hard time wrapping my head around the offline storage capabilities of the HTML 5 spec. Can you consider an “HTML 5 Offline Storage 101″ article?

Just to clarify, do you mean “storage” or “offline”? They’re two very different things.

Storage relates to variables, like cookie jars but a lot bigger.

Offline applications are about detecting connectivity and possibly running your app without a connection to the Web.

We (i.e., Remy) will be writing about both of these topics, but it’s useful to know which is more in demand than the other.

In the meantime, feel free to check out the demos I’ve written at HTML5 Demos (covering offline, storage, and web databases).

— Remy

Nav Title (in the document outline)

D Ross asked:

Working on my new site and checked it with the outliner. I’m getting an “untitled section” showing up because I don’t have a headline inside my “nav” element.

Is this correct? Do I really need to title my main nav?

If so, is adding an <h5> or something similar with the words “main navigation” good enough? If so, is hiding it with display: none okay?

Thanks,

DRoss

Yes, “untitled section” is fine. I know it’s been suggested to the developer of the outliner that it should say “navigation” or something similar, but I’m not sure when or whether that will happen. (You’ll see the same thing with <aside> too if there’s no heading nested directly beneath the element).

Thanks,

— Rich

The details element

Bart asked:

Hello Doctors!

I’d like to ask you a little help with understanding the “details” element.

As the W3 spec says: “The details element represents a disclosure widget from which the user can obtain additional information or controls”.

I’m not sure if I get it right, but I think I can use this element to put details about a post (such as date and time) and controls, including “answer”, “save” and “repost”.

Please tell me if I’m wrong.

Regards, Bart

PS. I love the HTML5doctor blog, it’s so important to explain how to use HTML5. Keep up the great work!

This question triggered a flurry of responses from several of us doctors, so we’ve added them all here for you.

Answer 1

The spec says <details> is not appropriate for footnotes, and you could argue that post details are footnotes. Also, the <details> element has the option to show or hide its content, which suggests to me that it’s not appropriate for the post details.

You could possibly use a <section> or a <footer> for the post details, but I’m not clear on what you mean by “controls”.

For the date/time, you can use the <time> element:

<time class="published updated" datetime="2009-09-23">September 23rd, 2009</time>

Other doctors might have other opinions, but I hope this helps.

— Tom

Answer 2

Just to follow up on Tom’s reply: the user viewing your content can control whether or not they see the details.

The <details> element is an interactive element that is collapsed by default, so that only the heading is visible. The heading should be marked up in a <dt> element (if absent, it will read “Details”).

The control that the user agent should render (when fully supporting the <details> element) is a small triangular button to the left that, when clicked, toggles the visibility of the element’s contents.

If the <details> element should be open by default, it should have its open attribute set.

I would use <details> for any content that still allows the surrounding content to make sense while not necessarily needing to be seen. So in your example, I would put the metadata in the <details>, but not the “user controls” to reply, save, etc., since the user should always be able to see that they can perform these actions.

While the browser vendors haven’t implemented the interactive aspect of details, I, for one, will be emulating this using JavaScript.

I hope that helps (too!).

— Remy

Answer 3

You can also use pubdate as an attribute of <time>:

<time pubdate datetime="2009-09-23">September 23rd, 2009</time>

pubdate is useful when you have two different times in the post. For example, for a future event:

<article>
<header>
<h1>Gig: Hixie and the Pixies, <time datetime="2010-01-01">Jan 1st 2010</time>, Royal Albert Hall</h1>
<p>Published <time datetime="2009-09-21" pubdate>Sept 21, 2009</time></p>
</header>
<p>With Lachy on kazoo, Henri on Sousaphone, Pilgers on the triangle, and Hixie conducting</p>
</article>

I feel a post about the <time> element coming on…

— Bruce

More to come

That wraps up this round of questions! We’d like to know what areas of HTML5 you’d like us to cover in future articles, so leave a comment below or send us an e-mail.

Your Questions Answered #4 originally appeared on HTML5 Doctor on December 9, 2009.

Sorry.

What we’ve been doing wrong is using section to wrap content in order to style it, or to demarcate the main content area from the nav, header, footer etc. These are jobs for div, not section.

The section spec says

The section element represents a generic document or application section…The section element is not a generic container element. When an element is needed for styling purposes or as a convenience for scripting, authors are encouraged to use the div element instead.

section is a blob of content that you could store as an individual record in a database. It generally looks like this (and note that the heading goes inside the section element, not immediately before it):

<section>
<h1>Any level of heading</h1>
rest of the content
</section>

With very few exceptions, section should not be used if there is no natural heading for it. Check your work in the HTML 5 outiner tool. If you see any instances of “untitled section” that corresponds to a section, you’re probably doing it wrong. (It’s fine for a nav or aside element to be untitled, however).

Section is also the most generic of the sectioning elements. Make certain that you don’t really need an article, which is defined as

a composition that forms an independent part of a document, page, application, or site. This could be a forum post, a magazine or newspaper article, a Web log entry, a user-submitted comment, an interactive widget, or any other independent item of content

addEvent(dragItems, 'dragstart', function (event) {
  // via ARIA say the element has been grabbed
  this.setAttribute('aria-grabbed', 'true');
  // code continues...

addEvent(dragItems, 'dragend', function (event) {
  // remove the ARIA grab attibute when we're not dragging
  this.setAttribute('aria-grabbed', 'false');
});

<div class="story">
<h3><a href="story1.html">Bruce Lawson voted sexiest man on Earth</a></h3>
<p><a href="story1.html"><img src="bruce.jpg" alt="full story. " />A congress representing all the planet's women unanimously voted Bruce Lawson as sexiest man alive.</a></p>
<p><a href="story1.html">Read more</a></p>
</div>

<article>
<a href="story1.html">
<h3>Bruce Lawson voted sexiest man on Earth</h3>
<p><img src="bruce.jpg" alt="gorgeous lovebundle. ">A congress representing all the planet's women unanimously voted Bruce Lawson as sexiest man alive.</p>
<p>Read more</p>
</a>
</article>