Advice is now provided in the HTML spec on how to mark up subheadings, subtitles, alternative titles and taglines using existing and implemented HTML features.

Advice for marking up subheadings and the like

The important question for developers is: How do I mark up these buggers???

To answer this advice has been added to the HTML specification on how to mark up subheadings, subtitles, alternative titles and taglines:

Note: Do not use h1–h6 elements to markup subheadings, subtitles, alternative titles and taglines unless they are intended to be the heading for a new section or subsection.

Note: Example below added 10/5/2013

In the following example the title and subtitles of a web page are grouped using a header element. As the author does not want the subtitles to be included the table of contents and they are not intended to signify the start of a new section, they are marked up using p elements. A sample CSS styled rendering of the title and subtitles is provided below the code example.

   <header>
   <h1>HTML 5.1 Nightly</h1>
   <p>A vocabulary and associated APIs for HTML and XHTML</p>
   <p>Editor's Draft 9 May 2013</p>
   </header>

In the following example the subtitle of a book is on the same line as the title separated by a colon.

<h1>The Lord of the Rings: The Two Towers</h1>

In the following example part of an album title is included in a span element, allowing it to be styled differently from the rest of the title.

   <h1>The Mothers 
   <span>Fillmore East - June 1971</span> 
   </h1>

In the following example the title and tagline for a news article are grouped using a header element. The title is marked up using a h2 element and the tagline is in a p element.

   <header>
   <h2>3D films set for popularity slide </h2>
   <p>First drop in 3D box office projected for this year despite hotly tipped summer blockbusters,
    according to Fitch Ratings report</p>
   </header>

Note: Some have been advocating of the use of the small element to signify subtitles. This has been under discussion in the HTML working group, but no compelling arguments for its use have been made. Therefore it is not advised to use small to mark up subtitles.

What about the document outline?

If you want a subtitle to be displayed in the semi-mythical document outline, include it along with the heading text as per example 1 and 2 above. If you don’t, put the text in a p element (for example), as per example 3 above.

Questions for developers

Does the advice in the spec cover the use cases you encounter? If not what other advice should the spec include? Are the examples clear and unambiguous? If not how could they be improved? Any other questions you have, ask away in the comments!

If you are really keen you can join the likes of Bruce Lawson, Ian Devlin and myself in the HTML working group and take part in discussion there.

What being obsolete in HTML5 means

must not be used by authors

hgroup like other obsolete features,  is non-conforming. This means that a conformance checker  displays an error  if the hgroup element is found. The following is the error message displayed by the W3C Markup Validation Service:

Error: The hgroup element is obsolete. To mark up subheadings, consider either just putting the subheading into a p element after the h1-h6 element containing the main heading, or else putting the subheading directly within the h1-h6 element containing the main heading, but separated from the main heading by punctuation and/or within, for example, a span element with differentiated styling. To group headings and subheadings, alternative titles, or taglines, consider using the header or div elements.

Like for other obsolete elements, browsers will continue their current level of support for hgroup. That is, browsers that have parsing and user agent style support will continue to do so, therefore authors that have used hgroup in their pages do not need to rush out and remove it. The element effectively has no meaning as its semantics have not been implemented. It’s effectively a div with a funny name.

The whys and wherefores

Much has been discussed and written over the past few years on the hgroup element and whether it meets the high bar required to include as a feature in HTML, on balance it has been decided it does not. Should this have happened more quickly? Yes , but as Mike[tm]Smith stated recently:

People disagree. Organizations disagree. The task of us all working together to try to overcome our disagreements is time-consuming, often very frustrating, and almost never easy.

If you want to read up on the history of hgroup there is plenty of stuff available:

HTML working group mail archives 2010 (tip of the iceberg):

• suggestion for abolition of hgroup thread (November)
• hgroup and ARIA outline thread
• suggestion for abolition of hgroup thread (December)

Selected articles on the subject:

• On the hgroup element
• Farewell, hgroup
• W3C Drops hgroup Tag From HTML5 Spec
• HTML5 Accessibility Chops: data for the masses
• The hgroup hokey cokey
• hgroup removed from the HTML5 specification
• RIP HTML5 hgroup Element

How to mark up subheadings, subtitles, alternative titles and taglines originally appeared on HTML5 Doctor on May 3, 2013.

Bruce grills him mercilessly; some questions were contributed over Twitter and co-interrogators are acknowledged below.

What’s your connection with HTML5?

I’ve been participating in the HTML Working Group since 2007 after reading a post by Roger Johansson. I have recently taken on the roles of HTML accessibility task force chair and co-editor of the HTML specification. I also edit Using ARIA in HTML, HTML5: Techniques for Providing Useful Text Alternatives and HTML to Platform Accessibility APIs Implementation Guide I also blog on accessibility and web standards.

Some people call you “the accessibility guy”. What do you call yourself?

I have lots of ways to self identify these days. The most important is being a dad to Clara and Eloisa.

What’s your day job?

I work as an accessibility engineer/director/consultant/curmudgeon at The Paciello Group. On a typical day I may be writing code, testing a site or application, reviewing the work of colleagues, talking with clients, (tor)mentoring colleagues (can’t wait until Patrick Lauke starts), working on the free testing tools we develop, editing the HTML spec or one of the other specs I edit, writing a blog post, filing bug reports on browsers or AT and as I work from home I try to squeeze in a kip (nap), while keeping an ear open for my boss Charlie pinging me on skype.

How did you get into the world of accessibility?

When I went back to Australia in 2001 after a 2 year stint as a HTML code cutter in London, I applied for a job at vision australia which combined my technical and social work interests (in a previous life I studied psychology at Sydney Uni and then worked with people with disabilities).

The job at vision australia was (I thought) as developer on their web site, but on the first day my then boss Brian Hardy threw a copy of WCAG 1.0 at me and said “read this”, and it started from there.

What’s the difference between W3C HTML5 and WHATWG HTML Living Standard?

The W3C has  HTML5 CR (Candidate Recommendation) which is a snapshot (also read Robin’s interview for more detail) and HTML 5.1 which is akin to the WHATWG spec in that it is up to date and includes new/unstable feature proposals. HTML 5.1 takes up most commits from the WHATWG spec unless there is disagreement in the HTML WG about a change.

HTML 5.1 is also modularised, meaning some features are developed as extension specifications within the “HTML5 family of specifications” This is the case for features such as HTML Canvas 2d context and some controversial new features (the <picture> element and srcset attribute being examples).

Once one or both new feature proposals get implemented they may well be moved into the core HTML spec. Another example is the <main> element. It started life as an an extension spec, but was pretty quickly integrated into HTML 5.1 as implementations occurred. It should be noted that the <main> element should be included in the HTML5 CR spec before it becomes irrevocably frozen, as it already meets the criteria of two interoperable implementations. It should also be noted that the text of HTML5 CR is not yet untouchable. It is still updated with bug fixes and I have a queue of changes to feature definitions, currently in HTML 5.1, to commit. More details about how the HTML recommendation process works can be found in: Plan 2014.

Which mailing list should I be subscribed to for W3C HTML? (Steve Fenton)

I recommend you join the HTML WG – anybody can. When you join, you are subscribed to a number of lists; the two to watch and contribute to are Public-HTML for technical discussion and Public-HTML-admin for process/admin stuff related to technical discussion.

How do you get a new element/ feature added to HTML? (Dr Rich Clark)

Lots of hard work, research, data gathering, use cases, discussion, haggling, etc. To get a feature added to HTML that involves implementation in browsers (i.e. vast majority) you need to get implementers to interested.

What I did for the <main> element was talk to as many implementers (both general browser implementers and accessibility implementers), developers, authors and users as I could and got advice and input from them. I went where the various people hung out; on IRC, mailing lists, twitter, blogs, conferences – anywhere.

Robin Berjon has written a useful HowTo on extension specifications which is a route you can use at the W3C (I used it for <main>). The WHATWG also provide info on how to do it via their process.

What drives you to push proposals through in the face of stiff opposition? (Steve Fenton)

A passion for pain mostly :-) also a desire to improve the web.

Do you plan to work on getting your changes upstreamed to the WHATWG spec? Do you coordinate with the upstream? (Henri Sivonen)

The way it currently works is that the WHATWG spec is a (major) source for the HTML 5.1 spec. We cherry-pick commits to the WHATWG spec to add to the HTML spec. Uncontroversial changes such as bug fixes, editorial tweaks, new features proposals that the HTML WG members have no issue with, get added on a weekly basis. We also do our own commits to the spec, for example I make improvements to the authoring advice and requirements and accessibility implementation stuff after discussions on the HTML list or in response to bug reports.

Co-ordination is a thorny issue the WHATWG is an important contributor to HTML and I have have reached out, but with limited success so far. Its safe to say that like HTML, the relationship between the WHATWG and the W3C is a work in progress.

I think the most important thing is that the HTML 5.1 spec reflects implementations and that includes advice and requirements on how authors should use HTML as implemented, to maximise the benefit to users.

Are you worried about WHATWG/ W3C specs diverging?

I used to worry a lot more about this. Implementation stuff is not diverging, authoring advice and requirements and advice are diverging as improvements are made to HTML 5.1. Ideally the WHATWG spec and the HTML 5.1 spec would not contain contrary advice, but I don’t think the threat of divergence, should stop us from making improvements to HTML that benefit authors and users. Its better to have the improvements out there for people to make use of rather than have two specs that agree, both of which contain advice fictions based not on implementation reality but on future possibilities.

Rephrasing from Isn’t it bad that the specs have forked?:

“The plan is to just do a better job with the HTML 5.1 spec, such that it becomes the logical and obvious choice for anyone wanting to figure out which spec they should use.”

What are the skills of a good editor?

Unsure about that, I don’t know. What I try to do is get as much feedback on stuff as possible, so I go out to where people are and badger them. I realise that I don’t know it all and therefore want to engage others to contribute their knowledge and am myself only an editor in a team contributing to the development of HTML. I also realise that HTML is a vast and complex specification and limit my editing to those areas that I feel knowledgeable and confident enough to contribute to (luckily I am part of a team).

Is the spec readable/ useful enough for authors?

I think the spec needs work to make the authoring advice contained in it more useful, usable and accurate. I am working on it. I have already committed changes to HTML 5.1 in response to feedback from authors, developers and users. I read a lot of articles and blogs picking up issues with the spec and discuss stuff with authors/developers who use the spec and book authors such as you who use it as source material. But really, it’s the users of the spec that decide if it’s readable/ useful enough, so I seek out and appreciate any feedback from them.

Why hasn’t the HTML5 outlining model really been implemented? (Marc Drummond)

My understanding is that the outline algorithm as currently defined is not intended to be implemented in browsers. Meanwhile it has sort of been implemented by the JAWS screen reader, but in a borked way. It is a proposed feature that  implementers in general have not shown an interest in. for this reason it is a feature at risk in the HTML5 CR specification and will likely be dropped before it becomes a Recommendation, it will probably live on in HTML 5.1 as a proposed feature and we will see how it goes.

