HTML5 is a technology that is all the rage in the web world with a great potential to considerably ease the process of video playback, enhance the web application user interface and boost the offline or online synchronization of web applications. video plug-ins. You can find so many websites over the World Wide Web that …

7 best html5 jquery video plug-ins Read More »

Listen to this week's news roundup (January 30, 2012) I really should have named today's update "Planes, Trains and Automobiles", since those were all involved with my commute this unusual morning! This week's podcasts is surely enough recorded from SFO Airport, so I hope you enjoy the atmosphere and the ...

FlipHTML5 has released a free AI ebook generator, designed to enable everyone to create, publish, and share quality ebooks.

Before we start, let’s have a brief introduction on HTML5 framework. A HTML5 mobile application is a web page or series of web pages...

TikTok wants to determine its users’ appetite for mobile gaming with the launch of “mini-games” that can be played inside the social video app and discovered through creators’ videos. TechCrunch learned and has now confirmed TikTok’s new gaming pilot quietly launched just weeks ago with a variety of new partners, including game developers Vodoo, Nitro […]

© 2024 TechCrunch. All rights reserved. For personal use only.

See it on GitHub! View it on npm! This release was kicked off because of Gulp 5. Gulp 5 has breaking changes so we had to work through the upgrade manually. In the process of doing that upgrade we discovered a couple of bugs. Christian Oliff noticed that tests were failing on Windows I noticed […]

The HTML5

One of the lesser known HTML5 JavaScript goodies is the document.head DOM tree accessor, which is a more efficient (and easier to type) alternative to document.getElementsByTagName('head')[0]. Native support for document.head is very easy to detect…

I was asked to give an introductory talk on HTML5 for the latest Adobe User Group Belgium Web SIG Event. The presentation I ended up with is entitled “HTML5: It goes to ELEVEN” and can be viewed on Slideshare. In this article, I’ll try to write down some of the things I talked about.

A while ago, I was wondering how exactly one triggers HTML5’s XML mode — let’s call it XHTML5 from now on. You know, just out of curiosity. I’ll always prefer HTML over XHTML because it’s much less verbose and I like to keep things simple.

One of the more subtle yet awesome changes that HTML5 brings, applies to the id attribute. I already tweeted about this a few months ago, but I think this is interesting enough to write about in more than 140 characters.

This site has been set up to explore the possibilities of using HTML5 with CSS.

Re-coding and styling the 'oneBox' to make use of the html5 support for tabindex and :focus on any element.

Using 'Swiper' with html5 'picture' element to change the images depending on the browser window size, and update parameters.

Using html5 to use four diferent images depending on browser window size. Suitable for all modern browsers.

The State – Sort of – of HTML5 Audio Scott Schiller discusses the high level of hype around HTML5 and CSS3. The two specs render ”many years of feature hacks redundant by replacing them with native features,” he writes in an insightful blog. Blogging, he says: CSS3’s border-radius, box-shadow, text-shadow and gradients, and HTML5’s <canvas>, Read the rest...

WinJS is a JavaScript framework for Windows 8, and David Rousset uses it here to create a quick RSS reader. He shows how in a tutorial series. This first article shows the way to build a welcome screen that employs WinJS ListView control. Blend and CSS3 are employed. The second tutorial shows work on the Read the rest...

HTML5 is the fifth version of the World Wide Web Hypertext Markup Language (HTML). HTML5 accessibility is a work in progress with many details still under development.

  We are gearing up for two of the biggest shows of the year: Game Developers Conference (GDC) in San Francisco and Mobile World Conference (MWC) in Barcelona, Spain - both the week of March 2. Come loo...

Before we start, let’s have a brief introduction on HTML5 framework. A HTML5 mobile application is a web page or series of web pages...

A quick Google search will yield plenty of handy autocomplete plugins — there’s even an option shared by jQuery UI which comes bundled with the library. However today I want to look into an alternative solution. The jQuery Autocomplete plugin released by DevBridge has the exact functionality that I find most appealing. The styles will […]

Mobile app interfaces have been utilizing on/off sliding switches for a while. These are most commonly found on the settings page where users can update preferences for their account. But web designers have taken notice and have built many open platforms to generate your own on/off switch sliders. In this tutorial I want to look […]

Preston, Scott, 1969-

Grannell, Craig

Delorme, Rick, author

Felke-Morris, Terry, author

Felke-Morris, Terry

Felke-Morris, Terry

