Your Questions Answered #6

Richard Clark — Thu, 08 Apr 2010 14:30:59 +0000

We’re back with another round of patient questions about HTML5. In this article, we’ll discuss using multiple

s, audio codecs, microformats, post bylines, and the element.

Using multiple
s

Bnonn asked:

I’m unsure of how `h1` is supposed to be used now that pages can be divided into sections and articles. In (X)HTML4, a page was basically a page, and so you only had one `h1` element: the top level heading for the page. I’m not even sure if that was a requirement of HTML4, or if it was just a de facto standard, but it made sense.

Now, however, there are any number of possible sections and articles per page; each of which may contain any number of heading elements (and one of those might be inside a `header` element). Given that `h1` is a top-level heading, it seems as if each section and/or article should have one, in addition to the page-level `h1`. However, this contradicts what I know of accepted usage, so I’m confused about the way in which I should be marking up headings in HTML5. It doesn’t seem right to start headings in a `section`, for instance, with `h2`, because then…where’s the top-level heading for that element? But it doesn’t seem right to start them with `h1`, because that element in current web usage has more “power” than warrants its use there.

There is also SEO to wonder about. Even if using multiple `h1` elements is right, I wouldn’t want to be penalized for it by Google. So what’s the story with that?

Any help is much appreciated.

Regards,

Bnonn

Basically, you can use multiple

s in order to shape the document outline. So an

within a

will be treated like an

(if it is a nested

). If that

(and only that

) is aggregated elsewhere on the web, however, it will fit seamlessly into that external document’s outline. This means that your original

could be treated as an

, or
as appropriate.

I hope that makes sense! Bruce’s article on the section element touches on this, and we also hope to talk more about document outlines in the future.

Cheers,

Rich

P.S. Multiple
s in HTML4 are perfectly legal, but seldom used.

Audio Codecs

Adam asked:

Hello,

I’ve got a query about the issues regarding what codecs to use for the audio tag. I don’t quite get why Firefox won’t support mp3. Surely the browser calls on the codecs present on the operating system, not within the browser, so how are the licensing issues a problem to the browsers if they are simply leaving what is already present (and in theory already licensed)?

I fully admit that I am no lawyer. It just seems very odd the line of argument Mozilla has taken.

Adam Wilcox

I’m not sure why they’ve taken that stance, but I know that Mozilla only plans to support Ogg and Apple are keen to push MP3 and MP4, so we’re at stalemate. Because of this, discussion of specific codecs has been removed from the spec altogether.

Although not related to audio, see this article I wrote about YouTube and Vimeo supporting HTML5 video. It explains a little about codecs.

Sorry I can’t be of more help.

Rich

Since writing this reply there has been a lot more talk over codecs for both video and audio since Microsoft announced they would be supporting H.264 in IE9. We’ll cover this in more detail soon.

hCards

Ken asked:

How does html 5 deal with hCards and microformats in general? Specifically, can you have more than one hCard per page? As I understand it currently, having more than one is problematic. I’m asking now because of the treatment “footer” and “aside” has gotten, i.e. they are context sensitive to their “article” or “section” unless top-level, then applied to the page. Also, the use of scoped on style tags: hCards should be updated in a like manner for html 5.

Thanks for hearing me out. I don’t know if this is the appropriate place for this question, but as html 5 is much more useful, I thought maybe a post is in order

Also, “article”’s impact on the hAtom microformat makes for an interesting article, don’t ya think?

We touched upon microformats in our articles on the

and elements, but we’ll try to cover more soon (possibly in an article on the

element).

I haven’t heard that having more than one hCard is problematic. I’ve certainly never had any issues doing that. If you check out the source code on the homepage of HTML5Doctor, you’ll see we’ve used multiple hCards — one for each author’s name associated with a post.

Hope that helps a little.

Cheers,

Rich

Article bylines

Eric asked:

I tweeted to you guys a few days ago (@ericdfields), wondering what you recommend for bylines for blog posts. Bylines, borrowing a newspaper term, would be the ‘Posted by SoandSo on Nov 1, 2010′ copy you find under the article of your typical blog post.

To me, they seem like something of an ‘aside’ for the header of the document.

I don’t know if its perfectly valid, but here’s the test case I whipped up.

Thanks in advance for any insight!

In my opinion, they’re header or footer information, so I do:


  
    Foo
    Bar
  
  Posted by Bruce on 1st November

Thanks, Bruce

How to use with a date in astrology

Dear HTML5Doctors,

I was confused in how to using the time tag with the Astrology date. For example if I have a chunk of content like this:

ARIES: 13 Apr – 14 May

how can I use attribute “datetime” to explain the format of that date?
ARIES: 13 Apr - 14 May
The year of birth is not fixed, please advice me some solutions about this.

Thank you,

radiz

Hi Radiz,

The time element is for one specific day, not a range or “imprecise” date. So you can’t use it for “13 April.” You need to use it for a specific “13 April” and give a year. For more, see our article on the element.

Thanks, Bruce

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 #6 originally appeared on HTML5 Doctor on April 8, 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.

Native Audio in the browser

Mark Boas — Wed, 29 Jul 2009 15:00:29 +0000

Until recently, the ability to play any type of audio within a browser involved using Adobe Flash or other browser plugins. Although Adobe’s Flash player is unquestionably the most ubiquitous of these, most developers and designers would agree that it’s better not to rely on a plugin at all.

Enter HTML 5

One of the most exciting and long-awaited features in HTML 5 the element, enabling native audio playback within the browser. We can take advantage of this for browsers that support it — such as Safari 4, Firefox 3.5 and Chrome 3 — while falling back on Flash or other plugins for other browsers.

According to spec

Currently, the HTML 5 spec defines five attributes for the element:

src — a valid URL specifying the content source
autobuffer — a boolean specifying whether the file is to be buffered in advance
autoplay — a boolean specifying whether the file should play as soon as it can
loop — a boolean specifying whether the file should be repeatedly played.
controls — a boolean specifying whether the browser should display its default media controls

Note that these are the same attributes defined for the element.

Examples

Let’s take a couple of these attributes and create a simple example that will play an audio file:

(This example will work for Firefox 3.5 and Chrome 3. You’ll need to replace the Ogg file with an MP3 to get it working in Safari 4.)

Of course, the spec is not finalised, and there isn’t yet a consensus on which codecs to support. This table details the codecs supported by today’s browsers:

Codec support in modern browsers
Browser	Ogg Vorbis	MP3	WAV
FireFox 3.5	✓		✓
Safari 4		✓	✓
Chrome 3 (beta)	✓	✓
Opera 10 (beta)			✓

To create our own controls, we can use the API methods defined by the spec:

play() — plays the audio
pause() — pauses the audio
canPlayType() — interrogates the browser to establish whether the given mime type can be played
buffered() — attribute that specifies the start and end time of the buffered part of the file

Note that Opera 10 does not support the HTML element, but it does support the Audio() API in a basic and unique manner: from the above list, it only supports the play() method.

Safari 4, Firefox 3.5, and Chrome 3 beta support both and Audio(). Internet Explorer 8 has no native audio support whatsoever.

Use the Source

The best way to coerce browsers into playing audio (or video, for that matter) is to use the element. The browser will try to load the first audio source, and if it fails or isn’t supported, it will move on to the next audio source. In addition, we can embed a Flash player if all else fails:

One caveat, though: you need to be careful about the order of the elements. Because of a bug in Firefox, if you list the MP3 first (which Firefox doesn’t support), it will silently fail and refuse to render that particular element. The trick is to list the Ogg Vorbis file first and the other formats after. Webkit (Safari and Chrome) handle unsupported formats just fine.

Opera is another kettle of fish altogether, which we’ll need to solve using JavaScript.

Cross-Browser Implementation

When we created jPlayer, an audio player plugin for jQuery, we were attempting to address some of the limitations of the current crop of Flash-based audio players. Many relied on Flash to implement the player’s graphical interface, effectively isolating the player from the rest of the web design process.

The original jPlayer relied on Flash to play the actual audio while allowing the look and feel to be styled via HTML and CSS. With growing support for HTML 5 in modern browsers, we were inspired to break our Flash dependency and use native audio when it was supported.

The most significant issue is the cross-browser implementation, where lack of a common supported audio format among browsers causes complications. If developers want to take full advantage of all browsers that support HTML 5 audio, they’ll need to create both MP3 and Ogg (and in Opera’s case, WAV) versions of the audio file they want to stream!

Our job was made more difficult by the lack of available information:

Firefox 3.5 — quite a detailed document
Safari 4 — technically complete, but lacks explanations and examples
Opera 10 — only a short note
Chrome 3 — a wiki

Since the HTML 5 standard is still a work in progress, several aspects of the element vary from browser to browser. For example, there seems to be no way to determine the load progress of an audio file. Although Safari 4 can determine how much of an audio file has downloaded, Firefox 3.5 does not yet implement the buffered DOM attribute. (It is, however, included as part of the Firefox’s documentation, so we presume it will be implemented.)