<hgroup>: rubbish or not?

Good question! I think it’s a feature in search of a use case. The only use case cited for it is to mask subheadings from the unimplemented outline algorithm (see above). I don’t think it’s a good enough reason to add a new element to HTML. Also, its accessibility mappings are defined such that any content in it becomes one big heading. But it is there, so we have some choices: make it more useful by changing how it is defined and fixing the accessibility mappings, obsolete it and replace it with something that is more useful, obsolete it and replace it with advice on how to mark up subheadings using current features, or just leave as is…

Do you agree with Luke Stevens that the new structural elements miss the mark and we should just use <div>s with ARIA roles instead?

No. I think that there is improvement needed in how the elements are defined and how they are explained, but do not think that using divs and roles is the way forward. Some people imbue HTML structural features with magical properties that in reality are not present. What I try to do is look at how such features are used and work in practice, for users that actually consume the semantics and, where needed, modify the feature definitions to benefit users.

I asked Hixie why most of his fights are with accessibility practitioners. He said didn’t know. Have you got any ideas?

Hixie has strong opinions about how HTML should be defined; other people disagree with him. Conflict ensues at times. I believe the new development process for HTML at the W3C takes a lot of heat out of these disagreements providing a constructive environment for contributions from a wide range of stakeholders to the further development of the language of the web.

Now you’re an HTML5 doctor, what (apart from fame, glory and the adultation of beautiful people) do you hope to get from it and contribute?

Once I get over the shock and honour of being bestowed with a HTML5Doctorate, I hope to contribute by writing articles on the bits of HTML/ARIA I know best. I would also very much like to get as much input/feedback as possible from the good readers of HTML5Doctor and seek their collaboration in improving HTML 5.1.

The all-important grooming question: Blue Stratos or Old Spice?

I used to be a Blue Stratos kinda guy, but have switched to the far superior male fragrance Hai Karate after your recommendation.

Interview with Steve Faulkner: HTML5 editor and new doctor originally appeared on HTML5 Doctor on March 19, 2013.

New input types

HTML5 introduces no less than a baker’s dozen (yes, that’s 13!) new input types for forms. We’re going to take a brief look at each of them and explain why you should be using them right now. These new input types have dual benefits: using them means less development time and an improved user experience. The new input types we’ll be looking at are:

• search
• email
• url
• tel
• number
• range
• date
• month
• week
• time
• datetime
• datetime-local
• color

search

Search seems like an appropriate place to start our foray into HTML5 input types. When we talk about search, we’re not just talking about Google, Bing, or Yahoo. We’re talking about the search field on that e-commerce site you just made a purchase from, on Wikipedia, and even on your personal blog. It’s probably the most common action performed on the Web every day, yet it’s not marked up very semantically, is it? We all tend to write something like this:

<input type="text" name="search">

Well, what if we could write something like …

<input type="search" name="search">

With HTML5 we can. Feels much better, doesn’t it? Desktop browsers will render this in a similar way to a standard text field—until you start typing, that is. At this point, a small cross appears on the right side of the field. Notice the x in Figure 1. This lets you quickly clear the field, just like Safari’s built-in search field.

On a mobile device, however, things start to get interesting. Take the example iPhone shown in Figure 2; when you focus on an input using type="search", notice the keyboard, specifically the action button on the keyboard (bottom right). Did you spot that it says “Search” rather than the regular “Go”? It’s a subtle difference that most users won’t even notice, but those who do will afford themselves a wry smile.

As you’ve seen with the new attributes, browsers that don’t understand them will simply degrade gracefully. The same applies to all of the new input types discussed here. If a browser doesn’t understand type="search", it will default to type="text". This means you’re not losing anything. In fact, you’re using progressive enhancement and helping users to have a better experience. Let’s face it: filling out web forms isn’t very fun, so anything you can add to ensure a smoother experience, the better.

email

In rendering terms, the email input type is no different than a standard text input type and allows for one or more e-mail addresses to be entered. Combined with the required attribute, the browser is then able to look for patterns to ensure a valid e-mail address has been entered. Naturally, this checking is rudimentary, perhaps looking for an @ character or a period (.) and not allowing spaces. Opera 9.5+, Firefox 4+, Internet Explorer 10 and Chrome 5+ have already implemented this basic validation. The browser goes as far as presenting the user with an error message (see Opera in Figure 3) if the e-mail address entered isn’t valid. You can style the field for when an value is entered using the :valid, :invalid or :required pseudo class (assuming you have the required attribute on the input) just like Locum Dr. Peter explained.

<input type="email" name="email" required>

The specification details that one or more e-mail addresses are allowed. This means that the multiple attribute could be used with type="email" too.

Pretty cool, huh? Again, this highlights how HTML5 forms help to cut down the amount of JavaScript that you have to write when carrying out form validation.

There’s always a catch, though, right? At the time of writing, there is an internationalization issue with type="email". When using it with double-byte internationalized domain names, the browsers invalidate them; so this example

<input type="email" name="email" value="gordo@日本.jp">

isn’t valid in Firefox, Safari, or Chrome (there is no issue in Opera). However, a workaround has been created by Kyle Barrow that uses type="text" with the pattern attribute, as shown here:

<input type="text" name="email" value="gordo@日本.jp" pattern="[^ @]*@[^ @]*">

An alternative solution is to continue using type="email" with the formnovalidate attribute on the submit button, as follows. This ensures that no validation will be carried out on form submission, which may or may not be suitable for your needs.

<form action="process.php">
<label for="email">Email:</label>
<input type="email" name="email" value="gordo@日本.jp">
<input type="submit" formnovalidate value="Submit">
Or you could use the novalidate attribute on your form, like so:

<form action="process.php" novalidate> <label for="email">Email:</label>
<input type="email" name="email" value="gordo@日本.jp">
<input type="submit" value="Submit">

Internationalization issues aside, remember how we said there are dual benefits to HTML5′s input types—less development time and better user experience? Let’s go back and look at the iPhone once more, as shown in Figure 4.

Did you notice it this time? No? Look at the keyboard again. That’s right, the keyboard is different. There are dedicated keys for the @ and . characters to help you complete the field more efficiently. As we discussed with type="search", there is no downside to using type="email" right now. If a browser doesn’t support it, it will degrade to type="text". And in some browsers, users will get a helping hand.

url

The url input type, as you might expect, is for web addresses. You can use the multiple attribute to enter more than one URL. Like type="email", a browser will carry out simple validation on these fields and present an error message on form submission. This is likely to include looking for forward slashes, periods, and spaces, and possibly detecting a valid top-level domain (such as .com or .co.uk). Use the url input type like so:

<input type="url" name="url" required>

Again, we’ll take a look at how the iPhone renders type="url". As you can see in Figure 5, it has again updated the onscreen keyboard to ensure that completing the field is as simple as possible for the user by swapping the default space key for period, forward slash, and .com keys. (To access more endings like .org and .net, tap and hold the .com key.)

tel

tel differs from email and url in that no particular syntax is enforced. Phone numbers differ around the world, making it difficult to guarantee any type of specific notation except for allowing only numbers and perhaps a + symbol to be entered. It’s possible that you can validate specific phone numbers (if you can guarantee the format) using client-side validation. type="tel" is marked up as follows:

<input type="tel" name="tel" id="tel" required>

Once more, the iPhone recognises type="tel", only this time it goes one step further and completely changes the keyboard to the standard phone keyboard, as shown on the left in Figure 6. In addition to the iPhone, some Android devices (such as HTC Desire, shown on the right in Figure 6) also display a numeric keyboard for type="tel". That’s pretty handy, don’t you think? Nice, big keys for entering a phone number help you to get that big, nasty form completed quickly.

number

number, as you might expect, is used for specifying a numerical value. As with the majority of these new input types, Opera was the first to implement type="number". It, Safari, and Chrome render the input as a spinbox control (see Figure 7) whereby you can click the arrows to move up or down. Or if you prefer, you can type directly into the field. Firefox, on the other hand, renders the field like a standard text box. Support for type=”number” is in IE 10 also, although if you enter a non-numerical character the field empties when focus is lost and no feedback is provided to the user.

With the additional attributes min, max, and step we can change the default step value of this spinbox control as well as set minimum, maximum, and starting values (using the standard HTML value attribute). This example shows how these attributes work:

<input type="number" min="5" max="18" step="0.5" value="9" name="shoe-size">

In this example, min represents the minimum value the field will accept, and max represents the maximum value. If we reach the maximum or minimum value, the appropriate arrow on the spinbox control will be greyed out so you can no longer interact with it. step is the increment that the value should adjust up or down, with the default step value being 1. This means we can include negative values or step up in increments of 0.5 or 5. value is that attribute you’re used to from previous versions of HTML. Each of the attributes are optional, with defaults being set if they aren’t used.

In contrast to Opera’s implementation, the iPhone (Figure 8) and some Android devices (such as HTC Desire, shown on the right in Figure 6-13) simply render the field as a standard text box but optimize the keyboard for easy input.

To make the iPhone render with the standard telephone keypad as we saw for type="text" Chris Coyier, of CSS Tricks devised a little hoax you can use. Rather than using type=”number”, use a standard type="text" input and add a pattern attribute that accepts only numbers, as shown below. This solution isn’t ideal but if you think it could be useful, Chris has put a short video together showing it in action.

<input type="text" pattern="[0-9]*" name="shoe-size">

Chris’ technique may soon become absolete though with the introduction of the inputmode attribute. The attribute, recently added to the specification will allow users to specify the type of input mechanism that is most useful for users. When implemented, you will be able to choose between numeric, latin, email, or kana input modes.

range

The range input type is similar to number but more specific. It represents a numerical value within a given range. Why the difference, I hear you cry? Because when you’re using range, the exact value isn’t important. It also allows browsers to offer a simpler control than for number. In Opera, Safari, Internet Explorer 10 and Chrome, type="range" renders as a slider (see Figure 6-14). When moving the slider in IE 10 a tooltip appears showing the current value. Additionally, in Opera, if the CSS defines the height greater than the width, the slider control will be rendered vertically as opposed to the standard horizontal rendering.

The following code shows how we might mark up our skill level on a scale of 1 to 100 by setting the min and max attributes (see Figure 9). We can also set the starting point for range using the value attribute.

<input id="skill" type="range" min="1" max="100" value="0">

Dates and times

If you’ve ever booked tickets online, you will have come across date pickers to help you quickly and easily choose the date you require. Perhaps you’ve even implemented a date picker on your own website. Generally, this is done using a JavaScript library such as jQuery, Dojo, or YUI. It can be a pain when you need to load a whole library and associated plug-ins just to implement a simple date picker. Well, with HTML5 we get that functionality baked into the browser. Not only that, but we don’t have to stop at just electing a single date; we can select a week, month, time, date and time, and even date and time with a time zone using the different input types. The markup is pretty straightforward.