Some people knit, others do puzzles, and yet others find calm by colouring. Me, I love pixeling. My computer career started with a super basic computer. It didn’t even have a way to store what I programmed. So, every day, I would write myself a small program that allows me to paint on the screen […]

I’ve had a couple people ask me to link on my blog to my four part video series on HTML5 and video. Currently, it’s a feature on the AdobeTV home page, but I reckon that will be for just a little while. After that, you can link directly to Part 1 (7:18), Part 2 (10:31), [...]

While we’re preparing an upcoming release, I didn’t want the day to go by without mentioning that ten years ago today, HTML5 Boilerplate was released. Here’s the story of the project as we wrote it up a few years ago. The History of HTML5 Boilerplate Sometime in 2009… “Wouldn’t it be great if we created […]

Online Resource

Online Resource

Online Resource

Online Resource

The panelists discuss whether HTML5 and JavaScript can really replace Flash.

This site has been written in HTML5 and used to use WordPress to manage the content. I’ll explain why I used HTML5, describe the structure of the theme templates, and show some of the ways I tried to tame WordPress’s tendency to add mess to the source code.

As this is my personal site I wanted to experiment with using HTML5, CSS3, and WAI-ARIA. All these documents are currently working drafts and subject to change. However, the web documents and applications of the future are going to be written in HTML5 and I wanted to see the benefits of using it to markup static documents. Using CSS 2.1, let alone the CSS3 selectors and properties that some browser vendors have implemented, has many advantages for controlling the presentation of semantically coded documents. For this reason I am not going to avoid using basic CSS 2.1 selectors just to faithfully reproducing this site’s design in IE6. However, I have tried to accommodate IE 7 and IE 8 users by using an HTML5 enabling script so that the new HTML5 elements can be styled in those browsers if users have Javascript enabled.

HTML5 templates

I started with a static prototype of this site developed on my local server. WordPress makes it very easy to create your own templates and, therefore, it is no problem to use HTML5. This theme only has 3 main templates: index, single, and archive. There are of course templates for 404s, attachments, comments, etc., but I won’t discuss them as they are all based on the 3 main templates. All the templates include ARIA roles as an accessibility aide.

The single.php template has this rough structure:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <title></title>
  <link rel="stylesheet" href="default.css">
</head>

<body>
  <header role="banner"></header>
  <nav role="navigation"></nav>
  <article role="main">
    <header>
      <time datetime="YYYY-MM-DD"></time>
      <h1></h1>
    </header>
    <footer></footer>
  </article>
  <nav></nav>
  <aside role="complementary"></aside>
  <footer role="contentinfo">
    <small></small>
  </footer>
</body>
</html>

The first line of the document is the HTML5 DOCTYPE. The new <article> element contains the content of each post. The same structure is used for the index.php template except that there are several articles displayed on each page and the ARIA role value of main is not used. In contrast, the archive.php template houses all the article excerpts in a <section> element with the ARIA role of main because the list of archived posts is itself the main content of the document.

A clean theme

WordPress tends to add classes, elements, and other bits of code in certain places. I haven’t used any of the WordPress functions that add class names to the body and to elements wrapping a post and also wanted to avoid cluttering the source code with any other unnecessary markup. This required a bit of fiddling around with the theme’s functions.php file. I’m not a PHP developer so this might not be pretty!

Removing actions from wp_head()

WordPress has a hook called wp_head that sits in the header.php of most themes. To avoid it inserting unwanted code into the <head> of the document I used the remove_action function to disable the functions that were responsible. The following code was added to the functions.php file of my theme:

// Remove links to the extra feeds (e.g. category feeds)
remove_action( 'wp_head', 'feed_links_extra', 3 );
// Remove links to the general feeds (e.g. posts and comments)
remove_action( 'wp_head', 'feed_links', 2 );
// Remove link to the RSD service endpoint, EditURI link
remove_action( 'wp_head', 'rsd_link' );
// Remove link to the Windows Live Writer manifest file
remove_action( 'wp_head', 'wlwmanifest_link' );
// Remove index link
remove_action( 'wp_head', 'index_rel_link' );
// Remove prev link
remove_action( 'wp_head', 'parent_post_rel_link', 10, 0 );
// Remove start link
remove_action( 'wp_head', 'start_post_rel_link', 10, 0 );
// Display relational links for adjacent posts
remove_action( 'wp_head', 'adjacent_posts_rel_link', 10, 0 );
// Remove XHTML generator showing WP version
remove_action( 'wp_head', 'wp_generator' );

