HTML5 Doctor » video

Video: the track element and webM codec

Bruce Lawson — Thu, 24 Jun 2010 13:45:42 +0000

There are a couple of interesting developments in the world of HTML5 multimedia that you’ll be interested in. The first is the new element (currently only in the WHAT-WG spec due to political stuff).

is a child of a or 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 or element that includes the element can access your information.

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 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 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:






Your browser does not support video; download the WebM, mp4 or Ogg video for off-line viewing.

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

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

Share and Save:

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

Your Questions Answered #5

Richard Clark — Tue, 02 Mar 2010 14:30:55 +0000

We’re back with our first roundup of your questions for 2010. In this article, we’ll be covering a range of topics including sections and sectioning, the element, scaling video, and a proposal for a element.

Headers and sidebars

Ad asked:

Hello,

I have 2 questions:

1. If I have my main navigation above the masterhead would best practise be having the nav tag inside of a header tag with the h1 and h2 in a hgroup? Or should the nav and header tag be separate?

2. I am building a blog in HTML5. It has a blog-like sidebar with articles, contact info and about info in it. Would the best tag to wrap this in be section or aside?

Thank you so much for your time,
Ad Taylor

Placing your

within your

is fine and valid. However, if it makes more sense to leave it outside, then you can do that too. You don’t need to put the inside the

though.

See our articles on

and

for more on this.

Regarding your second question, I would use

(as we’ve done on the HTML5 doctor site) and then use multiple sections within that. Also see Bruce’s article on Designing a blog with HTML5.

Hope that helps.

Cheers, Rich

HTML5 element

Martijn asked:

As you are, according to the slogan, “helping [me] implement HTML5 today,” I thought to bother you people with a spec. related question.

What should an UA do with an image without specified width and height attributes?

The dimension attributes part of the specification keeps stating “if specified” for every rule but doesn’t give any “if not specified”.

The part of the specification defining the img element itself does not state anything of importance about the dimension attributes apart from how the attributes in the DOM should be created by the UA.

Interesting is to note that they have omitted these attributes in all their img element examples.

In the dimension attribute section they go state the following.

– The dimension attributes are not intended to be used to stretch the image.

So we can only use them to make images smaller? This is odd as well so let’s say by stretch they mean to say both expending and shrinking in size. In this case the attributes can only be used for two cases:

1. To state the exact width and height of the image. Something that seems redundant unless not using those attributes means the UA can display the image at any size (which it might, as nothing about this is defined in the spec.).

2. To give a 0 in both attributes. By this I am telling the UA that the image is not to be seen by the user.

Am I missing something or is the specification missing this?

Looking forward to getting your prescription

Kind Regards, Martijn

If no dimension attributes are specified, the browser will leave no space for the image, and once the image has been loaded (after the rest of the page), it will then need to reflow the entire page, as that’s the first time it knows the size of the image. This can cause the content you’re reading scrolling off the page.

If you give the size of the image as attributes in the HTML, the browser will leave space and render the image there once it’s loaded without reflowing the page. On a mobile phone, reflowing the page unnecessarily drains the battery, and users can get vertigo from the page’s text jumping around to accommodate images.

Thanks, Bruce

Section and Sectioning

Yanoo asked:

Hi,

What do you mean when you are talking about “sectioning”? And why don’t header and footer require sectioning?

I think about section and sectioning like about part of something defined. News, comment, page content, sidebar, *header*, and *footer*. Is it bad representation?

Sectioning relates to the headings in some block of related content and defining what is related to what in a hierarchy of headings (

–

). The outlining algorithm can produce a table of contents from the nested

, and

elements.

Headers and footers themselves do not change the outline; a header or footer may contain no headings. If a header or footer does contain a heading, then that heading does come into the outline. See our article on the section element.

Thanks, Bruce

Scaling the Video

Ian asked:

Hi there,

Not sure if this question is an appropriate one, but any help would be really appreciated.

I’m going about updating my video website, chutney.ie, and would love to implement HTML5. I am interested in replicating the scaling effect/style used on the Mozilla welcome page.

Not being overly knowledgeable in this area, I would love to know how to begin — is this effect a Flash based animation, or something that can be achieved with HTML alone?

Again, any nudge in the right direction would be great.

Many thanks,

Ian