<input id="dob" name="dob" type="date">

You can go a step further by using the min and max attributes to ensure the user can only choose from a specified date range.

<input id="startdate" name="startdate" min="2012-01-01" max="2013-01-01" type="date">

As with many of the other form implementations, Opera leads the way (support in other browsers is varied). Let’s take a look next at how browsers render these input types.

date

Figure 10 shows Opera 10.5′s rendering of type="date".

These date pickers aren’t restricted to desktop devices; some Blackberry devices and Chrome for Android render its internal date picker when used with type="date" (see Figure 11).

month

Next up, Figure 12 shows type="month", which might, for example, be used for a credit card expiry date.

<input id="expiry" name="expiry" type="month" required>

week

You can also drill down to type="week". Notice how Opera highlights a specific week using the same date picker control, as shown in Figure 13.

<input id="vacation" name="vacation" type="week">

time

You can see in Figure 14 that type="time" renders a spinbox similar to that used earlier for selecting the precise time.

<input id="exit-time" name="exit-time" type="time">

datetime

We can combine the date and time by using type="datetime" for specifying a precise time on a given day, as shown in Figure 15.

<input id="entry-day-time" name="entry-day-time" type="datetime">

datetime-local

Finally, Figure 16 shows that we can achieve slightly more granular control by selecting a precise time on a given day with a local time zone variation using type="datetime-local".

<input id="arrival-time" name="arrival-time " type="datetime-local">

Date and time caveats

There are two caveats with these implementations. First, with the current implementation, it isn’t possible to type a date into the field (in all browsers). The date picker is keyboard accessible, though. However, we can foresee a potential issue; if implemented on a form that a data entry clerk regularly completes, they are likely to be quicker at typing the date than tabbing through with the keyboard or selecting from a date picker. Second, it isn’t possible to style the look of the date picker. We tend to think that this is a good thing, as users will receive a common experience across all websites they visit (provided they use the same browser all the time). Undoubtedly, though, corporations will require a branded date picker. Safari 5 and Chrome 5 have implemented these input types, but, unfortunately, they aren’t very user friendly. Dates have to be entered in the same format as the time element that we met earlier in the book. So for dates, the format would be YYYY-MM-DD, and for dates with time, a user would have to enter YYYYMM-DDT00:00Z, which is not very friendly at all.

As with the other new input types, if a browser doesn’t recognize them, it will simply default back to type="text" and let the user continue to use your JavaScript date picker.

color

The color input type is pretty self-explanatory: it allows the user to select a color and returns the hex value for that color. It is anticipated that users will either be able to type the value or select from a color picker, which will either be native to the operating system or a browser’s own implementation. Opera 11 has implemented type=”color” with a simple color picker that offers a number of standard color choices or the option to select Other, which brings up the operating system color picker (shown on the right in Figure 17).

<input id="color" name="color" type="color">

In contrast, certain Blackberry devices have implemented the color input type that renders a color picker, as shown in Figure 18.

This is article is an excerpt from Chapter 6 of Beginning HTML5 and CSS3: The Web Evolved by Christopher Murphy, Oli Studholme, Richard Clark and Divya Manian, published by Apress.

Buy the book

HTML5 forms input types originally appeared on HTML5 Doctor on February 28, 2013.

As we’ll see, these new features will go a long way toward making your life easier while delivering a delightful user experience. The best thing about all this? You can start using them now. We’ll start with a (very) brief history of HTML5 forms though.

HTML5 form attributes

There are 14 new attributes that we’ll be looking at in this article.

• placeholder
• autofocus
• autocomplete
• required
• pattern
• list
• multiple
• novalidate
• formnovalidate
• form
• formaction
• formenctype
• formmethod
• formtarget

placeholder

First up is the placeholder attribute, which allows us to set placeholder text as we would currently do in HTML4 with the value attribute. It should only be used for short descriptions. For anything longer, use the title attribute. The difference from HTML4 is that the text is only displayed when the field is empty and hasn’t received focus. Once the field receives focus (e.g., you click or tab to the field), and you begin to type, the text simply disappears. It’s very similar to the search box you see in Safari (see Figure 1).

Let’s have a look at how to implement the placeholder attribute.

<input type="text" name="user-name" id="user-name" placeholder="at least 3 characters">

That’s it! We can hear you thinking, “What’s so great about that? I’ve been doing it with JavaScript for years.” Yes, that’s true. However, with HTML5, it’s part of the browser, meaning less scripting is required for a more accessible, cross-browser solution (even when JavaScript is disabled). Figure 2 shows the placeholder attribute working in Chrome.

Browsers that don’t support the placeholder attribute ignore it, so it won’t render. By including it, though, you’re providing an enhanced user experience for those users who have browser support and you’re “future proofing” your site. All modern browsers support placeholder.

Note: There is no official pseudo-class for styling placeholder text but both Mozilla (makers of Firefox) and WebKit offer vendor prefixed properties for styling (-mozplaceholder and –webkit-input-placeholder). This makes it safe to assume that a pseudo-class will become standard for styling placeholder text. For further detail there is a thread on the WHATWG mailing list about this topic.

autofocus

autofocus does exactly what it says on the tin. Adding it to an input automatically focuses that field when the page is rendered. As with placeholder, autofocus is something that we used JavaScript for in the past.

Traditional JavaScript methods do, though, have some serious usability problems. For example, if a user begins completing the form before the script loads, they will (jarringly) be returned to the first form field when the script is loaded. The autofocus attribute in HTML5 gets around this issue by focusing as soon as the document loads, without having to wait for the JavaScript to be loaded. However, we only recommend using it for pages whose sole purpose is the form (like Google) to prevent the usability issues.

It is a Boolean attribute (except if you are writing XHTML5; see the note) and is implemented as follows:

<input type="text" name="first-name" id="first-name" autofocus>

All modern browsers support the attribute and, like placeholder, browsers that don’t support the autofocus attribute simply ignore it.

Note: Several new HTML5 form attributes are Boolean attributes. This just means they’re set if they’re present and not set if they’re absent. They can be written several ways in HTML5.

autofocus
autofocus=""
autofocus="autofocus"

However, if you are writing XHTML5, you have to use the autofocus="autofocus" style.

autocomplete

The autocomplete attribute helps users complete forms based on earlier input. The attribute has been around since IE5.5 but has finally been standardized as part of HTML5. The default state is set to on. This means that generally we won’t have to use it. However, if you want to insist that a form field be entered each time a form is completed (as opposed to the browser autofilling the field), you would implement it like so:

<input type="text" name="tracking-code" id="tracking-code" autocomplete="off">

The autocomplete state on a field overrides any autocomplete state set on the containing form element.

required

The required attribute doesn’t need much introduction; like autofocus, it does exactly what you’d expect. By adding it to a form field, the browser requires the user to enter data into that field before submitting the form. This replaces the basic form validation currently implemented with JavaScript, making things a little more usable and saving us a little more development time. required is a Boolean attribute, like autofocus. Let’s see it in action.

<input type="text" id="given-name" name="given-name" required>

required is currently implemented only in Opera 9.5+, Firefox 4+, Safari 5+, Internet Explorer 10 and Chrome 5+, so for the time being you need to continue writing a script to check that fields are completed on the client side in other browsers (*cough* IE!). Opera, Chrome, and Firefox show the user an error message (see Figure 3) upon form submission. In most browsers, the errors are then localized based on the declared language. Safari doesn’t show an error message on submit, but instead places focus on that field.

The default rendering of “required” error messages depends on the individual browser; at present the error message bubble can’t be styled with CSS in all browsers. Chrome, however, does have a proprietary property that you can use to style the error bubble. Peter Gasston has written an article about the syntax. You can also style the input using the :required pseudo-class. An alternative is to override the wording and styling using the setCustomValidity() method in JavaScript. Importantly, don’t forget that this browser validation is no substitute for validating on the server as well.

pattern

The pattern attribute is likely to get a lot of developers very excited (well, as excited as you can get about form attributes). It specifies a JavaScript regular expression for the field’s value to be checked against. pattern makes it easy for us to implement specific validation for product codes, invoice numbers, and so on. The possibilities for pattern are wide-ranging, and this is just one simple example using a product number.

<label>Product Number:
<input pattern="[0-9][A-Z]{3}" name="product" type="text" title="Single digit followed by three uppercase letters."/>
</label>

This pattern prescribes that the product number should be a single digit [0-9] followed by three uppercase letters [A-Z]{3}. For more examples, the HTML5 Pattern website lists common regex style patterns to help get you started.

As with required, Opera 9.5+, Firefox 4+, Safari 5+, Internet Explorer 10 and Chrome 5+ are the only browsers with support for pattern at present. However, with the browser market moving at a fast pace, the others will soon catch up.

list and the datalist element

The list attribute enables the user to associate a list of options with a particular field. The value of the list attribute must be the same as the ID of a datalist element that resides in the same document. The datalist element is new in HTML5 and represents a predefined list of options for form controls. It works in a similar way to the in-browser search boxes that autocomplete as you type (see Figure 4).

The following example shows how list and datalist are combined (see Figure 5):

<label>Your favorite fruit:
<datalist id="fruits">
  <option value="Blackberry">Blackberry</option>
  <option value="Blackcurrant">Blackcurrant</option>
  <option value="Blueberry">Blueberry</option>
  <!-- … -->
</datalist>
If other, please specify:
  <input type="text" name="fruit" list="fruits">
</label>

By adding a select element inside the datalist you can provide superior graceful degradation than by simply using an option element. This is an elegant markup pattern designed by Jeremy Keith that adheres perfectly with HTML5′s principle of degrading gracefully.

<label>Your favorite fruit:
<datalist id="fruits">
  <select name="fruits">
    <option value="Blackberry">Blackberry</option>
    <option value="Blackcurrant">Blackcurrant</option>
    <option value="Blueberry">Blueberry</option>
    <!-- … -->
  </select>
If other, please specify:
</datalist>
  <input type="text" name="fruit" list="fruits">
</label>

Browser support for list and datalist is currently limited to Opera 9.5+ (see Figure 5), Chrome 20+, Internet Explorer 10 and Firefox 4+.

multiple

We can take our lists and datalists one step further by applying the Boolean attribute multiple to allow more than one value to be entered from the datalist. Here is an example.

<label>Your favorite fruit:
<datalist id="fruits">
  <select name="fruits">
    <option value="Blackberry">Blackberry</option>
    <option value="Blackcurrant">Blackcurrant</option>
    <option value="Blueberry">Blueberry</option>
    <!-- … -->
  </select>
If other, please specify:
</datalist>
  <input type="text" name="fruit" list="fruits" multiple>
</label>

multiple isn’t exclusively for use with datalists, though. A further example for multiple might be for email addresses when sending items to friend or the attachment of files, as shown here:

<label>Upload files:
<input type="file" multiple name="upload"></label>

multiple is supported in Firefox 3.6+, Safari 4+, Opera 11.5+, Internet Explorer 10 and Chrome 4+.