Source: WPEngineer.com: Cleanup WordPress Header

Removing an empty <span>

If you want to create excerpts you can either write them into the excerpt box or use the <--more--> quicktag in the WordPress editor. I just wanted the first paragraph of my posts to be used as the excerpt and so using the in-editor tag was the most practical approach I was aware of. However, when you do this WordPress will insert an empty <span> in the post’s content. This element has an id so that the area following the excerpt can be targeted by “more” or “continue reading” links. I removed both the empty <span> and the jump link by adding the following code to the functions.php file of the theme:

// removes empty span
function remove_empty_read_more_span($content) {
  return eregi_replace("(<p><span id="more-[0-9]{1,}"></span></p>)", "", $content);
}
add_filter('the_content', 'remove_empty_read_more_span');

Source: Ganda Manurung: Remove Empty Span Tag On WordPress

// removes url hash to avoid the jump link
function remove_more_jump_link($link) {
  $offset = strpos($link, '#more-');
  if ($offset) {
    $end = strpos($link, '"',$offset);
  }
  if ($end) {
    $link = substr_replace($link, '', $offset, $end-$offset);
  }
  return $link;
}
add_filter('the_content_more_link', 'remove_more_jump_link');

Source: WordPress Codex: Customizing the Read More

Displaying images in the excerpt

For posts that display nothing but a photograph (yes, they will be shit but I’m hoping it gets me using my camera a bit more often) I wanted the image to show up in the archives. Equally, if the first paragraph of a post contained a link I wanted that to be preserved. The default the_excerpt() template tag doesn’t allow for this so it needed some modifying. I added a new function, which is just a modified version of the core excerpt function, to the functions.php file and then made sure that the template tag executed this function rather than the one contained in the core WordPress files.

function improved_trim_excerpt($text) {
   if ( '' == $text ) {
      $text = get_the_content('');
      $text = strip_shortcodes( $text );
      $text = apply_filters('the_content', $text);
      $text = str_replace(']]>', ']]>', $text);
      $text = strip_tags($text, '<p><img><a>');
      $excerpt_length = apply_filters('excerpt_length', 55);
      $words = explode(' ', $text, $excerpt_length + 1);
      if (count($words) > $excerpt_length) {
         array_pop($words);
         array_push($words, '[...]');
         $text = implode(' ', $words);
         $text = force_balance_tags($text);
      }
   }
   return $text;
}
remove_filter('get_the_excerpt', 'wp_trim_excerpt');
add_filter('get_the_excerpt', 'improved_trim_excerpt');

Source: Aaron Russell: Improving WordPress’ the_excerpt() template tag

Conditional next/prev links

I prefer not to have empty elements in the markup and so I needed a way to conditionally insert the “Older entries”, “Newer Entries”, etc., links into templates. The solution I’m using here, which isn’t perfect, is to add this to functions.php:

function show_posts_nav() {
  global $wp_query;
  return ($wp_query->max_num_pages > 1);
}

Source: Eric Martin: Conditional navigation links in WordPress

And then to wrap the navigation markup in the templates with the following:

<?php if (show_posts_nav()) : ?>
<nav>
   <ul>
      <li><?php next_posts_link('&#171; Older Entries') ?></li>
      <li><?php previous_posts_link('Newer Entries &#187;') ?></li>
   </ul>
</nav>
<?php endif; ?>

Summary

It’s fairly easy to create a simple site with HTML5 and to use WordPress to deliver it. At the moment there are issues with Internet Explorer because you cannot style HTML5 elements unless you use Javascript. However, HTML5 redefines the meaning of certain elements (such as <dl>, which has become a more versatile “description list”) and allows block elements to be wrapped in a link. Therefore, there is still benefit in using the HTML5 DOCTYPE even if you do not make use of the new elements.

Further reading

1. HTML5 working draft
2. HTML5 differences from HTML4
3. Accessible Rich Internet Applications (WAI-ARIA) 1.0

In the last few months there has been increased discussion about some of the new elements that have been introduced in the HTML5 draft specification. This entry is primarily a counter argument to some of the comments that I disagree with.

The most recent and high-profile comments in regard to parts of the HTML5 specification come from The HTML5 Super Friends in an article entitled Guide to HTML5 Hiccups. It lays out their concerns with the HTML5 draft specification as it stood at the time of its writing and I am largely going to focus on the issues they have discussed.

The article and section elements

The first argument that I disagree with is that the article and section elements are redundant and, therefore, that the article element should be dropped.