I’m not sure how Mozilla did it, but you can use some of the Webkit and Mozilla transforms on the element. For example, you can cause the video to grow on hover — see this example in Chrome, Safari, or Opera. You can also use the :target pseudoclass to initiate animations. Alternatively, you can use a JavaScript onClick event to create the same effect.

You can also combine and to provide some interesting results (laying the over the ). For more on the element and what it can do, please read the Introduction to HTML5 Video on dev Opera written by Bruce Lawson and Patrick Lauke.

Cheers, Rich

We need a tag

John wrote in and proposed a field element:

Hey there. First off thanks for the site. I was excited to find it. I spent a little time on the W3C site and honestly couldn’t figure out how to submit suggestions there. So going to submit mine to you guys and maybe you can pass it on (if it is good) or point me to someone that can help. Ok to the point:

We are getting nice new tags to with HTML5 (nav, footer, etc) to help us create more semantic code. I think what we really need is a field tag — after all what are fieldsets sets of?

Everyone wraps up their labels and inputs with some element. Some of us do this with UL, some people do it with DT/DD, some with DIVs and some people out there insist that a form is tabular data.

We are all just bastardizing these elements because there is no clear semantic wrapper for field elements of a form.

I think you get the point. I’m trying to keep this email short. If you think there is anything to this argument, I have a more detailed summary (with example code) at:

http://john.mirick.me/2009/10/what-is-really-set-of-shouldnt-we-have.html

I would love to hear your thoughts on this.

Thanks!
John

While a field element would be nice — it would stop the argument over how best to mark-up forms — you have to ask yourself whether or not it actually adds any semantic or functional value to an HTML document. Yes, wrapping inputs and their labels in a field would make things easier to read and drop the need for the for attribute on the label (since the relationship can be assumed), but doing so would not be backwards compatible. In theory, we could continue to add for until there is a suitable time to drop it, but again I question the value of such a tag.

The purpose of wrapping form input/label pairs is generally to ease styling. My personal stance is that unless there are case studies showing how such an element can add more value to HTML forms, this proposal won’t make it very far.

Regards, Mike

Got a question for us?

That wraps up this round of questions. If you’ve got a query about the HTML5 spec or how to implement it, you can get in touch with us and we’ll do our best to help.

Share and Save:

Your Questions Answered #5 originally appeared on HTML5 Doctor on March 2, 2010.

YouTube and Vimeo support HTML5 Video

Richard Clark — Sat, 23 Jan 2010 16:08:28 +0000

Unless you’ve been hiding under an XHTML2 shaped rock for the past week or so, you’ll know that both YouTube and Vimeo have announced plans to support the HTML5 video element. Two blog posts published last week announced that the two major players in online video are experimenting with the HTML5 element.

Will it work cross browser?

The videos will work natively in Safari and Chrome (well, YouTube would certainly have to, wouldn’t it?). They’ll also work in IE if you have ChromeFrame installed (which we all know is cheating). If you’re using a browser that doesn’t support HTML5 video it will default back to the Flash method they currently employ.

Both YouTube and Vimeo use the H.264 codec to encode the videos — and that’s where things start to get complicated.

Since no official codec is defined in the spec because browser manufacturers have chosen to use different codecs to render HTML5 video. Opera and Mozilla use the Ogg Theora codec (more on that later), while Apple and Google use H.264. Who knows which side of the fence Microsoft will come down on, but I feel duty bound to mention that the licensors of the H.264 codec include both Microsoft and Apple.

The elephant in the room

There’s one major problem here: Ogg Theora, the open source video codec supported by both Firefox and Opera, is not supported on either site. It’s a shame these browsers aren’t supported, especially since Firefox 3.6 was released last week and announced support for full-screen video in its native video player.

Why use Ogg?

As previously stated, Ogg is an open source codec, meaning it’s free to use and implement. By contrast, support for native H.264 decoding in a browser costs approximately $5 million per year. (See summary of AVC/H.264 license terms [PDF].) It also seems that people creating H.264 content will be liable for royalties starting in 2011.

Far be it from me to get into the ins and outs of the debate over which codec to use, but it seems that open source would be the better way to go. Silivia Pfeiffer (a contractor for Mozilla) claims that serving as Ogg Theora will reach more people than serving as H264.