novalidate and formnovalidate

The novalidate and formnovalidate attributes indicate that the form shouldn’t be validated when submitted. They are both Boolean attributes. formnovalidate can be applied to submit or image input types. The novalidate attribute can be set only on the form element.

An example use case for the formnovalidate attribute could be on a “save draft” button, where the form has fields that are required for submitting the draft but aren’t required for saving the draft. novalidate would be used in cases where you don’t want to validate the form but do want to take advantage of the more useful user interface enhancements that the new input types offer.

The following example shows how to use formnovalidate:

<form action="process.php">
  <label for="email">Email:</label>
  <input type="text" name="email" value="gordo@example.com">
  <input type="submit" formnovalidate value="Submit">
</form>

And this example shows how to use novalidate:

<form action="process.php" novalidate>
  <label for="email">Email:</label>
  <input type="text" name="email" value="gordo@example.com">
  <input type="submit" value="Submit">
</form>

form

The form attribute is used to associate an input, select, or textarea element with a form (known as its form owner). Using form means that the element doesn’t need to be a child of the associated form and can be moved away from it in the source. The primary use case for this is that input buttons that are placed within tables can now be associated with a form.

<input type="button" name="sort-l-h" form="sort">

formaction, formenctype, formmethod, and formtarget

The formaction, formenctype, formmethod, and formtarget attributes each have a corresponding attribute on the form element, which you’ll be familiar with from HTML4, so let’s run through each of them briefly. These new attributes have been introduced primarily because you may require alternative actions for different submit buttons, as opposed to having several forms in a document.

formaction

formaction specifies the file or application that will submit the form. It has the same effect as the action attribute on the form element and can only be used with a submit or image button (type="submit" or type="image"). When the form is submitted, the browser first checks for a formaction attribute; if that isn’t present, it proceeds to look for an action attribute on the form.

<input type="submit" value="Submit" formaction="process.php">

formenctype

formenctype details how the form data is encoded with the POST method type. It has the same effect as the enctype attribute on the form element and can only be used with a submit or image button (type="submit" or type="image"). The default value if not included is application/x-www-formurlencoded.

<input type="submit" value="Submit" formenctype="application/x-www-form-urlencoded">

formmethod

formmethod specifies which HTTP method (GET, POST, PUT, DELETE) will be used to submit the form data. It has the same effect as the method attribute on the form element and can only be used with a submit or image button (type="submit" or type="image").

<input type="submit" value="Submit" formmethod="POST">

formtarget

formtarget specifies the target window for the form results. It has the same effect as the target attribute on the form element and can only be used with a submit or image button (type="submit" or type="image").

<input type="submit" value="Submit" formtarget="_self">

This is article is an excerpt from Chapter 6 of Beginning HTML5 and CSS3: The Web Evolved by Christopher Murphy, Oli Studholme, Richard Clark and Divya Manian, published by Apress.

Buy the book

HTML5 forms introduction and new attributes originally appeared on HTML5 Doctor on February 26, 2013.

HTML5 makes life easier for us by defining an element whose sole purpose is just that: the <progress> element.

The HTML5 specification describes it best:

The progress element represents the completion progress of a task.

The task itself is irrelevant, but displaying its progress is not.

<progress id='p'></progress>

<progress id='p' max='70'><span>0</span>%</progress>

var pBar = document.getElementById('p');
var updateProgress = function(value) {
  pBar.value = value;
  pBar.getElementsByTagName('span')[0].innerHTML = Math.floor((100 / 70) * value);
}

<progress id='p' max='100' value='0'><span>0</span>% played</progress>

var video = document.getElementById('v');
var pBar = document.getElementById('p');
video.addEventListener('timeupdate', function() {
  var percent = Math.floor((100 / video.duration) * video.currentTime);
  pBar.value = percent;
  pBar.getElementsByTagName('span')[0].innerHTML = percent;
}, false);

var p = document.getElementById('p');
// 'reader' is of type FileReader
reader.addEventListener('loadstart', function(evt) {
  if (evt.lengthComputable) p.max = evt.total;
}, false);
reader.addEventListener('progress', function(evt) {
  if (evt.lengthComputable) p.value = evt.loaded;
}, false);

Styling #

As is usual with such elements, browsers have their own unique styling for the <progress> element. You can, however, override this to a certain extent using simple CSS.

The default styling tends to consist of an element with rounded corners, a grey background colour, and a green gradient for the actual progress marker.

Let’s say we want to style our progress bar for the HTML5 Doctor website, so that it fits in with the design. We’ll remove the bevel and the gradients using only solid colours. The code below will almost do that:

progress {
  color: #0063a6;
  font-size: .6em;
  line-height: 1.5em;
  text-indent: .5em;
  width: 15em;
  height: 1.8em;
  border: 1px solid #0063a6;
  background: #fff;
}

This, however, won’t change the colour of the progress bar itself, which will remain a green colour. We can change this in Firefox, Internet Explorer 10, Chrome, and Safari using a variety of methods which are outlined below.

Firefox #

All we need to use here is:

progress::-moz-progress-bar { background: #0063a6; }

and Firefox will display the colour correctly.

Chrome and Safari #

For Chrome and Safari, we need to use progress::-webkit-progress-value to specify the progress bar colour and progress::-webkit-progress-bar to specify the background colour of the <progress> element itself:

progress::-webkit-progress-bar { background: #fff; }
progress::-webkit-progress-value { background: #0063a6; }

Internet Explorer 10 #

Actually the CSS above will be fine to style the <progress> element in IE10, but it’s worth noting that this browser interprets the <progress> element’s color value as the colour of the progress bar.

I’ve uploaded some working examples of determinate and indeterminate progress bars for you to see.

The progress element originally appeared on HTML5 Doctor on February 12, 2013.

Pinterest, for the uninitiated of you, allows you to organise and share things you love — mostly food, drink, and kittens.

We’re going to look at how to mark up a single pinned item, as shown below:

The existing markup is below (I’ve simplified it a little to make it easier to read):

<div class="pin">
  <div class="pin-holder">
    <div class="actions">
      <a href="#repin">Repin</a>
      <a href="#like">Like</a>
      <a href="#comment">Comment</a>
    </div>
    <a href="me/cat/">
      <img src="cat.jpg" alt="My awesome cat">
    </a>
  </div>
  <p>Awesome cat description.</p>
  <p class="stats">
    <span>25 likes</span>
    <span>2 comments</span>
    <span>100 repins</span>
  </p>
  <div class="convo">
    <a href="/me/">
      <img src="me.jpg" alt="Profile picture of me">
    </a>
    <p><a href="/me/">Me</a> onto <a href="/here/">here</a></p>
  </div>
</div>

So, all’s well and good, but how should it be marked up in HTML5? As the saying goes, there are a hundred ways to skin a cat (excuse the pun). We’ve created five possible options, one of which achieved some consensus amongst the Doctors. Be warned: some of the differences between options are small and may be difficult to spot. Look carefully at each option!

Let us know which answer you would go with (or roll your own) in the comments. Make sure you show your working out. Also, please escape your HTML (or use pseudo code), or we’ll put a severed unicorn head skinned cat in your bed.

<article class="pin">
  <div class="pin-holder">
    <nav class="actions">
      <a href="#repin">Repin</a>
      <a href="#like">Like</a>
      <a href="#comment">Comment</a>
    </nav>
    <a href="me/cat/">
      <img src="cat.jpg" alt="My awesome cat">
    </a>
  </div>
  <p>Awesome cat description.</p>
  <aside class="stats">
    <span>25 likes</span>
    <span>2 comments</span>
    <span>100 repins</span>
  </aside>
  <article class="convo">
    <a href="/me/">
      <img src="me.jpg" alt="Profile picture of me">
    </a>
    <p><a href="/me/">Me</a> onto <a href="/here/">here</a></p>
  </article>
</article>

<article class="pin">
  <div class="pin-holder">
    <aside class="actions">
      <a href="#repin">Repin</a>
      <a href="#like">Like</a>
      <a href="#comment">Comment</a>
    </aside>
    <a href="me/cat/">
      <img src="cat.jpg" alt="My awesome cat">
    </a>
  </div>
  <p>Awesome cat description.</p>
  <aside class="stats">
    <span>25 likes</span>
    <span>2 comments</span>
    <span>100 repins</span>
  </aside>
  <article class="convo">
    <a href="/me/">
      <img src="me.jpg" alt="Profile picture of me">
    </a>
    <p><a href="/me/">Me</a> onto <a href="/here/">here</a></p>
  </article>
</article>

<article class="pin">
  <div class="pin-holder">
    <nav class="actions">
      <a href="#repin">Repin</a>
      <a href="#like">Like</a>
      <a href="#comment">Comment</a>
    </nav>
    <figure>
      <a href="me/cat/">
        <img src="cat.jpg" alt="My awesome cat">
        <figcaption>Awesome cat description.</figcaption>
      </a>
    </figure>
  </div>
  <aside class="stats">
    <span>25 likes</span>
    <span>2 comments</span>
    <span>100 repins</span>
  </aside>
  <article class="convo">
    <a href="/me/">
      <img src="me.jpg" alt="Profile picture of me">
    </a>
    <p><a href="/me/">Me</a> onto <a href="/here/">here</a></p>
  </article>
</article>

<section class="pin">
  <div class="pin-holder">
    <aside class="actions">
      <a href="#repin">Repin</a>
      <a href="#like">Like</a>
      <a href="#comment">Comment</a>
    </aside>
    <figure>
      <a href="me/cat/">
        <img src="cat.jpg" alt="My awesome cat">
        <figcaption>Awesome cat description.</figcaption>
      </a>
    </figure>
  </div>
  <p class="stats">
    <span>25 likes</span>
    <span>2 comments</span>
    <span>100 repins</span>
  </p>
  <div class="convo">
    <a href="/me/">
      <img src="me.jpg" alt="Profile picture of me">
    </a>
    <p><a href="/me/">Me</a> onto <a href="/here/">here</a></p>
  </div>
</section>

<div class="pin">
  <article class="pin-holder">
    <aside class="actions">
      <a href="#repin">Repin</a>
      <a href="#like">Like</a>
      <a href="#comment">Comment</a>
    </aside>
    <a href="me/cat/">
      <img src="cat.jpg" alt="My awesome cat">
      <p>Awesome cat description.</p>
    </a>
  </article>
  <aside class="stats">
    <span>25 likes</span>
    <span>2 comments</span>
    <span>100 repins</span>
  </aside>
  <div class="convo">
    <a href="/me/">
      <img src="me.jpg" alt="Profile picture of me">
    </a>
    <p><a href="/me/">Me</a> onto <a href="/here/">here</a></p>
  </div>
</div>

Your answers below, please, with your rationale, by Tuesday, 29th January.

Simplequiz #7: Pinterest originally appeared on HTML5 Doctor on January 22, 2013.

Hot on the heels of our interview with Robin Berjon, editor of HTML5 at W3C, over the weekend I interviewed Ian Hickson, editor of HTML “The Living Standard” at WHATWG and, arguably, the most influential individual working on the Web today. Hickson, known as “Hixie”, works for Google and previously worked for Opera (my employer) and Netscape.

Some of questions were suggested by web developers over Twitter, where indicated.

If you could wipe out any web technologies from existence, which would you choose? (from @webr3)

HTML, JavaScript, DOM, anything I’ve ever invented, SVG, XML, JSON, CSS — basically anything that anyone uses! The Web technology stack is a complete mess. The problem is: what would you replace it with?

The Web’s technology stack is one of the only (maybe the only? I’m hard pressed to come up with another example) platform that is completely vendor-neutral and not centrally developed. Anyone can invent a new feature and if the market agrees, can get that feature to be a de facto part of the platform. XMLHttpRequest is a classic example. A browser cannot be a serious competitor on the Web without supporting it now, yet it was initially just made up and shipped by one vendor without any consultation with anyone. Even the features that are designed in public with wide review end up implemented and used before they’re “done”, and once they’re used they can’t be changed — which leads to APIs that make no sense, like pushState(), which has a required argument that is ignored.

The hardest part of this is that we can’t tell if something we’ve designed is any good without testing it in real world sites, and by the time it’s been properly tested, it’s too late to change it. pushState() happened like this (where we learnt that the second of the three arguments should be dropped only after there were already pages depending on using the first and third arguments), but there are even bigger examples: the CSS cascade and specificity mechanism, for example, which was a great idea but that doesn’t quite work at the end of the day, or even XML and specifically XML namespaces, which are widely recognised as a disaster but which whole layers of the Web platform depend on.

This isn’t helped by the way that certain parts of the platform that are now absolutely core central pillars, like JavaScript, essentially started as experiments; or the way that other features, like the offline application cache API, were designed with a very limited understanding of how authors would eventually use them. (Appcache works great if you want to do what it was designed for, but it turns out most people want to do something different enough that appcache feels horrible to them.)

In the end, the most horrible parts of the Web are also the most successful, because it’s the most successful parts that get extended by the most people, and so that have the least coordination in terms of their long-term evolution, which is how things end up being horrible.

HTML5 vs. the “living standard”: how do I know which elements will be around ten years from now, so I can safely use them in client work? (from @szafranek)

You know what will be around ten years from now by looking at what is implemented in two browsers today. If it’s implemented in two browsers today, I can almost guarantee it’ll still be around in ten years. If it’s not, all bets are off.

This has nothing to do with “living standard” vs. versioned specs, though. HTML4 has all kinds of features that aren’t in HTML anymore — for example, <object declare> and <a coords>.

Do you feel there’s enough innovation within the user agent market, since most are virtually equivalent in every way? (From @webr3)

I don’t really agree with the premise of the question. Browsers differ in many important ways. One of the reasons they might seem to be “virtually equivalent”, though, is that they often adopt features from each other. Another is that one of the key features they’ve all been trying for is “get out of the way and let the Web shine through”, which means you see less and less of the browser itself.

In the area of browser development that I’m most familiar with — namely the Web technology stack — there’s a lot of innovation going on. I get a lot of e-mails from browser vendors asking me to spec their new invention so that it has a spec and can be implemented by everyone else also. In fact, it’s gotten to the point where I have to track these requests to make sure I only spec those with multiple vendors on board. (I don’t want to end up with a spec where each section is only implemented by one browser. That would be a waste of everyone’s time.)

The browser space right now has more active competition than it ever has had in the past, especially on desktops. It’s a great time for users.

Why are you the one who always says “no”? Casing the <picture> and <main> elements here (from @helloanselm). Why so grumpy? (from @steve_fenton)

The short answer is, it’s my job!

There’s really two questions here. First, why do we in general say “no” so often? And second, why is it that it’s so often me that says it?

The first one is a combination of prioritisation and design.

First, let’s look at prioritisation. There are very limited resources available to add features to the Web. Every feature has a cost:

• Implementation: someone has to write code for it in each browser
• Testing: someone has to write the tests to check the feature is working
• QA: someone has to regularly run the tests to make sure the feature doesn’t regress
• Code maintenance: when browser vendors refactor code, they have to refactor more code if there are more features
• Tutorials: people who write tutorials have to include the feature, or handle feedback asking for them to do so
• Cognitive load: authors learning the platform have more documentation to wade through, even if they don’t care about the feature
• Page maintenance: authors have to know how to maintain the feature if other people have used it in pages they now maintain
• Spec writing: someone has to write the spec for the feature and ensure it’s maintained
• Bug fixing: when bugs are found in the spec or implementations, they have to be maintained
• Code size: each feature increases the size of browsers (both on-disk binaries and in-memory resident size)

(This list comes from our FAQ.)

We get an absolute torrent of feature requests, from authors, users, browser vendors, etc. So we have to prioritise:

• Is the feature going to be implemented by more than one browser? If no browser has signed up, or if only one has signed up and no other browsers have shown any interest, then I add it to the page of notes I mentioned earlier, and move on.
• Is the feature a game changer, or is it merely incremental? If the feature does no more than save a line of code every now and then, then its value probably doesn’t warrant its cost.
• Is the feature compatible with the Web philosophy? If the request is for a way to force the user to read something the way the author wants, it’s likely to be a non-starter. If it’s something that enables the user to control the page better, that’s more likely to be a winner.
• Is it more important than everything else? This is a great way to filter ideas: is your idea the most important thing we can do to improve the Web? There’s not always a direct tradeoff. The people who work on a browser’s JavaScript engine are often not the same people who work on a browser’s canvas API, for instance. But there’s always an opportunity cost — adding one feature means we won’t have the time or resources to add another.

So that’s the first part of the answer: we say “no” because we don’t have time to add everything. <main> is a great example of this. In my opinion, the value it adds is so minimal that it just isn’t worth the cost.

Next, let’s look at design. The way we usually approach ideas is that we describe the problem, then we come up with solutions to the problem and compare them by evaluating them against the problem. This is where most concrete proposals run into a “no”, because something else got the “yes” instead.

<picture> is an example of this. We described the problem (that took a few months of back and forth), and then once we had a problem description, I looked at the various proposals and synthesised a solution based on those that addressed the problems adequately while trying to avoid some common design pitfalls based on lessons we’d learnt from previous ideas. So for example with <picture>, we learnt with <video> and <source> that having multiple elements for selecting a resource is a huge design pitfall, so when designing a solution to the problem here, I avoided that (hence the srcset="" design based on CSS’s image-set() proposal).

So that’s the second part of the answer. We say “no” to some specific proposals because we’ve come up with other (better) solutions instead.

The second implicit question here was why do I say “no” so much, as opposed to other people. This is basically politics. It’s hard to say “no”, in part because of human nature, but also in part because when you say “no” in this kind of context you tend to invite argument. Most browser vendors don’t have time to have these arguments. I do. It’s my job, and I’ve gotten pretty good at saying “no” over the years. So a lot of the veteran browser engineers will just redirect people to me and expect me to say “no” for them. This lets them get on with their job of writing a browser, redirecting all the ire and arguments to me, whose job it is to field them. Or they’ll see an e-mail to the WHATWG list, think “oh my, that’s crazy”, but just stay silent because “Hixie will deal with it”.

In reality, I can’t really say either “yes” or “no”. What I say doesn’t mean anything: I don’t write any browsers. The browser vendors say “no” to me all the time by not implementing what I’ve specced. Just last week I revamped part of the spec (on context menus) because none of the browser vendors implemented it. One of the specs I spent years of my life on — XBL2 — has gone precisely nowhere because the browser vendors just don’t want to implement it. (My main mistake with XBL was trying to solve the whole problem at once, rather than doing it in incremental steps that implementors could more easily deal with.)

Similarly, there’s stuff that was never specced, indeed stuff that I’ve said “no” to myself, which the browser vendors nonetheless implemented. Again with the context menu example: Gecko implemented it by having an element called <menuitem>, which I argued forcefully was a bad design. They disagreed with my arguments and implemented it anyway, and so (eventually) I updated the spec to have <menuitem>. (This isn’t a criticism of Mozilla. It’s how these things are done. They did nothing wrong here.)

Do you feel there’s enough feedback from HTML authors, rather than vendors, getting through to specification editors/authors? (from @webr3)

I don’t know about “enough”. Is there ever “enough” feedback?

We do get a lot of feedback from Web developers, but it’s true that most of it has to be collected by seeking it out on forums, sites like Reddit, Twitter, Google+, people’s blogs, etc. I have some Google Alerts that lead me to a lot of places where people are complaining about HTML in one way or another, which I use as feedback. It’s almost certainly not enough. I wish we had more authors participating directly by either filing bugs or participating in the WHATWG list. People probably don’t realise how much feedback we get from developers, because they don’t see me reading the blogs and so on. Also, a lot of the feedback browser vendors send us is actually of the form “Web developers tell us that…” (though they often don’t say that explicitly).

The problem, to be honest, is that most authors don’t know what they want. Many years ago, Google actually paid for a usability study for one of the features I was speccing (microdata) and it was absolutely fascinating to see how people’s actual performance was so divergent from their impressions. We’d ask them questions like, “Which would be simpler, this or that?”, and then we’d actually test them by having them use the options, and there was just no relationship between what people said they wanted and what people were actually able to use.

Often when people send feedback (not just authors; pretty much anyone who hasn’t been in the process for a long time starts this way), they send feedback along the lines of “I want to add feature X” or “I want feature X to be extended in manner Y”. But when we drill down and ask them, “What problem are you trying to solve?”, or, “What’s your use case?” (same question but phrased differently), we often find that either (a) they actually don’t have a real problem and just thought that it would be a good idea, or (b) their solution wouldn’t actually solve their problem. Often we’re able to come up with much simpler solutions (or point to already existing solutions), which is quite satisfying.

Two and a half years ago, I asked you, “Would you like to be the HTML 6 editor?”. You replied, “I might want a change of pace when we’re done with HTML 5.” How come you decided not to take that holiday and continue editing HTML?

We’re not done yet. I still have 238 e-mails and 163 bugs remaining.

Do you have an exit strategy, or would you like to edit HTML for the forseeable future?

Well, I could stop any time, really. So long as I find it interesting and implementors respect my work, though, why stop? We have a severe lack of spec writers who are able to write good specs.

For styling form components, we were told to wait for XBL, then to wait for Web Components. Anne van Kesteren said, “After a decade of waiting for this, I think it might be time to start calling this vaporware.” Thoughts?

If anyone has a better proposal, I’m all ears.

You work for Google, which has a widely deployed browser, a mobile operating system, and massive web properties. Do your employers require you to align specifications to their business objectives or otherwise influence your specification decisions?

No, quite the opposite. When I started, I was given very explicit instructions to the effect that I should put the Web’s long-term interests ahead of any of Google’s short-term interests.

Having said that, of course, one of the reasons I wanted to work for Google is the unique perspective one can get from working here and from having access to the data Google has. There’s no question that that has influenced my decisions.

Do you have other duties apart from specification?

I basically work on the HTML spec full-time, but yes, I have some other duties internally.

Is the Web Platform becoming too complex (Web Components, shadow DOM, etc.)?

Too complex for what?

For the amateur with something to say, rather than professional coder? Or new entrants — e.g., Geri Coady’s Pastry Box article?

The platform has been too complex for any one person to fully understand for a long time already. Heck, there are parts of the Web platform that I haven’t even tried to grok — for example, WebGL or IndexDB — and parts that I continually find to be incredibly complicated despite my efforts at understanding them — like the Unicode bidirectional text algorithm or the subtler aspects of JavaScript’s prototype model. I’m pretty sure most authors don’t understand the precise details of margin collapsing in the presence of floats and divs with clear set, or the inline box model.

This isn’t surprising, though. If you define the “Windows” platform as everything from the NT kernel API to the Direct3D API and everything in between, I’m pretty sure you’d quickly come to the conclusion that nobody understood that whole platform either.

I don’t think this is a problem.

The WHATWG began because the W3C told you, “HTML was dead. If you want to do something like HTML5, you should go elsewhere.” Now that the W3C has come to its senses, is it time for the WHATWG to hang up its spurs and for its participants to work inside W3C to continue the development of the web platform?

We tried (2007–2012). It didn’t work out. In fact, we ended up spinning more specs out of the W3C! The WHATWG has about 12 specs spread amongst eight or so editors now.

In what sense didn’t it work out, and why?

We have different priorities, different visions, different approaches. I’m probably not the right person to give an objective answer, though.

You seem to have most of your spats with people who work in the field of accessibility. Why is that?

I don’t know. I wish I did.

You told me, “People with disabilities are just as important to me in my work on HTML5 as is anyone else”, but I guess they would say you don’t pay enough attention to the needs of disabled people (longdesc, table summary, re-writing rules for alt text). Presumably therefore you feel that disabled people are better served by removing these features. What do you base that assumption on?

The premise of the question is that there’s one accessibility community that speaks with one voice and has one opinion, and that they entirely represent the exact homogeneous desires of all disabled people. But none of that is true. There are multiple Web standards accessibility communities. People within those communities often don’t agree with each other. There are lots of disabled people with lots of different opinions and different needs. The accessibility communities don’t always represent all the disabled people’s needs. And so forth.

Taking the specific features you list:

• longdesc="" is a solution in search of a problem, which virtually no author uses, and which those who do use almost entirely use incorrectly, and which therefore users have long ignored. Discouraging its continued use means authors are more likely to spend time on things that are more likely to improve accessibility. Mark Pilgrim, author of “Dive Into Accessibility”, wrote a post about this.
• Table summaries: check out the HTML spec for <table>. The first paragraph says that <table> is for representing tabular data (incidentally discouraging the use of <table> for layout tables, which is good for accessibility). The second paragraph says what tabular data is (a grid). The third paragraph provides a link to the section that defines what the table model is. The fourth paragraph encourages authors to “provide information describing how to interpret complex tables” and links to an entire section describing how to give table summaries. That section has six different suggestions for how to do it.
• Rules for alternative text for images: the section on <img> first says that <img> represents an image, then briefly says that how you give the URL for the image (it goes into more detail for that again later), and then the third sentence points at the section on alt="" — which consists of literally a dozen different subsections on how best to give alternative text for images in a wide variety of cases. When this was first written, it was probably by far the most detailed description for how to write alternative text ever published.

So we didn’t remove two of those three features. We expanded them dramatically. The one feature we removed was really a misfeature, and we have the data to back that up.

What’s been your biggest mistake? What are you most proud of?

I’m probably most proud of the HTML parser specification. Years ago it seemed like such a preposterously absurd task to take on that I said I would never do it. And it was huge (and we’re not quite done yet; there’s at least one major outstanding bug). But this, more than anything, has been the crowning achievement of the HTML spec. We went from a world where four browser engines had four completely different approaches with radically different behaviours in every edge case, to a world where the browsers agree so closely on their behaviour that we have an almost unheard of level of interoperability. There have been academic papers written about it. It’s completely changed how we write parser specifications, and I expect the knock-on effects on other specs will continue for years. It used to be that people said that specs should only define how to parse conforming content and should do so in a declarative fashion. But now saying that sounds hopelessly naive and old-fashioned.

My biggest mistake…there are so many to choose from! pushState() is my favourite mistake, for the sheer silliness of ending up with an API that has a useless argument and being forced to keep it because the feature was so desired that people used it on major sites before we were ready to call it done, preventing us from changing lest we break it. postMessage()‘s security model is so poorly designed that it’s had academic papers written about how dumb I was, so that’s a pretty big mistake. (It’s possible to use postMessage() safely. It’s just that the easiest thing to do is not the safe way, so people get it wrong all the time.) The appcache API is another big mistake. It’s the best example of not understanding the problem before designing a solution, and I’m still trying to fix that mess.

At the less-technical and more-political level, I think taking WebSockets to the IETF was a huge mistake. It ended up delaying the spec for literally a year without any resulting improvements, and they made a number of changes that IMHO reduce the protocol’s security. (Again, it’s possible to use it safely, it’s just not as easy as it was before the IETF got involved. Ironically, they broke the very things we learnt to do right after getting them wrong with postMessage().) We’re still waiting for things like compression and multiplexing, which we would probably have had a long time ago if we hadn’t gone to the IETF.

Also, when I designed the Web Storage API I made a horrible mistake by making the API synchronous and requiring consistency during a script’s execution, which essentially became the one place in the whole Web platform where, in theory, browsers are required to block cross-process. Since browsers don’t implement that, we instead have an API where there’s no consistency guarantee, which is rather scary.

Outside of the HTML spec, one of my biggest mistakes was not realising, back when I was first in the CSS working group, that specifications were not immutable. CSS2 had these vague rules about margin collapsing and about the inline box model which David Baron and I took as essentially immutable constraints around which we were to strictly define the margin collapsing model and the inline box model. We succeeded, in that now the spec has mostly well-defined models for both those things, but boy are they insanely complicated. What we should have done instead is just break the constraints and come up with something simpler, ideally something that more closely matched what browsers implemented at the time.

One of the side-effects of that kind of thinking (not directly my mistake, though I didn’t argue against it as far as I recall) is that we ended up with “Quirks Mode” and DOCTYPE switching. What we should have done is just made the specs match browsers and not bothered with all these modes.

I also made mistakes with the Acid tests, wherein I tested things that the specs required but which in retrospect it would have been better to ignore, which ended up encouraging browsers to implement things that we later realised it would have been better all around if we had skipped. Some of those we were able to mitigate, others not so much. Acid3 had some stuff around SVG fonts that we should have never had. Acid2 had some crazy stuff around SGML comments that we were thankfully later able to totally abandon.

I made a number of mistakes in the development of XBL2 (as mentioned earlier), but since the result of those mistakes was that it’s getting ignored, the only real long-term cost has been the opportunity cost and delay in getting a solution in that space.

I’m sure I’m forgetting some huge mistake I’ve made that everyone is yelling at me for. (I asked for suggestions for this question on IRC, and after we were done enumerating a bunch of mistakes, Anne asked, “That’s a long list. Why do we trust this guy again?” D’oh.)

Urban geek legend has it that you invented Web Sockets because you wanted to control your model trains through the browser and couldn’t. True or false?

Obviously there’s a lot of demand for something like Web Sockets, so it’s not like it was only because I want to control my trains that we worked on that, but it was definitely a key motivating factor for me. Without Web Sockets I was forced to use hanging GETs and all the other techniques people will be familiar with, which introduces precious milliseconds of latency that can be so destructive when you have two locomotives speeding towards each other. I’ve since used Web Sockets in pretty much every non-trivial development project I’ve done.

You specified microdata, which even you dislike, because RDFa was ugly and hard to write…

It’s not so much that I dislike microdata so much as I don’t think the problem microdata (and RDF, etc.) solves is an interesting problem that should be solved. Of course, enough people think it is a problem that should be solved that I approached it like all the other problems. It’s a good example of how the HTML spec is not just a reflection of my wishes.

…The WHATWG shot across RDFa’s bow worked. RDFa Lite now does everything microdata does, while also being compatible with Facebook’s Open Graph Protocol…

RDFa Lite doesn’t do everything microdata does. There’s a number of things that microdata does (or doesn’t do) that are absolutely key:

• not have anything to do with RDF
• not have any support for any prefixing mechanism
• have integration with the drag-and-drop API

There are probably others, too, but I haven’t studied RDFa Lite carefully.

Why is “not have anything to do with RDF” key?

It’s where microdata and microformats get most of their simplicity compared to RDF-based technologies.

…To avoid fragmentation, are you going to withdraw microdata as a spec, add an RDFa API, and use RDFa Lite instead? If not, why not?

Well, at this point microdata is in wide use, so there’s no way to remove it even if we wanted to. But since RDFa still doesn’t solve the same problems, it hasn’t come up.

RDFa (or rather, RDF) and microdata have fundamentally different data models. RDF is a triple (quad, really) database. Microdata represents tree structures. Microdata has more in common with JSON than RDF.

What are your thoughts on angle brackets…

They’re pointy? I don’t know. Are angle brackets something people have thoughts on?

…and how does HTML stand up to JSON? (from @pal_nes)

Different solutions to different problems.

JSON’s missing one major feature that I wish it would get, which is defined error handling (even if it’s only XML-style “you must abandon the parse if it there is an error”). Right now, handling of broken JSON seems to vary from parser to parser.

Other than that, I like JSON and often use it. I think people get very attached to generic syntaxes, though. Sometimes the best syntax is just newline-separated strings in a plain text file. Sometimes it’s a nested tree like JSON. Other times it’s a nested annotated tree like XML. Sometimes it’s a binary bitmap. I think people shy away from defining their own syntaxes more than they should. Writing a parser is easy and is a very, very well studied part of computer science. Using something like JSON makes sense if what you want to serialise is a static JavaScript structure with no cross-references. If your data structure is something else, then using JSON doesn’t generally make more sense than using a dedicated format — either way, you’re going to have to get the data out and piece it back together into your own internal representation.

Also, often when people define generic syntaxes, they go a bit crazy. When you’re defining a dedicated format (or a vocabulary for a generic format, same thing really), you usually don’t have time to go crazy and define wild features, because your motivation is to solve your original problem and designing the language is a necessary evil, not the end goal.

Is it a problem if people have no markup in the <body> and generate the DOM with script?

It’s obviously a problem for users who have scripting disabled, but other than that, it’s just an authoring choice.

There are significant advantages to having a static description of markup. You can validate it, for example, to catch semantic errors (such as accidentally putting an <input> in a <select> instead of using <option>). HTML these days has several features to make it easier to do this while writing a Web app — e.g., hidden="", DOM cloning, etc.

But equally there are advantages to generating things from script. For one, if you want to generate several instances of something, right now the easiest way is to describe the structure in JavaScript calls with the data you want to substitute into your template being right there.

Personally, when I write Web apps (mostly games), I tend to use static HTML for the parts of the app that don’t change or that only appear once, and JavaScript calls to generate the parts that appear more than once. For example, one of the games I’m working on has a list of maps, and so the <ol> for the list is hard-coded in the HTML, but the <li>s are generated dynamically.

Talking of script, what do you think of DART?

I haven’t studied it (or the newer JS proposals, for that matter) enough to have an opinion. If it’s intended to replace JavaScript as the Web’s language, they have an uphill battle ahead of them, though. Replacing any part of the Web is extremely hard.

I wrote about the difficulty of replacing the whole Web last year. Replacing any part of the Web (as opposed to extending it) is similar in difficulty, though on a proportionally smaller scale.

How do you think the long-term development of devices and interaction models will impact the development of web standards? (from @wcagtest)

I don’t think it’ll affect the development at all. There’s no difference between new interaction models and any other new feature. The Web and Web standards themselves will obviously be impacted, but I have no idea how. I’m fascinated to find out how the Web will evolve in the face of projects like Google’s Glass or devices like the Pebble.

I am sad that the Web didn’t handle small screens — and later, touch UI — that well. I would’ve hoped that the Web’s media-independent nature would have made that work better. For small screens, honestly, I mostly blame Web designers for assuming big screens and not thinking flexibly. We’re seeing that change now. For touch, though, I wish we had done a better job of mapping the UI to the Web’s generic events. A touch gets mapped to a “click” event easily enough, but drag-and-drop never got mapped, pinch gestures didn’t get mapped to wheel events, etc. Mainly I think this is because the first truly successful touch browser set the standard, and it was developed mostly in secret with a small team many of whom, as I understand it, weren’t Web veterans.

Will native apps triumph over the Web on mobile devices?

Native platforms and the Web have very different characteristics. The Web is by design radically vendor-neutral, and (to a lesser extent in practice) device-neutral. This has huge benefits: nobody can single-handedly kill the Web, for example. If you write a Web page or application today, and then tomorrow your desktop operating system vendor or your mobile phone handset vendor goes bankrupt, you can just buy another device and your page still works. If you target a proprietary platform — e.g., Amiga or OS/2 — that then loses the support of its vendor, the result is that your application is no longer usable.

The cost of having a system immune from the whims of a single vendor is that by and large, innovation doesn’t happen in multi-vendor discussions. If you have a proprietary platform, it’s easy to add features to it: you just do it. No need to argue with anyone. On the Web, a feature can only be added if every major implementor agrees it’s worth adding, and that usually only happens once it’s been proven in a native platform. So native platforms have the edge when things are rapidly innovating.

This is why the mobile world today has so much focus on native apps. Every new generation brings radical new features, and the Web will always be behind on those. So the cutting edge is native.

You can see this on the desktop. Innovation on desktop operating systems has slowed down dramatically, and as a result the Web has been able to mature there. The result is that on desktop, Web apps are doing great (so great that it’s viable to create a desktop OS that does nothing but bring up a Web browser, in fact). Mobile is where desktop was a decade or two ago, in terms of innovation.

What’s the biggest danger to a free, open Web at the moment?

Patents.

What’s the very next thing on your to-do list?

The top thing on my bugs list is “Spec for document.open() doesn’t match reality when the parser is script-created”. That sounds like a hard one. Let’s see…top thing on my e-mail pile right now is…some even harder stuff do with the HTML parser and feedback from [Boris Zbarsky] about some very subtle aspects of the security implications of certain DOM APIs. Yikes. Maybe I’ll do lunch instead…

Related Posts:

• Interview with Robin Berjon, HTML5 editor
• Interview with Steve Faulkner: HTML5 editor and new doctor
• HTML5: briefing notes for journalists and analysts
• HTML as a Living Standard — For and Against
• HTML5 for Web Developers

Interview with Ian Hickson, HTML editor originally appeared on HTML5 Doctor on January 8, 2013.

]]> http://html5doctor.com/interview-with-ian-hickson-html-editor/feed/ 25 http://html5doctor.com/interview-with-ian-hickson-html-editor/ http://feedproxy.google.com/~r/html5doctor/~3/r5xWDAS8N6w/ http://html5doctor.com/review-pro-html5-accessibility-by-joshue-o-connor/#comments Tue, 11 Dec 2012 10:00:48 +0000 Bruce Lawson http://html5doctor.com/?p=4830 Pro HTML5 Accessibility is an exhaustive book. Author Joshue O Connor is senior accessibility consultant with National Council for the Blind of Ireland’s Centre for Inclusive Technology and a stalwart of many W3C working groups.

Don’t be afraid of the title. The book doesn’t assume that you’re a professional accessibility expert – quite the opposite; the first 100 pages don’t really deal with HTML5 at all, but survey the landscape of disability, assitive technologies and W3C WAI-ARIA. The last chapters of the book usefully survey testing methodologies and tools which will be invaluable to the lone developer told “oh, and it must be accessible/ DDA-/508-compliant, too”.

Joshue does an admirable job of explaining how to use HTML5/ARIA to make sites accessible, and gives a thorough overview of how current browsers communicate new widgets (date pickers, sliders, video controls etc) to assistive technology now, rather than in some glorious unspecified future.

He writes engagingly, too: “Remember that the <div> and <span> elements are semantically neutral elements. They have no meaning, poor things, and are merely empty hooks—ciphers for you to do with what you will. They cheer up to no end when you give them meaning. Existential crisis averted!”

I also appreciated Joshue’s pragmatism: “Good semantics are really important, but real-world accessibility is very nuanced—particularly for new content and element types. However, bear in mind that an unencoded ampersand (which will throw a validation error) never resulted in an inaccessible webpage.”

However, I didn’t understand “Having some heading structure, rather than none, on a web document is far more important than merely ensuring the headings are ordered in the correct way.” Surely “merely ensuring the headings are ordered in the correct way” is exactly the same as “having some heading structure rather than none”?

It’s also unclear to me why the author chose to markup buttons to control a video player as

 
<div id="back" tabindex="0">
<img src="player/back_button.png" role="button" alt="Jump Back" />
</div>

rather than simply use a <button> element which by default has a role of button and is focussable. But it doesn’t much matter; it gets the job done.

There are some errors which the technical editor should have picked up. Chapter 3 says “JavaScript has some event handlers that can be activated only by using the mouse, such as onClick”, which isn’t strictly true. The same chapter also says “IE 9 doesn’t support the <video> element”, which is just wrong: it does. A cursory code-test would have shown that chapter 5′s example <img scr="myserver/usful_andgroovy_image.png"> won’t work, as there is no scr attribute (it’s obviously a typo for src).

The most significant failing of the book isn’t the author’s fault: it’s the lack of love for presentation that I’ve found endemic in all Apress books lately. For example, the tables in chapter 5 could easily have been formatted for a more attractive presentation, but they look exactly as a basic Word document. Similarly, the multi-page bulleted lists could easily have been a single, multi-column page.

It looks as if Apress just doesn’t care about quality, which is incomprehensible from a publisher. In a publishing environment where ebooks have advantages such as portability, searchability, updateability in case of errors, dead-tree publishers need to work hard to ensure their products remain competitive. They need to play to the traditional strengths of print: beautiful layouts, colours, good design and high-quality paper. We see these in books from Five Simple Steps, Smashing Magazine and A Book Apart. I’ve only seen a PDF of this book, but a previous physical Apress book I own has a paper quality redolent of 1970s East German toilet paper. Certainly Apress has expended no effort at all to lay out the pages for a pleasant read.

That rant aside, the content of this book will be invaluable to a developer new to the world of accessibility, trying to use modern web standards.

Related Posts:

• Review: HTML5 Designing Rich Internet Applications
• Review: HTML5 Multimedia: Develop and Design
• Reviewing HTML5 for Web Designers
• HTML5 Doctor Resources
• Review: The Truth About HTML5 For Web Designers

Review: Pro HTML5 Accessibility by Joshue O Connor originally appeared on HTML5 Doctor on December 11, 2012.

]]> http://html5doctor.com/review-pro-html5-accessibility-by-joshue-o-connor/feed/ 10 http://html5doctor.com/review-pro-html5-accessibility-by-joshue-o-connor/ http://feedproxy.google.com/~r/html5doctor/~3/-3n4CEK4L_A/ http://html5doctor.com/taking-web-audio-offline-in-ios-6-safari/#comments Tue, 27 Nov 2012 13:30:20 +0000 Alex Gibson http://html5doctor.com/?p=4812 Playing cached audio for offline use on iOS Safari has long been a challenge that has proved to be mission impossible. But with the advent of the (WebKit-only) Web Audio API, it is now finally achievable — although you still need to jump through a few hoops.