article and section are identical except that article allows a pubdate attribute. We would suggest that article be dropped and section be adapted to allow an optional pubdate attribute or, even better, more explicit metadata.

The article and section elements are not identical according the to HTML5 draft specification. Here is what it says about the section element as of 13 September 2009:

The section element represents a generic document or application section. A section, in this context, is a thematic grouping of content, typically with a heading, possibly with a footer.

Now contrast that with what it says about the the article element:

The article element represents a section of a page that consists of a composition that forms an independent part of a document, page, application, or site.

An article element is “independent” in the sense that its contents could stand alone, for example in syndication, or as a interchangeable component on a user-configurable portal page.

That is a clear distinction that resists the reading of article and section being “identical”. The article element has a specific purpose: to mark parts of a document that form an independent composition that may be appropriate for syndication. It is a special kind of sectioning element that performs an essential role that is lacking in the semantics of the generic section element. This generic element serves only to thematically group content. That grouping may occur at the document level, within an independent article, or within a footer.

The article element has unique semantics and practical use. There is a fundamental conceptual difference between stand-alone compositions and sections of compositions, documents, or pages and this difference should be recognised and catered for in the specification. Websites regularly employ microformats and you don’t have to look far to see independent compositions currently marked up with class="hentry" or find links to individual blog comments and twitter updates. There is clearly a need for an easy way to define independent compositions and that is met with the introduction of the article element in HTML5.

What may be needed is a stronger clarification and definition of the article element to minimise the potential for this distinction to be overlooked and to highlight the differences from a generic document section.

The hgroup element

The hgroup element is a relatively recent addition to the draft specification. It is defined as serving a fairly specific purpose:

The hgroup element represents the heading of a section. The element is used to group a set of h1–h6 elements when the heading has multiple levels, such as subheadings, alternative titles, or taglines.

The element works to associate headings together so that the highest ranked heading descendant (if present) of the hgroup element is used as its text in document outlines and summary. Other heading descendants are treated as subheadings and are left out of outlines.

The HTML5 Super Friends have this to say about the hgroup element:

We don’t see the added value of this element and would instead add a boolean attribute to the heading element which allows content authors to specify if that particular heading should be included in the outline.

Bruce Lawson has similar concerns and proposes another alternative – removing the need for a wrapping element and defining a new element specifically for marking up subtitles:

I agree that hgroup is clumsy and likely to be misused. Rather than wrap an h1 and its h2 subtitle in hgroup to keep the subtitle out of the outlining algorithm, I would prefer to use

<header>
<h1>My blog</h1>
<subtitle>My wit and wisdom</subtitle>
</header>

as I think that;s easier to understand than a heading-that’s-not-a-heading, and it removes a wrapping element.

I disagree with these criticisms of the hgroup element and consider the proposed alternatives to be more problematic, less intuitive, less flexible, and further removed from the way in which authors currently markup subheadings.

The way that many authors are currently marking up subheadings is by using headings of various ranks and in various orders depending on whether the subheading or qualifying heading needs to appear above or below the main page heading. A subheading is still, conceptually, a heading of sorts and it cannot be accurately marked up with a paragraph or any other currently available element.

Allowing the addition of a boolean attribute to heading elements has several problems.

1. A boolean attribute may be less intuitive for authors than the hgroup element. The hgroup element relies upon and produces an association between all the headings it contains. Since headings and subheadings occur together and derive their meaning from each other, it is semantic to wrap these headings in an element. We know that the highest ranked heading contains the string to be used in the outline and that the other headings serve as ranked subheadings to this primary heading. A boolean attribute is only associated with the element that it is a part of. We can create no association between the element and adjacent elements. This is related to the next issue.

2. The hgroup itself acts as heading content while a boolean attribute would act only to remove headings from the outline. The hgroup element only removes the descendant headings that are those not of the highest rank. The boolean attribute shifts the burden onto the author to decide which headings should be marked for removal from the outline, rather than providing an element to wrap a collection of headings without authors having to be concerned with (or aware of) issues of outlining.

What about Bruce Lawson’s idea for a subtitle element? I believe that, irrespective of the what this element were actually called, it suffers from similar problems to the idea of using a boolean attribute. There is nothing to prevent the use of a subtitle element away from a heading, it creates no association with other elements, and it does not allow for ranking of subheadings.