Google, on the other hand, which owns YouTube has said that Theora is not a good enough codec, claiming “If [youtube] were to switch to theora and maintain even a semblance of the current youtube quality it would take up most available bandwidth across the Internet”, a claim hotly (and convincingly) contested in Greg Maxwell’s YouTube / Ogg/Theora comparison.

YouTube and Vimeo seem to have discounted Ogg. I’d love to find out if there are other plans to add support for Firefox and Opera.

Where does that leave us?

Ignoring the whole video codec debate, it leaves us in some ways back where we started — dealing with proprietary software or complicated licensing to create online content rather than using technologies that will allow us to have a truly open web.

With Apple, Google, Mozilla, and Opera not likely to budge on their respective codec choices for HTML5 video, we can only hope that the developers at market-leading sites like YouTube and Vimeo can implement cross-browser interoperable video just like Kroc Camen’s Video for Everybody. Judging by the aforementioned blog posts, both sites have more plans in the pipeline, which is encouraging.

The codec battles are only beginning, and we’re waiting to see which direction one big gun will point. Last year, Google (which owns YouTube) announced that is paying $104million for a company called On2 Technologies, “a leading creator of high-quality video compression technology” and which made the original VP3 codec which is the basis for Ogg Theora.

What are their plans? To release a “better” Theora-like codec into the community? We can only speculate.

Back to today. Although not perfect, these sites’ support for the element is still a massive leap forward for HTML5. Who knows — if more large sites continue to adopt HTML5, maybe it’ll be ready in 2010 rather than 2022!

Share and Save:

YouTube and Vimeo support HTML5 Video originally appeared on HTML5 Doctor on January 23, 2010.

Why designers should care about HTML5

Cennydd Bowles — Wed, 14 Oct 2009 13:01:06 +0000

After a while on the fringes of our collective consciousness, HTML5 is finally getting the attention it deserves. The development community (as typified by the SuperFriends) has come together to debate practical elements of the spec, argue over the inclusion of controversial elements, and assess the timeframe over which we can unleash HTML5 in the wild.

However those of us more accustomed to the world of Post-Its, sketches, and .psds – the designers – haven’t been so vocal. Perhaps we’ve been distracted by the bright lights of CSS3 and those surface thrills we’ve longed for. (Rounded corners! Gradients! Transparency!) Or, alternatively, we’ve been in the thrall of @font-face and looking forward to the coming age of passable web typography.

Understandable. But it’s time designers got excited about HTML5 too.

Partly, it’s just good practice. Whatever your flavour of design – visual, web, interaction, user experience – knowing the native technology makes you better at your job. Just as composers should understand the capabilities of the orchestra’s instruments, designers need to understand the language of the web.

But there’s more to HTML5 than simply keeping our skills sharp. It could make a big difference to the way we design for the web.

Semantic elements

Information architects (and, by extension, user experience designers) should be excited by the new HTML5 elements –

and so on. While they won’t immediately revolutionise today’s web, they’re an investment for the future. Doing useful stuff with information is the central theme of IA, and therefore its practitioners should be at the forefront of the new experiences that machine-readable semantics will offer. HTML5 allows us to mark text up in a more meaningful way than a sea of

s, meaning we’ll soon see applications appearing at a sub-page level. We’ve started to scratch the surface – think about the Operator toolbar or customisable UIs à la iGoogle – but we’ll need detailed design thinking to work out how to bring the benefits of semantic richness to the end user.

APIs and other extensions

While it’s clear that some of the HTML5 APIs are far from perfect right now, when they’re refined they will offer us intriguing new opportunities and challenges.

Designers of location-based services should of course find the geolocation API invaluable. The contentEditable attribute gives us further power to make the web truly read/write without resorting to JavaScript and custom interfaces. New input types (eg type="search") can provide extra visual cues about input function, although of course this depends on the solutions chosen by the browser manufacturers.

Until now, it’s been easy to consider our domain as bounded by the viewport and the web server. But HTML5 is another step toward seamlessness: the merging of desktop, offline and online. For instance, the drag and drop API could see the line between online and desktop experience blur further. Local storage could allow for a web-like experience in areas of poor connectivity. This convergence is clearly a good thing, but we must also design how to expose those hidden seams at the user’s request. Users should stay in control of how their locations are published and what data is synchronised to their machine.

, ,

There is of course something of a reported schism between the standards world and the Flash world. Some see the advent of these new media elements (particularly ) as heralding the death of Adobe’s poster child.