The bad news is that you still can’t cache an MP3 file using Application Cache and then simply load it using an XmlHttpRequest. Safari on iOS 6 will cache the MP3 but then refuse to play it and fail silently (how useful!).

But all is not lost…

Base64 to the Rescue #

Because the Web Audio API offers developers direct control over the AudioBuffer, you can now convert data formats on-the-fly and feed them directly to the Web Audio API for playback. For example, if you encode an MP3 file as a Base64 string, you can then decode it to an ArrayBuffer and convert the raw audio data.

Encoding an Audio File #

You can easily convert an MP3 file to a Base64 string using OpenSSL. If you are on Mac OS X, it comes pre-installed, so just open up Terminal.app and type the following command:

openssl base64 -in [infile] -out [outfile]

Make sure to replace [infile] with the path to your MP3 and [outfile] with your chosen destination for the encoded data.

This will output a Base64-encoded string representation of your sound file. You can then cache the string using any form of web storage you choose (e.g., Application Cache, localStorage, or webSQL).

Base64 to ArrayBuffer #

In order to decode the Base64 string back into an ArrayBuffer, you’ll need to use a custom method. Check out Daniele Guerrero’s base64-binary.js as a good script that can be used exactly for this purpose. It decodes a Base64 string into a Uint8Array typed array and stores it in an ArrayBuffer.