One of my key points in relation to criticism of the hgroup element is that subheadings draw their meaning from context. A subheading (as opposed to a section heading) is only a sub-heading if it is associated with a higher ranking heading. Remove the higher ranking heading and what was once a subheading is likely to be understood as a heading.

The strength of the hgroup element over the two alternative suggestions I have referenced is that it is the only proposal that defines a subheading as contextual. I think that it is the most intuitive proposal (although perhaps none of them are particularly inuitive) – the name of the element is self-descriptive and encapsulates the contextual relationship and adjacent positioning of its child elements — and matches most closely with the way that subheadings are currently marked up on many websites.

The aside element

The HTML5 Super Friends are of the opinion that the aside element is not worth including in the specification:

The use cases for aside are too limited to warrant its inclusion in the specification. We were also concerned about potentially duplicating content within an aside.

However, the specification itself provides some fairly compelling uses for the element:

The element can be used for typographical effects like pull quotes or sidebars, for advertising, for groups of nav elements, and for other content that is considered separate from the main content of the page.

Authors might use the aside element for their blogrolls, for marking up adverts ranging from google ads on blogs to large banners on enterprise websites, for expanding on themes within an article or providing an extended definition of a term, for pull quotes, and anything else “tangentially related to the content around the aside element, and which could be considered separate from that content”.

Most of these uses would not involve duplication of content. Using the aside element for pull quotes would produce some instances of content duplication. However, this is not really a problem for users who are used to content being duplicated in this way in newspapers and magazines. It would not take much for search engines to adapt to deal with short amounts of duplicate content contained within an aside either. While I appreciate the point about duplicate content I’m not yet convinced that it is actually problematic.

The legend element

The current specification defines the legend element as providing an explanatory caption for the contents of its parent element. The parent element may be a fieldset, figure or details element. However, Remy Sharp‘s article entitled legend not such a legend anymore shows why it is not practical to use legend for the new elements details and figure – because it is not backwards compatible with current browsers and effectively unusable outside of a fieldset because of the inability to style the element.

In this case, forging a new element is most appropriate rather than trying to use an element like label which will only create confusion with little advantage.

Summary

I have discussed my reasons for disagreeing with certain feedback on the HTML5 draft specification. I have yet to be convinced that the article, hgroup, or aside elements should be dropped from the specification because it seems to me that they have necessary uses and advantages over alternatives.

Over the weekend two new HTML5 elements – summary and figcaption – were added to the draft specification. The introduction of summary and figcaption marks the acceptance that new elements are needed to act as captions or legends for the details and figure elements. The addition of the figcaption element finally begins to clear up the difficulty in marking-up figure element captions and looks to cement the place of the figure element in the HTML5 specification. The summary element does much the same for the details element but the very nature of the details element itself means that its future is not yet clear.

The figcaption element

This new element acts as the optional caption or legend for any content contained within its parent figure element.

If there is no figcaption element within a figure element then there is no caption for the rest of its content. If there is a figcaption element then it must be the first or last child of the figure element and only the first figcaption element (should there be more than one child figcaption of the parent figure element) represents a caption.

The figure element is used to mark up any self-contained content that may be referenced from the main flow of a document but could also be removed from the primary content (for example, to an appendix) without affecting its flow. This makes it suitable for various types of content ranging from graphs and data tables to photographs and code blocks.

<p><a href="#fig-ftse">Figure 1</a> shows the extent of the collapse in the markets and how recovery has been slow.</p>

<figure id="fig-ftse">
  <figcaption>Figure 1. The value of the FTSE 100 Index from 1999&ndash;2009.</figcaption>
  <img src="ftse-100-index-graph.jpg" alt="The index hit a record high at the end of 1999 and experienced two significant drops in the following last decade.">
</figure>

<p>This latest financial crisis hasn't stopped Alex from writing music and his latest track is actually worth listening to.</p>

<figure>
  <audio src="what-am-i-doing.mp3" controls></audio>
  <figcaption><cite>What am I doing?</cite> by Alex Brown</figcaption>
</figure>

The creation of the figcaption element is an important step forward for the HTML5 draft specification as it finally provides a reliable means to markup the caption for content that is best marked up as a figure. Previous attempts to use the legend element, the caption element, and the dt and dd elements had failed due to a lack of backwards compatibility when it came to styling these elements with CSS.

The summary element

This new element represents a summary, caption, or legend for any content contained within its parent details element.

The summary element must be the first child of a details element and if there is no summary element present then the user agent should provide its own. The reason for this is because the details element has a specific function – to markup additional information and allow the user to toggle the visibility of the additional information. Although it is not specified in the specification, it is expected that the summary element will act as the control that toggles the open-closed status of the contents of the parent details element.