Firefox 3.5 does appear to enable “seeking” of the file, allowing you to start the download from any point in the media. Other browsers, such as Safari 4, grab the file from the beginning and only allow seeking within the part already downloaded (or wait until the particular part being seeked to has been downloaded).

Although these inconsistencies aren’t showstoppers, in order to compete effectively with plugin-based solutions, we believe any HTML 5 audio implementation should be consistent across all browsers and match current implementations feature for feature.

JavaScript solutions

If we intend to take advantage of each browser’s audio capabilities, we need to create different solutions for different browsers. We could use browser sniffing, but considering the rapidly changing landscape, it’s better to check what capabilities a particular browser supports and adapt accordingly.

To demonstrate this “feature sniffing”, we’ve created a rough and ready HTML 5 audio checker.

Using JavaScript, you can check for audio tag support:

// returns a boolean
var audioTagSupport = !!(document.createElement('audio').canPlayType);

or check for the Audio() object:

try {
  // The 'src' parameter is mandatory in Opera 10, so have used an empty string "".
  // Otherwise, an exception is thrown.
  myAudioObj = new Audio(""); 

  audioObjSupport = !!(myAudioObj.canPlayType);
  basicAudioSupport = !!(!audioObjSupport ? myAudioObj.play : false);
} catch (e) {
  audioObjSupport = false;
  basicAudioSupport = false;
}

or check file type compatibility:

// Need to check the canPlayType first or an exception
// will be thrown for those browsers that don't support it
if (myAudio.canPlayType) {

  // Currently canPlayType(type) returns: "no", "maybe" or "probably"
  canPlayOgg = ("no" != myAudio.canPlayType("audio/ogg")) && ("" != myAudio.canPlayType("audio/ogg"));
  canPlayMp3 = ("no" != myAudio.canPlayType("audio/mpeg")) && ("" != myAudio.canPlayType("audio/mpeg"));
}

Note that to change the src attribute of an audio object or element, you’ll need to recreate the object or element with the new value for its src attribute.

So, to create a solution that takes full advantage of HTML 5 audio, you’ll typically need to:

check for HTML 5 audio support, and if not present, fall back on Flash,
check the level of HTML 5 audio support and adapt your code accordingly for each browser, and
check what file types are supported and link to appropriate formats of the files.

The Road Ahead

Although HTML 5 audio is a relatively immature part of the standard, if recent trends continue and users upgrade to the latest versions of Safari and Firefox, browser support will likely rise above the 25% mark in the very near future. This is a significant chunk of the browser market that will no longer need to rely on Adobe’s Flash, Microsoft’s Silverlight, or any other browser plugin for audio support.

And when you consider that mobile and other lower-spec devices — like Apple’s iPod and iPhone (Safari), Nintendo’s Wii (Opera), and Google Android-powered devices (Chrome) — are choosing to support HTML 5 audio rather than Flash, you begin to paint a picture of how important native audio support will soon become.

HTML5 Doctor » audio

Your Questions Answered #6

s, audio codecs, microformats, post bylines, and the element.

s

as appropriate.

I hope that makes sense! Bruce’s article on the section element touches on this, and we also hope to talk more about document outlines in the future.

Cheers,

Rich

P.S. Multiple

s in HTML4 are perfectly legal, but seldom used.

Audio Codecs

hCards

Article bylines

Foo

Bar

How to use with a date in astrology

Got a question for us?

Related Posts:

Why designers should care about HTML5

Semantic elements

Native Audio in the browser

Enter HTML 5

According to spec

Examples

Use the Source

Cross-Browser Implementation

JavaScript solutions

The Road Ahead

Further reading:

Related Posts:

HTML5 Doctor » audio

Your Questions Answered #6

s, audio codecs, microformats, post bylines, and the element.

s

as appropriate. I hope that makes sense! Bruce’s article on the section element touches on this, and we also hope to talk more about document outlines in the future. Cheers, Rich P.S. Multiple

s in HTML4 are perfectly legal, but seldom used.

Audio Codecs

hCards

Article bylines

How to use with a date in astrology

Got a question for us?

Related Posts:

Why designers should care about HTML5

Semantic elements

Native Audio in the browser

Enter HTML 5

According to spec

Examples

Use the Source

Cross-Browser Implementation

JavaScript solutions

The Road Ahead

Further reading:

Related Posts:

as appropriate.

I hope that makes sense! Bruce’s article on the section element touches on this, and we also hope to talk more about document outlines in the future.

Cheers,

Rich

P.S. Multiple