I don’t think this is either likely or desirable. Neither technology is perfect. Flash is, of course, proprietary and thus subject to the whims of a third party that stands between browser and user. has known accessibility problems. But the two can live in harmony, if we play to their respective strengths. Some current Flash applications might be better suited to , particularly those based around dynamic visualisation: graphs, animations, infographics. Some applications will benefit from the powerful capabilities of Flash: games, heavily interactive widgets.

This aside, there’s clearly a user experience benefit in not having to rely on an external plugin to play rich media elements, and it will be interesting to see the uptake of the and elements. Although it will initially be down to browser makers to define the interface elements involved, we will need to figure out how to integrate them into everyday web experiences. The good news is that they can be styled in the same way as any other HTML element. If your visual aesthetic relies on slanted images with box shadows, it’s trivial to apply this to video too.

That said, we can’t ignore the elephant in the room: the thorny codec issue. I’m sure we’d all agree that the sooner it’s resolved, the better.

What can designers do?

Only the most patient and detail-oriented designer will relish the idea of reading the spec in full and arguing the finer points on the WHATWG list. That’s just not the way designers roll.

But as a community it’s important that we start talking about HTML5. If you’re new to HTML, now’s a great time to learn. The articles on this site and A preview of HTML5 give useful guidance on the differences between HTML5 and its predecessors. Above all, designers should get chatting with their developer friends: there can’t be many left who no longer have an opinion on this technology. How do they see their practices changing? What can we do today to prepare our sites for the advent of HTML5? How can we build on its strong points to make the web a better place?

We don’t yet know what we’ll accomplish with HTML5, but then it’s not often that the vocabulary of the web changes this deeply. However, one thing is clear: if we prepare now, we have a great chance to bring innovation to our users’ online lives.

This article was jointly published on Ineffable, Cennydd’s personal website.

Share and Save:

Why designers should care about HTML5 originally appeared on HTML5 Doctor on October 14, 2009.

Your questions answered #1

Richard Clark — Mon, 06 Jul 2009 10:59:36 +0000

One week on since our official launch and we’ve been overwhelmed by your response to the site. It’s great to see a large number of you wanting to get involved with the discussion relating to HTML 5 and asking about what you can and can’t do as well as the pro’s and cons of the specification.

In this post we’re going to cover a few of the questions we’ve received that don’t require a full post answer but still need to be addressed. We’ll post more answers everytime we’ve collated a bunch of questions so don’t be afraid to ask, however groundbreaking or insignificant it might be. Ok here we go for starters…

Automated Conversion?

Andy Mabbett wrote to ask:

Are there (or will there be) any automated or semi-automated tools which will take my (valid) HTML 4.01 Strict documents and convert them to HTML5?

While we don’t know about any specific conversion tools for converting to HTML 5 from HTML 4.01. There are several articles (see below) describing how you can name your classes more semantically in preparation for using HTML 5.

A final point on this is that I’m not sure that it would be wise to have a converter in order to move from HTML 4.01 to HTML 5, a machine however clever will not really be able to understand the true meaning of

for example. I’d be interested to hear other peoples thoughts on this though?

When should I start using HTML 5?

James asked us (presumably a little tongue in cheek):

Dear Doctor,

When will I know that it is time to start using HTML5 “for real”? Will there be an announcement?

yours etc,
James

Now I’d love there to be an official annoucement, in fact I might just announce it now! You can all start using HTML 5 today. There I said it, I feel so much better now. Seriously though, there is no reason for you not to start using HTML 5 now in sites you’re developing. I’m not saying that you have to use it religiously, but at you should at least start thinking about it in your development roadmaps. We can see on our sister site that there are a number of sites using HTML 5 “in the wild”. The amount of implementation varies greatly (some including

’s around their

elements for styling purposes for example) but they have begun to incorporate HTML 5 right now.

Lastly, Molly recently gave a talk at @media which touched upon this subject, she told us that

Implementation trumps specification

which I happen to firmly believe, after all CSS 2.1 isn’t a formal specification yet but almost everyone is using it. If you’re not sure where to start then I suggest taking a look at what browser implementations are currently like, which is where this Wiki from the WHATWG comes in. Hope that answers your question James.

Main Body

Darren asked:

How do I markup the main body of a page, are there tags? Can I serve a SWF Flash file using tags?

Regards Darren