<details>
  <summary>Technical details.</summary>
  <dl>
    <dt>Bit rate:</dt> <dd>190KB/s</dd>
    <dt>Filename:</dt> <dd>drum-and-bass-mix.mp3</dd>
    <dt>Duration:</dt> <dd>01:02:34</dd>
    <dt>File size:</dt> <dd>78.9MB</dd>
  </dl>
</details>

The introduction of the summary element seems to secure the future of the details element and the new behaviour that it affords, for now. When user agents begin to add support for the details element you won’t need JavaScript, or even CSS, to have expanding or collapsing sections in an HTML document.

The future of the details element

There will continue to be some debate over the inclusion of behaviour in an HTML specification especially given the widespread use of JavaScript to provide the expand-collapse functionality that details describes.

The details element writes some quite significant behaviour into an HTML document and I can see it being abused to provide generic expand-collapse functionality throughout a document. It is also not entirely clear what purpose the details element actually serves other than being an attempt to bypass the need for JavaScript or CSS to expand or collapse sections of a document.

There has been a general softening of the rough distinction between content, presentation, and behaviour. JavaScript libraries are being used to patch holes in browser CSS and HTML5 support, the CSS3 modules introduce plenty of behaviour that was previously only possibly with JavaScript, and the HTML5 specification is also introducing functionality and behaviour that previously required the use of JavaScript.

The future survival of the details element, and the behaviour associated with it, may well depend on browser implementations and author applications over the coming months.

Here are two ways to include HTML5 elements in your WordPress post content without WordPress’ wpautop function wrapping them in p tags or littering your code with line breaks.

HTML5 has several new elements that you may want to use in your post content to markup document sections, headers, footers, pullquotes, figures, or groups of headings. One way to safely include these elements in your posts is simple; the other way is a bit more complicated. Both ways rely on hand-coding the HTML5 markup in the WordPress editor’s HTML view.

If you are adding HTML5 elements to your post content then you should use an HTML5 doctype.

Disable wpautop for your theme

This is the simple way. Disable the wpautop function so that WordPress makes no attempt to correct your markup and leaves you to hand-code every line of your posts. If you want total control over every line of your HTML then this is the option for you.

To disable wpautop entirely add these lines to your theme’s functions.php:

remove_filter('the_excerpt', 'wpautop');
remove_filter('the_content', 'wpautop');

However, wpautop is generally quite useful if most of your posts are simple text content and you only occasionally want to include HTML5 elements. Therefore, modifying wpautop to recognise HTML5 elements might be more practical.

Modify wpautop to recognise HTML5 elements

WordPress’ wpautop is part of the core functions and can be found in this file within your WordPress installation: wp-includes/formatting.php. It controls how and where paragraphs and line breaks are inserted in excerpts and post content.

In order to create a modified version of WordPress’ core wpautop function I started off by duplicating it in my theme’s functions.php file.

What I’ve experimented with is disabling wpautop and adding a modified copy of it – which includes HTML5 elements in its arrayss – to my theme’s functions.php file.

Add the following to your theme’s functions.php file and you’ll be able to use section, article, aside, header, footer, hgroup, figure, details, figcaption, and summary in your post content. (Probably best to try this in a testing environment first!)

/* -----------------------------
MODIFIED WPAUTOP - Allow HTML5 block elements in wordpress posts
----------------------------- */