Once this is done, you can simply decode the audio data using the Web Audio API’s decodeAudioData() method:

var buff = Base64Binary.decodeArrayBuffer(sound);

myAudioContext.decodeAudioData(buff, function(audioData) {
  myBuffer = audioData;
});

Once you have the audio data decoded, pass it to your audio buffer source and play the sound:

mySource = myAudioContext.createBufferSource();
mySource.buffer = myBuffer;
mySource.connect(myAudioContext.destination);
mySource.noteOn(0);

Full Demo and Source Code #

Check out the online demo and source code for a complete example of the techniques discussed in this article.

Browser Support #

Currently the demo works in Safari 6, Chrome Desktop, and iOS 6 Safari. The technique has potential to work in any browser that supports Web Audio API, so hopefully Chrome Mobile can soon add support as well.

The W3C is currently pursuing the Web Audio API as a standard.

Related Posts:

• Multimedia Troubleshooting
• Native Audio in the browser
• Go offline with application cache
• Drag and Drop and Automatically Send to the Server
• Server-Sent Events

Taking Web Audio Offline in iOS 6 Safari originally appeared on HTML5 Doctor on November 27, 2012.

]]> http://html5doctor.com/taking-web-audio-offline-in-ios-6-safari/feed/ 5 http://html5doctor.com/taking-web-audio-offline-in-ios-6-safari/ http://feedproxy.google.com/~r/html5doctor/~3/2SDlAnmgzjs/ http://html5doctor.com/interview-with-robin-berjon-html5-editor/#comments Tue, 13 Nov 2012 14:05:26 +0000 Bruce Lawson http://html5doctor.com/?p=4788 At the recent Apps World expo in London, Doctor Bruce spoke on a panel with Robin Berjon, recently appointed W3C HTML5 editor. He took the opportunity to ask Robin some questions on process, living standards and male grooming.

 

Tell us about yourself.

My name is Robin Berjon (@robinberjon, berjon.com) and I live in Paris with wife, daughter, and cat. I’ve been hacking Web and open source stuff since 1996. A little over ten years ago I started becoming involved in standards with the hope of helping make hacking with Web technology as cool as I thought it could be. I hadn’t realised that “as cool as it could be” would be notion prone to evolving so fast over time.

How long have you been editor of HTML5?

Since September, so a touch over two months by now.

But isn’t Hixie editor?

Hixie is the editor of the WHATWG HTML specification; I’m part of the W3C team of HTML editors. Essentially the same source document is used by everyone, but we produce different views on it. The WHATWG view is a single document containing features at varying levels of maturity; the W3C publishes that document as multiple separate specifications and currently focuses on a more stable subset of features.

It’s a big document — there’s room enough for a broad community to collectively figure out the future of HTML.

What does the job entail? Just tidying up and getting tests written? Isn’t that terribly boring?

Our goal is two-fold. First, we are on track to producing a stable snapshot of HTML5 by 2014. The first step in getting there is to produce a draft that is ready for intensive testing, which is the next step in the W3C process. In parallel, we will shortly start publishing drafts on the HTML.next track (also known as HTML 5.1) including a number of new features. This basically corresponds to switching to something that resembles software development best practices in which one can choose either to use a stable release or the nightly build.

Based on the stable snapshot, we will ramp up our testing effort in earnest. To some, testing is a tedious occupation but I beg to differ. With testing, you get to break stuff. And other people’s stuff, too! And those people then thank you for it. Remember all that time spent working around browser bugs? Well with specification testing you get to turn that around, find the bugs instead of avoid them, and then wait as the browser vendors fix them. It’s Web developer payback time!

And there’s a host of things to be done for HTML 5.1 such as fixing AppCache (with our friends from WebApps) or evaluating the various proposals for responsive images. There’s no point in waiting for a finished specification to start work on the next one, and one thing that I find particularly exciting is that a lot of the novel stuff is exciting tech that’s brought to us by the community.

It’s not all just mopping up, though, is it? You’re already looking at new features. For example, W3C is considering <picture> element; WHATWG isn’t. Is there a danger of differing specs for the same markup language?

I’m not really worried about differing specifications because there’s a reality test: what’s really implemented out there? If you have two specifications saying different things about the same feature, and that feature happens to be reasonably reliably implemented, then one of those specifications is wrong. And it’s pretty hard to stay relevant while being wrong.

I would actually like to see more variation in input rather than less. It can be rather daunting for a group of Web people who care a lot about one specific feature to start contributing to any standards group. A lot goes on there, there tends to be a fair bit of email, the mailing list’s culture can be hard to grasp even if it’s not downright aggressive. This puts a high bar on such contributions, high enough that it is too rarely turned into a reality.

At the same time, it is difficult for even seasoned Web hackers to draft specification text without input from browser vendors and experienced standardistas, which in turn can lead to frustration as carefully crafted and nurtured work is turned down.

So we need to figure out how to make this type of group working on a specific improvement work more easily, more often. We already have a lot of the technical infrastructure with Community Groups, but getting the human bits to work is always the hardest part. I think that the work going on in the Responsive Images Community Group is a truly great experiment (even if it means occasional drama) and that the experience they are building up will serve to guide a lot of subsequent groups working in a similar fashion.

I bring this up because successful open projects are those that can keep bringing in new contributors over time. The Web standards community as a whole needs to do a better job there — and we will! So no, I’m not worried about differing specs. So long as we can figure out how to get all the browsers on the same page one way or another, the more input the sexier.

I recall someone saying that 20,000 test cases will be needed? That’s a lot – how are you going to do it all?

It’s probably a fair bit more than 20,000 since we already have over 11,000 and aren’t anywhere near satisfied yet. But the exact number is not as important as the fact that the number will be big. In order to pull this off, it would be tremendously helpful to benefit from broad community involvement.

And as it happens, that’s precisely something that’s been ramping up. You’re of course familiar with Move The Web Forward, the grassroots movement that’s pushing for a better Web. A part of that is Test The Web Forward. It’s a series of events specifically dedicated to making the Web a better place for all through testing. There was a first event in San Francisco last summer, and we’ve just recently had one in Beijing this week, and another in Paris. The TestTWF folks are looking into more events in other locations, so if you’re interested in having one in your city make your voice heard.

What happens there is that we kick off with a few presentations to explain how testing works, and then we all get our hands dirty in a hackathon with ample help from testing experts. For developers it’s a
great way to learn more about Web technologies and to get involved in a project that gives back to the Web. Plus: payback!

I was at the Paris TestTWF a couple weeks ago, and I have to say that I’ve been overwhelmed with how good the participants were. The turn-out was great, and people there just showed up, asked great questions, and immediately started crunching on tests. It’s not as if I didn’t already know that the Web community rocks, but it’s still amazing to see just how much people care and how dedicated so many are to improving the Web.

The w3c has “chopped up” HTML into modular specs; WHATWG hasn’t. Why?

A lot of people, including spec reviewers, test writers, and implementers have told us that they find it easier to handle smaller specifications because they’re easier to swap into one’s brain, and because you can more easily have someone work on a well-defined area. I think that Tim Berners-Lee explained it well a few years ago.

Of course, a lot of the Web platform is intricately meshed together so that cutting things into smaller pieces can be difficult, and at times risks hiding vital information. This is particularly true of existing features; for new features we certainly intend to try hard to make things as modular as possible. That’s why we expect a lot of the new features developed in the HTML WG to be created as extension
specifications. This does not mean that they have lesser status that the “core” HTML specification, rather it becomes a logical, modular way of adding new functionality. It also makes it easier for third parties, such as smaller, more focused communities or even individuals with a good ideas, to provide very concrete input that can more readily be reviewed by the group. Great examples of this include the Responsive Images work or the <main> element.

At the end of the day a lot of it boils down to taste, or perhaps more importantly to how your work in relation to those specifications is organised. If you’re working on all of it at once, it may be simpler to keep it all in one place; but if you’re trying split work off in a larger team you might prefer some predefined boundaries between documents. At least that’s the impression I get from the input people provide whenever this topic crops up. As far as I’m concerned I find that the extension specification model is more conducive to community contributions and so it definitely has my preference.

Why do we need W3C snapshots and versions, instead of a “living standard”?

It’s a big Web out there and a lot of people are involved in it in different ways. Again, whether you prefer snapshots or the bleeding edge document likely depends on what you’re doing with it. If you’re continuously working on and with the spec, producing snapshots is a drag. At the other end of the spectrum if you’re burning the implementation into silicon and you need to interoperate with others who are doing the same, you want something that’s almost literally carved in stone. In between those extremes, the specifics of your situation as a user of the spec will make you fall on either side of the fence.

One of the notable costs of a document that changes continuously is that for any work you do with it you need to track it with equal continuity, which can be quite taxing. In order to enable more loosely coordinated work on improving the Web platform, producing snapshots (e.g. for test writing or implementing) can help a fair bit.

It’s important to notice that stability is important for legal reasons: companies like to know what their commitments are and what others have committed as well. W3C’s Royalty-Free patent policy helps ensure that these commitments make it possible for anyone to implement Web standards without paying royalties. Snapshots help us keep the Web free.

That’s why we’re working on making both possible in parallel. The setup we’ve progressively been putting together enables us to have a continuously updated document and snapshots taken from it at regular intervals. This just might be one of those cases in which we can actually make everyone happy.

You’ve put the HTML spec on github. Why?

We wanted to go with git anyway since its branching features are a great match for the approach we’re taking in which we have a stable branch that is used to produce snapshots and a more advanced branch into which new features go.

If you mix that with our desire to involve the community more in the standards process, then GitHub was the logical choice: that’s where our community is.

Do you communicate much with WHATWG? Some of them aren’t great fans of W3C.

Several of us hang out permanently on the #whatwg channel, and on the WHAT’s mailing lists. I can’t say that it has been anything other than friendly and pleasant.

Some people in the WHAT community have criticism of how the W3C operates. A lot of that criticism is constructive, and I am more than happy to relay it inside. W3C has a long history of doing the right thing with respect to opening up the standards process (e.g. with its RF policy or working in public). I’m confident that the consortium will continue in this vein, even if it can occasionally take time for some things to change.

And on the rare occasions when such criticism veers towards trolling, everyone’s experienced enough with online discussion not to bite.

Is it time for Hixie et al to disband WHATWG and return HTML to the W3C fold, now they’ve won?

You’d really have to ask them that!

The WHATWG has certainly done an astounding job of bringing HTML back to life and making it the biggest blip on anyone’s radar. I don’t think that that necessarily entails that it should close shop just yet, if ever. As I said, I believe we should ideally have more decentralised work on improvement, not less — even if it’s difficult.

Is it true that Tim Berners-Lee comes to you for tips on male grooming?

I can’t possibly disclose the list of those who come to me for advice, but it is certainly true that since my breakthrough feature in GQ France an increasing number of Web hackers have been asking how to approach the ruggedly handsome magnetism of these roguish good looks.

Thank you very much Robin. (Evidence of Robin’s “ruggedly handsome magnetism” may be seen in his TPAC dance-off.)

Related Posts:

• Interview with Steve Faulkner: HTML5 editor and new doctor
• HTML as a Living Standard — For and Against
• Interview with Ian Hickson, HTML editor
• HTML5 for Web Developers
• HTML5 adaptive images: end of round one

Interview with Robin Berjon, HTML5 editor originally appeared on HTML5 Doctor on November 13, 2012.

]]> http://html5doctor.com/interview-with-robin-berjon-html5-editor/feed/ 7 http://html5doctor.com/interview-with-robin-berjon-html5-editor/