Mike runs through the history of Flash. Those who forget the history of the web are doomed to repeat it:
The struggle now seems to be turning to native apps versus non-native apps on the mobile platform. It is similar to Flash’s original battle ground: the argument that the Web technology stack is not suitable for building applications with a polished user-experience.
I just noticed that I’m mentioned in the acknowledgements of this most handy of W3C documents. This pleases me disproportionately.
A history lesson and a love letter to the early web, taking in HTML, Photoshop, and the web standards movement.
Those were long years, the years of drop-shadows. Everything was jumping just slightly off the screen. For a stretch it seemed that drop-shadows and thin vertical columns of text would define the web. That was before we learned that the web is really a medium to display slideshows, as many slideshows as possible, with banner ads.
Paul Ford’s potted history of web standards, delivered in his own inimitable style.
Reading through the standards, which are dry as can be, you might imagine that standardization is a polite, almost academic process, where wonks calmly debate topics like semicolon placement. This is not the case.
This is hilarious …for about two dozen people.
For everyone else, it’s as opaque as the rest of the standardisation process.
HTML5 is now a W3C recommendation. Here’s what a bunch of people—myself included—have to say about that.
A collection of device APIs—which, despite the title, are all JavaScript, not HTML. Each API in the list has a link to its spec, an explanatory article, a demo, and the current level of support.
Great suggestions from Dave for podcasters keen on allowing easier sharing.
Oh, how I wish Soundcloud would do this and be less of an audio roach motel!
The definition of the cite element (and the blockquote element) has been changed for the better in HTML5 …at least in the W3C version anyway.
The semantics of the cite element are up for discussion again. Bruce, like myself, still thinks that we should be allowed to mark up names with the cite element (as per HTML 4), and also that cite elements should be allowed inside blockquotes to indicate the source of the quote.
Let’s pave that cowpath.
A great post by Stuart on the prospect of DRM-by-any-other-name in HTML.
The argument has been made that if the web doesn’t embrace this stuff, people won’t stop watching videos: they’ll just go somewhere other than the web to get them, and that is a correct argument. But what is the point in bringing people to the web to watch their videos, if in order to do so the web becomes platform-specific and unopen and balkanised?
I’m a big fan of the placeholder attribute introduced in HTML5. In my book, I described the cowpath it was paving:
- When a form field has no value, insert some placeholder text into it.
- When the user focuses on that field, remove the placeholder text.
- If the user leaves the field and the field still has no value, reinstate the placeholder text.
That’s the behaviour that browsers mimicked when they began implementing the native placeholder functionality. I think Opera was first. Now all the major browsers support it.
But in some browsers, the details of that behaviour have changed slightly. In Chrome and Safari, when the user focuses on the field, the placeholder text remains. It’s not until the user actually begins to type that the placeholder text is removed.
Now, personally speaking, I’m not keen on this variation. It seems that I’m not alone. In an email to the WHATWG, Markus Ernst describes the problems that he’s noticed in user-testing where users are trying (and, of course, failing) to select the placeholder text in order to delete it before they begin typing.
It seems that a relevant number of users do not even try to start typing as long as the placeholder text remains visible.
But this isn’t so clear-cut. A quick straw poll at the Clearleft showed that opinions were divided on this. Some people prefer the newer behaviour …however it quickly became apparent that the situations they were thinking of were examples of where placeholder has been abused i.e. attempt to act as a label for the form field. In that situation, I agree, it would definitely be more useful for the labelling text to remain visible for as long as possible. But that’s not what placeholder is for. The placeholder attribute is intended to show a short hint (such as an example value)—it should be used in addition to a label; not instead of a label. I tend to use example content in my placeholder value and I nearly always begin with “e.g.”:
<label for="fn">Your Name</label>
<input id="fn" name="fn" type="text" placeholder="e.g. Joe Bloggs">
(Don’t forget: generating placeholders from datalists can be a handy little pattern.)
So if you’re using placeholder incorrectly as a label, then the WebKit behaviour is probably what you want. But if you’re using placeholder as intended, then the behaviour in the other browsers is probably more desirable. If you want to get Safari and Chrome to mimic the behaviour of the other browsers, here’s a handy bit of CSS (from that same thread on the WHATWG mailing list):
[placeholder]:focus::-webkit-input-placeholder {
color: transparent;
}
You can see that in action on search forms at The Session for recordings, events, discussions, etc.
Now, if you do want your label—or input mask—to appear within your form field and remain even when the user focuses on the field, go ahead and do that. Use a label element with some CSS and JavaScript trickery to get the effect you want. But don’t use the placeholder attribute.
The inclusion of a main element in HTML has been the subject of debate for quite a while now. After Steve outlined the use cases, the element has now landed in the draft of the W3C spec. It isn’t in the WHATWG spec yet, but seeing as it is being shipped in browsers, it’s only a matter of time.
But I have some qualms about the implementation details so I fired off an email to the HTML working group with my concerns about the main element as it is current specced.
I’m curious as to why its use is specifically scoped to the body element rather than any kind of sectioning content:
Authors must not include more than one
mainelement in a document.
I get the rationale behind the main element: it plugs a gap in the overlap between native semantics and ARIA landmark roles (namely role="main"). But if you look at the other elements that map to ARIA roles (header, footer, nav), those elements can be used multiple times in a single document by being scoped to their sectioning content ancestor.
Let’s say, for example, that I have a document like this, containing two header elements:
<body>
<header>Page header</header>
Page main content starts here
<section>
<header>Section header</header>
Section main content
</section>
Page main content finishes here
</body>
…only the first header element (the one that’s scoped to the body element) will correspond to role="banner", right?
Similarly, in this example, only the final footer element will correspond to role=”contentinfo”:
<body>
<header>Page header</header>
Page main content starts here
<section>
<header>Section header</header>
Section main content
<footer>Section footer</footer>
</section>
Page main content finishes here
<footer>Page footer</footer>
</body>
So what I don’t understand is why we can’t have the main element work the same way i.e. scope it to its sectioning content ancestor so that only the main element that is scoped to the body element will correspond to role="main":
<body>
<header>Page header</header>
<main>
Page main content starts here
<section>
<header>Section header</header>
<main>Section main content</main>
<footer>Section footer</footer>
</section>
Page main content finishes here
</main>
<footer>Page footer</footer>
</body>
Here are the corresponding ARIA roles:
<body>
<header>Page header</header> <!-- role="banner" -->
<main>Page main content</main> <!-- role="main" -->
<footer>Page footer</footer> <!-- role="contentinfo" -->
</body>
Why not allow the main element to exist within sectioning content (section, article, nav, aside) the same as header and footer?
<section>
<header>Section header</header> <!-- no corresponding role -->
<main>Section main content</main> <!-- no corresponding role -->
<footer>Section footer</footer> <!-- no corresponding role -->
</section>
Deciding how to treat the main element would then be the same as header and footer. Here’s what the spec says about the scope of footers:
When the nearest ancestor sectioning content or sectioning root element is the
bodyelement, then it applies to the whole page.
I could easily imagine the same principle being applied to the main element. From an implementation viewpoint, this is already what browsers have to do with header and footer. Wouldn’t it be just as simple to apply the same parsing to the main element?
It seems a shame to introduce a new element that can only be used zero or one time in a document …I think the head and body elements are the only other elements with this restriction (and I believe the title element is the only element that is used precisely once per document).
It would be handy to be able to explicitly mark up the main content of an article or an aside—for exactly the same reasons that it would be useful to mark up the main content of a document.
So why not?
A recent simplequiz over on HTML5 Doctor threw up some interesting semantic issues. Although the figure element wasn’t the main focus of the article, a lot of the comments were concerned with how it could and should be used.
This is a subject that has been covered before on HTML5 Doctor. It turns out that we may have been too restrictive in our use of the element, mistaking some descriptive text in the spec for proscriptive instruction:
The element can thus be used to annotate illustrations, diagrams, photos, code listings, etc, that are referred to from the main content of the document, but that could, without affecting the flow of the document, be moved away from that primary content, e.g. to the side of the page, to dedicated pages, or to an appendix.
Steve and Bruce have been campaigning on the HTML mailing list to get the wording updated and clarified.
Meanwhile, in an unrelated semantic question, there was another HTML5 Doctor article a while back about quoting and citing with blockquote and its ilk.
The two questions come together beautifully in a blog post on the newly-redesigned A List Apart documenting this pattern for associating quotations and authorship:
<figure>
<blockquote>It is the unofficial force—the Baker Street irregulars.</blockquote>
<figcaption>Sherlock Holmes, <cite>Sign of Four</cite></figcaption>
</figure>
Although, unsurprisingly, I still take issue with the decision in HTML5 not to allow the cite element to apply to people. As I’ve said before we don’t have to accept this restriction:
Join me in a campaign of civil disobedience against the unnecessarily restrictive, backwards-incompatible change to the cite element.
In which case, we get this nice little pattern combining figure, blockquote, cite, and the hCard microformat, like this:
<figure>
<blockquote>It is the unofficial force—the Baker Street irregulars.</blockquote>
<figcaption class="vcard"><cite class="fn">Sherlock Holmes</cite>, <cite>Sign of Four</cite></figcaption>
</figure>
Or like this:
<figure>
<blockquote>Join me in a campaign of civil disobedience against the unnecessarily restrictive, backwards-incompatible change to the cite element.</blockquote>
<figcaption class="vcard"><cite class="fn">Jeremy Keith</cite>, <a href="http://24ways.org/2009/incite-a-riot/"><cite>Incite A Riot</cite></a></figcaption>
</figure>
You’re probably doing each of these already but just in case your’e not, Andy has listed six quick wins you can get from HTML5.
Bruce takes a look at the tricky issue of styling native form controls. Help us, Shadow DOM, you’re our only hope!
A good explanation of HTML5’s sectioning content and outline algorithm.
Bruce sits down for a chat with Hixie. This is a good insight into the past and present process behind HTML.
Tantek has put together a wiki page to document the arguments for and against adding a new “main” element to HTML.
A really nice explanation by Todd Kloots of Twitter’s use of progressive enhancement with Ajax and the HTML5 History API. There’s even a shout for Hijax in there.