function html5autop($pee, $br = 1) {
   if ( trim($pee) === '' )
      return '';
   $pee = $pee . "
"; // just to make things a little easier, pad the end
   $pee = preg_replace('|<br />s*<br />|', "

", $pee);
   // Space things out a little
    // *insertion* of section|article|aside|header|footer|hgroup|figure|details|figcaption|summary
   $allblocks = '(?:table|thead|tfoot|caption|col|colgroup|tbody|tr|td|th|div|dl|dd|dt|ul|ol|li|pre|select|form|map|area|blockquote|address|math|style|input|p|h[1-6]|hr|fieldset|legend|section|article|aside|header|footer|hgroup|figure|details|figcaption|summary)';
   $pee = preg_replace('!(<' . $allblocks . '[^>]*>)!', "
$1", $pee);
   $pee = preg_replace('!(</' . $allblocks . '>)!', "$1

", $pee);
   $pee = str_replace(array("
", "
"), "
", $pee); // cross-platform newlines
   if ( strpos($pee, '<object') !== false ) {
      $pee = preg_replace('|s*<param([^>]*)>s*|', "<param$1>", $pee); // no pee inside object/embed
      $pee = preg_replace('|s*</embed>s*|', '</embed>', $pee);
   }
   $pee = preg_replace("/

+/", "

", $pee); // take care of duplicates
// make paragraphs, including one at the end
   $pees = preg_split('/
s*
/', $pee, -1, PREG_SPLIT_NO_EMPTY);
   $pee = '';
   foreach ( $pees as $tinkle )
      $pee .= '<p>' . trim($tinkle, "
") . "</p>
";
   $pee = preg_replace('|<p>s*</p>|', '', $pee); // under certain strange conditions it could create a P of entirely whitespace
// *insertion* of section|article|aside
   $pee = preg_replace('!<p>([^<]+)</(div|address|form|section|article|aside)>!', "<p>$1</p></$2>", $pee);
   $pee = preg_replace('!<p>s*(</?' . $allblocks . '[^>]*>)s*</p>!', "$1", $pee); // don't pee all over a tag
   $pee = preg_replace("|<p>(<li.+?)</p>|", "$1", $pee); // problem with nested lists
   $pee = preg_replace('|<p><blockquote([^>]*)>|i', "<blockquote$1><p>", $pee);
   $pee = str_replace('</blockquote></p>', '</p></blockquote>', $pee);
   $pee = preg_replace('!<p>s*(</?' . $allblocks . '[^>]*>)!', "$1", $pee);
   $pee = preg_replace('!(</?' . $allblocks . '[^>]*>)s*</p>!', "$1", $pee);
   if ($br) {
      $pee = preg_replace_callback('/<(script|style).*?</\1>/s', create_function('$matches', 'return str_replace("
", "<WPPreserveNewline />", $matches[0]);'), $pee);
      $pee = preg_replace('|(?<!<br />)s*
|', "<br />
", $pee); // optionally make line breaks
      $pee = str_replace('<WPPreserveNewline />', "
", $pee);
   }
   $pee = preg_replace('!(</?' . $allblocks . '[^>]*>)s*<br />!', "$1", $pee);
// *insertion* of img|figcaption|summary
   $pee = preg_replace('!<br />(s*</?(?:p|li|div|dl|dd|dt|th|pre|td|ul|ol|img|figcaption|summary)[^>]*>)!', '$1', $pee);
   if (strpos($pee, '<pre') !== false)
      $pee = preg_replace_callback('!(<pre[^>]*>)(.*?)</pre>!is', 'clean_pre', $pee );
   $pee = preg_replace( "|
</p>$|", '</p>', $pee );

   return $pee;
}

// remove the original wpautop function
remove_filter('the_excerpt', 'wpautop');
remove_filter('the_content', 'wpautop');

// add our new html5autop function
add_filter('the_excerpt', 'html5autop');
add_filter('the_content', 'html5autop');

The results are not absolutely perfect but then neither is the original wpautop function. Certain ways of formatting the code will result in unwanted trailing </p> tags or a missing opening <p> tags.

For example, to insert a figure with caption into a post you should avoid adding the figcaption on a new line because an image or link appearing before the figcaption will end up with a trailing </p>.

<!-- this turns out ok -->
<figure>
  <a href="#"><img src="image.jpg" alt="" /></a><figcaption>A figure caption for your reading pleasure</figcaption>
</figure>

<!-- this turns out not so ok -->
<figure>
  <a href="#"><img src="image.jpg" alt="" /></a>
  <figcaption>A figure caption for your reading pleasure</figcaption>
</figure>

Another example would be when beginning the contents of an aside with a paragraph. You’ll have to leave a blank line between the opening aside tag and the first paragraph.

<aside>

This content could be a pullquote or information that is tangentially related to the surrounding content. But to get it wrapped in a paragraph you have to leave those blank lines either side of it before the tags.

</aside>

Room for improvement

Obviously there are still a few issues with this because if you format your post content in certain ways then you can end up with invalid HTML, even if it doesn’t actually affect the rendering of the page. But it seems to be pretty close!

Leave a comment or email me if you are using this function and find there that are instances where it breaks down. I ran numerous tests and formatting variations to try and iron out as many problems as possible but it’s unlikely that I tried or spotted everything.

Hopefully someone with more PHP and WordPress experience will be able to improve upon what I’ve been experimenting with, or find a simpler and more elegant solution that retains the useful wpautop functionality while allowing for the use of HTML5 elements in posts. Please share anything you find!

If you’re using HTML5 elements then you’re probably also using a JavaScript shiv to help make it possible to style those elements in versions of Internet Explorer prior to IE9. But when JavaScript is disabled the accessibility of the content may be affected in these versions of IE. This is one way to provide a more accessible fallback.

The concept is to ensure that all modern browsers are served the default style sheet(s) and that people using older versions of IE only download them if JavaScript is enabled. When JavaScript is not enabled, people using those browsers can be served either no styles at all (as Yahoo! suggests for browsers receiving C-Grade support) or simple fallback styles.

Client-side method: conditional comments

Doing this on the client-side comes at the cost of having to litter your code with proprietary conditional comments. First, it’s necessary to comment out the default style sheet(s) from versions of IE earlier than IE9. All other browsers will be able to read the file(s).

<!--[if ! lt IE 9]><!-->
<link rel="stylesheet" href="/css/default.css">
<!--<![endif]-->

For earlier versions of IE, an HTML5 shiv is included and the necessary link elements are created and added to the DOM using JavaScript. This means that when JavaScript is not enabled in IE7 or IE8 the style sheet will not be present, resulting in an unstyled HTML page. In this example, IE6 won’t be served CSS at all.

<!--[if (IE 7)|(IE 8)]>
<script src="/js/html5.js"></script>
<script>
   (function() {
      var link = document.createElement("link");
      link.rel = "stylesheet";
      link.href = "/css/default.css";
      document.getElementsByTagName("head")[0].appendChild(link);
   }());
</script>
<![endif]-->

To support multiple style sheets, an array and for loop can be used.

<!--[if (IE 7)|(IE 8)]>
<script src="/js/html5.js"></script>
<script>
   (function() {
      var css = [
         '/css/default.css',
         '/css/section.css',
         '/css/custom.css'
      ];
      var i;
      var link = document.createElement('link');
      var head = document.getElementsByTagName('head')[0];
      var tmp;

      link.rel = 'stylesheet';

      for(i = 0; i < css.length; i++){
         tmp = link.cloneNode(true);
         tmp.href = css[i];
         head.appendChild(tmp);
      }
   }());
</script>
<![endif]-->

Thanks to Remy Sharp and Mathias Bynens for helping me to improve this script. Fork it.

Rather than serving unstyled content, it may be preferable to provide some simple fallback styles. This can be done by linking to a separate style sheet wrapped in noscript tags. In this example, IE6 will always use these legacy styles while IE7 and IE8 will do so only when JavaScript is disabled.

<!--[if lt IE 9]>
<noscript>
   <link rel="stylesheet" href="/css/legacy.css">
</noscript>
<![endif]-->

You may wish to use a generic style sheet, such as “Universal IE6 CSS”, or spend a few minutes crafting your own and ensuring that the typography and colours approximate those in the default style sheet.

The complete example code is as follows:

<!--[if ! lt IE 9]><!-->
<link rel="stylesheet" href="/css/default.css">
<!--<![endif]-->

<!--[if (IE 7)|(IE 8)]>
<script src="/js/html5.js"></script>
<script>
   (function() {
      var link = document.createElement("link");
      link.rel = "stylesheet";
      link.href = "/css/default.css";
      document.getElementsByTagName("head")[0].appendChild(link);
   }());
</script>
<![endif]-->

<!--[if lt IE 9]>
<noscript>
   <link rel="stylesheet" href="/css/legacy.css">
</noscript>
<![endif]-->

Server-side method: user-agent string detection

The drawbacks of current client-side approaches to IE fallbacks is that they are IE-specific, make extensive use of conditional comments, and have to use JavaScript to create or rewrite link elements. This blog makes use of an alternative approach: server-side user-agent detection. It was inspired by Yahoo!’s Graded Browser Support strategy – created by Nate Koechley – which recommends that all CSS and JavaScript is withheld from legacy browsers (not limited to IE).

The source code in the head of this blog changes when viewed in modern browsers, IE8, and legacy browsers that are incapable of styling HTML5 elements (e.g. Firefox 2) or lack adequate CSS2.1 support (e.g. IE7).

Browsers are assumed to be capable; there is no need to update the script every time a new browser is released. Only when a browser is deemed to be severely incapable is it added to a “blacklist” and served simple styles to ensure that the accessibility of the content is maintained. This is the method I prefer, although it does require more time upfront.