There isn’t a tag (element), the most appropriate element for that would be

, however if only a single article is contained in that area you should use

As for the second part to your question, you *can’t* use a SWF file natively as the source to the tag, or FLV file for that matter. However, for the foreseeable future you’re still going to need to embed flash for video, via nesting the flash within the tag.

First you’ll use the with nested source elements to fall through the different supported codecs. Then when all else fails, particularly for IE, you’ll serve up the flash video via the and combo. This is because IE8 and lower doesn’t support the you’re going to need to fall back on something that works.

Make sure you read Tom’s article about the element, but you should also find this article on Video for Everybody useful to see how to degrade through the codecs.

And finally…

If your question hasn’t been answered in this post or we haven’t got back to you directly then it’s more than likely that we’ll be covering it soon in a more detailed post so be sure to check back or subscribe to the RSS feed for all future articles.

Share and Save:

Your questions answered #1 originally appeared on HTML5 Doctor on July 6, 2009.

The video element

Tom Leadbetter — Wed, 17 Jun 2009 23:58:46 +0000

The element is brand new in HTML 5 and allows you to, get this, play a movie in your website! The data of this element is supposed to be video but it might also have audio or images associated with it.

Of course, this will only work in a few browsers: Safari 3.1+, Firefox 3.5+, and latest builds of Opera (oh, and potentially the next release of Chrome).

The ‘old’ way

Ugh, look at this horrid code:

Yuck. And as you know, you need Flash for this. Or it is often delivered via javascript as well so it is not perfect.

The HTML 5 way

Nice, clean, minimal code:


 Try this page in Safari  4! Or you can download the  video instead.

Autoplay

The video tag has an attribute that allows the video to play when the page loads.

But autoplay is bad ok? Youtube and the like autoplay their videos. But before you push the launch button for your HTML 5 site, strongly consider whether it should autoplay a video.

Download

If the browser doesn’t know what to do with video tag, or if there is a display error, you can offer a download to the video instead:

Autobuffer

Autobuffer attribute is used when autoplay is not used but the page/site owner thinks the video will be watched at some point. The video is downloaded in the background, so when the user starts the video, it will be able to play at least some of the content. If both autoplay and autobuffer are used, then autobuffer is ignored.

It is worth pointing out at this point that the browser automatically downloads the video anyway, with or without autobuffer and there is nothing you can do about it. This has bandwidth and loading time issues, particularly if you have a lot of video on your page.

Poster

Use the poster attribute to display a frame of the video (as a .jpg, .png, whatever), in case the video doesn’t load for some reason. It can be a local image or elsewhere on the web


Try this page in Safari 4! Or you can download the video instead.

You should use the poster attribute because you don’t want the user to see nothing.

Controls

Adding this attribute means you can use your own play/pause/etc buttons for your video. Safari has lovely default controls but you can create your own.

Subtitles

There is no attribute for subtitles (yet – hello HTML 5 group) but just thought I’d mention it. Personally I love the way the JW FLV player handles it, but this is a very interesting read: http://blog.gingertech.net/2008/12/12/attaching-subtitles-to-html5-video/

But ideally, we will be able to delivery subtitles/description audio without javascript.

Current issues

Codecs

I won’t claim to be a video/audio codec expert but there are a few outstanding issues in this area, which this article does a good job explaining.

Internet Explorer

IE hasn’t a clue and as the market leader, will need to be addressed. Thankfully here at HTML 5 Doctor, we have a few hints and tips for IE that will be coming shortly.

Physical file

So far, the video tag needs to link to a physical file (see example at the top). What we need here is a way to just import, say a YouTube video, using the video tag, like we did with the embed tag.

When I set out writing this article, what I wanted to do was kick it back to 2008 and Rickroll the lot of you but so far I haven’t found a way to do it with the video tag.

Here’s what I think you should be able to do with the video tag:

How awesome would that be?

Conclusion

I think there is a long way to go yet but this tag has real potential. The issue over codecs looks certain to run and run, but you can put fall backs in the code, like the download link. You could use a combination of the video, object, embed elements, but that markup will be pretty horrendous:

In the meantime

If you don’t want to use the video tag yet, then here is valid XHTML code to display a video:

HTML5 Doctor » video

Video: the track element and webM codec

WebM video format

Related Posts:

Your Questions Answered #5

Headers and sidebars

Related Posts:

Related Posts: