HTML5 Doctor » ie

Your Questions Answered #7

Richard Clark — Tue, 20 Apr 2010 14:10:51 +0000

Here we are again with another round of patient questions about HTML5. In this article, we’ll be covering AJAX, the eternal question of

, our old friend Internet Explorer, how to mark up multiple blocks of content in a sidebar, and using

with .

HTML and AJAX

Arie asked:

I’m still learning about html5 and javascript, I’m wondering how html5 makes doing a lot of the things currently done in ajax and javascript more simple. Is it by providing things like the canvas that unify ideas?

Certain parts of HTML5 will indeed simplify or reduce the need for JavaScript. One such area of improvement is Web Forms 2.0, which will handle client-side form validation in the browser and provide new input types (like that checks for a valid email address). Of course, you’ll still need to validate your forms on the server, but at least the browser will catch the most obvious mistakes before the user actually submits the form.

Other parts of HTML5, like Web SQL Databases and , are essentially JavaScript APIs. They may not cut down on your need for JavaScript, but they do provide a consistent interface to some powerful functionality and will enable your application or site to do more things within (or outside of) the browser.

Cheers, Rich

or
?

Paul asked:

Hello

I see you are using divs on your website, I thought divs should be replaced by more semantic tags such as sections or article. what did I miss?

Thanks

Hi Paul,

Just like with HTML4, you shouldn’t use

s or s where another, more precise element would fit the bill. But for grouping arbitrary content,

s and s remain the way to go.

Thanks, Bruce

HTML5 and IE6

Adam asked:

Greetings HTML5 Doctor,

Is it at all possible to have a HTML5 layout while 30% of our users are running IE6? We are an IT company and our website is very large so having separate versions is completely impractical. HTML5 would allow us to move on and keep our markup a lot simpler but with no concrete guarantees regarding universal support is HTML5 ever going to get off the ground within 5 years while not having to resort to javascript solutions?

Simply change the doctype and you’ll be writing HTML5! If you want to use new elements, however, you’ll need to use JavaScript to support them (for all versions of IE up to IE8). The best place to start? Read Remy’s article on How to get HTML5 working in IE and Firefox 2.

I think we’re in a position to do something about this. By using the new doctype, block-level links, and new form input types (that degrade gracefully), we can start promoting HTML5 right now.

Cheers, Rich

Multiple blocks in a sidebar

Bart asked:

On my page (revora.net) I have a sidebar with content that I deem appropriate for the aside element. The sidebar contains several blocks of content. I’ve currently made the whole bar aside and made the blocks div. Is this correct, or should I do it the other way around?

It sounds like your first approach is correct. The

s might be

s or maybe

elements though, depending on their content. I suggest you read our article (and the comments) on the

element.

Thanks, Tom

Header with

Diego asked:

Hi,

This structure is right?
   
       
           Foo Bar
           Baz Bat Qux
       
   
   lorem ipsum
What I mean is, if I have a HEADER with just 2 H(n) I need to put these into a HGROUP ? Or… I can remove the HEADER and leave just a HGROUP? What’s the better solutions for it?

Thanks for all,

Diego Tres

What you have is correct. Basically, in the document outline, you will only see “Foo Bar” as the heading for that section. “Baz Bat Qux” will be hidden from the outline.

You don’t have to use a

within your

or an within your

. Similarly, you don’t have to use a

around your .

To summarise, the best solution (if you don’t require the

to appear in the document outline) is what you’ve already got.

Cheers, Rich

Got a question for us?

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

Share and Save:

Your Questions Answered #7 originally appeared on HTML5 Doctor on April 20, 2010.

dd-details wrong again

Remy Sharp — Mon, 12 Oct 2009 12:00:57 +0000

You may recall that I blogged about legend not being so legend as the heading element for details or figure. After enough noise was made the spec was changed so that the heading and contents of these elements can now be marked up using the dt/dd combo.

Although not immediately obvious why it’s the right choice, it appeared to work for our needs…at first. Of course now, it’s been discovered that it’s actually a pretty bad idea.

How we got here

In short, details and figure solve a common design pattern and provide nice new semantic tags to solve that problem. A figure could be an image you’re referring to in an article or chapter of a book, and the details element allows the user to interactively show and hide the details of some piece of information.

Both elements can contain a heading element to label up the contents. For some reason, beyond this author’s understanding, these two elements, completely different in meaning, have been historically tied to using the same solution solve the problem how to markup the heading.

As I mentioned earlier, originally the proposed solution for the headings was to use the legend element, which proved to completely break in every browser (in new and interesting ways).

Skip forward to mid-September, and Jeremy Keith proposes that we solve the legend issue with the dt/dd combo, and Ian Hickson says:

That’s not a bad idea actually. Ok, done.

Before this was proposed there was lots of discussion about why we couldn’t introduce a new element to solve this problem, and Ian points out already 18 (or 22, I forget!) elements that represent some sort of heading. This is the argument for not introducing another new heading type element to solve the details and figure problem.

The problem with dt/dd

Ironically the problem isn’t with the dt part of the solution, it’s actually with the dd.

Dean Edwards (genius behind some very cool JavaScript and something that will soon blow your minds) has been testing these elements in detail and found a very serious issue with the dd in, guess what, IE6 & 7. I want to explain and draw attention to what Dean has found.

Styling a dd within details or figure (and probably other elements) bleeds to the next element.

By styling a dd red, and only the dd, here’s what it should look like (and does in IE8):

Where as in IE7 (and IE6), the red style bleeds in to the following p element (note the “this paragraph shouldn’t be red”):

![dd styled in IE7](

What’s more, if you look back at the screen shots you can see the last paragraph says “Contents of first

”. The result of that test is being generated by the following JavaScript:

document.getElementsByTagName('dd')[0].innerHTML

Notice how in IE7, the contents of the first dd’s innerHTML is empty.

The problem here is that:

IE7 and below can’t style a dd properly without it breaking and the style bleeding in to adjacent elements.
JavaScript, randomly, can’t see the contents of the dd.

Is there hope?

There is a hack that fixes this issue. It’s pretty mad, but it does fix the styling issue. However the side effects from this hack are outright unacceptable and are so serious I would argue that the hack solution itself is a bug.

The hack is over at the public-html of W3.org, and involves stuffing an open object tag just before we close the head tag.

This isn’t a clean solution for including in HTML by hand, authors won’t remember or might get it wrong, so it needs to be perhaps automated as part of the HTML5 enabling script, right? It would have to be inserted using document.write() as the last part of the head element.

Dean went on to test this, and he found:

There is a nasty side effect though. As you mentioned the document.write() should be the last thing in the . If there are any scripts following the document.write() then they are not executed.

The really freakin’ important bit:

If there are any scripts following the document.write() then they are not executed

So, to answer the question: is there hope? No, not for the dd/dt combo. It can’t be styled properly and hacks will break JavaScript.

We want the details

We, as authors, want to make use of details and figure today. Waiting for IE7 to fall out of circulation before we start using these elements (as it’s been proposed a number of times on the IRC channel and mailing boards) is outright not going to happen. IE6 & 7 are going to be around for a good more number of years, certainly IE7 (IE6 has at least another 5 years in the beast).

We are going to start enabling the details interactive UI pattern using JavaScript whilst we wait for vendors bake it in to the browser, so the final proposed markup needs to work in all the browsers, including IE6 and IE7.

What are our current options?

Give new meaning to an existing element (as we’ve already tried to), legend, label and dt/dd have been tried, tested and failed. What else could we use?
Repurpose one of the existing new elements (keeping in mind that the dt/dd was repurposed so it should be a consideration).
Create another heading element to solve this problem.

The problem is that the conversation seems to have lost steam (or certain Dean was starting to see the conversation go in circles). If you want to see these two elements make it the final spec, and correctly, head over to either the IRC channel or the mailing list, and get heard.

Reference links

Dean’s original details test (my modified tests to fire the innerHTML on load: details, figure)
Litmusapp browser screenshots of the results: details, figure
whatwg mailing list thread: September, October
Related Posts:

Share and Save:

dd-details wrong again originally appeared on HTML5 Doctor on October 12, 2009.

How to get HTML5 working in IE and Firefox 2

Remy Sharp — Sat, 20 Jun 2009 08:05:45 +0000

HTML 5 may be the latest and greatest technology, but some browsers don’t have native support for the new semantic elements. Let’s momentarily forget about the really sexy functionality, like full control over the element, and just focus on getting the elements rendered.

The problematic A-grade browsers include IE 8 and below, Firefox 2, and Camino 1 (these last two browsers both use the Gecko rendering engine, which is why they’re both affected).

Let’s start with Internet Explorer.

IE doesn’t believe in HTML 5 elements

Quite simply, IE doesn’t even see HTML 5 elements, much less style them.

This is actually the same issue that we had before HTML 5, where the element couldn’t be styled in IE 6, resulting in all manner of workarounds. (Let me add that we’ll also fix the element while we convince IE to recognise HTML 5 elements).

The fix

There is hope! The trick, discovered by Sjoerd Visscher, is simply to create the new element using JavaScript, and voilà, IE is able to style it:

document.createElement('header');

John Resig has also written about this HTML 5 shiv.

For example, say you wanted to style the element in italics:




  Header test
  


  my birthday

This screenshot shows the rendering in IE before we apply the fix:

To apply the fix, add the indicated line of code:




  Header test
  
  
  
  


  my birthday

Now after we’ve applied the fix, it’s correctly styled in IE:

One hit solution

For everyone’s convenience, I wrote a single JavaScript file that can be included to create all the HTML 5 elements (and the element) for IE.

Download the IE HTML 5 enabling script

Include the script in your tag, and you’ll be able to style the elements appropriately in IE:

Note that I’ve used a conditional comment to only apply this to IE 8 and below. It’s my hope that IE 9 and onwards will support HTML 5 elements, but when that day comes, make sure to double check the conditional!

Conditions & Gotchas

There are a couple of things to be aware of when using the HTML 5 shiv.

JavaScript required

This obviously means that your design now depends on JavaScript. Personally, I feel that if you’ve used semantic markup for your site and the elements can’t be styled, the content is still completely readable.

Here’s a screenshot of the Full Frontal web site, written using HTML 5 elements, rendered in IE with and without JavaScript enabled:

You can see in the second screenshot that the content isn’t perfect, but it’s still readable — it cascades down correctly, much as if CSS were disabled.

A little head is always good

If you create the new element and don’t use a tag (which is perfectly valid HTML 5), IE will put all those created elements inside the tag. Pretty crazy, but you can easily avoid this by always using both the and tags in your markup. Leif Halvard explains further with demos.

Firefox 2 and Camino 1 rendering bug

Both Firefox 2 and Camino 1 have a bug in the Gecko rendering engine (specifically versions prior to 1.9b5):

Firefox 2 (or any other Gecko-based browser with a Gecko version pre 1.9b5) has a parsing bug where it will close an unknown element when it sees the start tag of a “block” element p, h1, div, and so forth.

According to the W3 Schools stats, Firefox 2 only has around 3% of the market — perhaps low enough to justify ignoring it. It’s safe to assume that Camino 1 commands an even smaller percentage of the market.

By ignoring this issue, however, a site can look quite bad in these browsers. So how can we fix it?

The bug surfaces when Gecko doesn’t recognise an element. Explained roughly, when Gecko parses an unrecognised element, it removes the element’s contents and puts them next to the element.

Take, for example, the following code:


  Title
  ...

This will be parsed in Gecko (prior to version 1.9b5) as if the markup were actually as follows:


  
  Title
  
  ...

The visual result is similar to the above screenshot of IE running without JavaScript (though subtly different, as the DOM tree is actually in a different order than you as the author intended).

The fix

There are two approaches to fixing this issue, and so far I've only successfully used the non-JavaScript approach.

The JavaScript solution

The first approach is to use JavaScript to traverse the DOM tree, rearranging elements as issues are encountered. Simon Pieters has a small working example of how this can be done (towards the bottom of the page). In practise, however, I personally found it didn't work for my markup. The problem is definitely solvable using JavaScript, but this solution still needs work to handle all permutations of markup.

The XHTML solution

The second approach is to serve Gecko XHTML. I've found this to be the easier approach if you're either generating a page dynamically (using something like PHP) or if you can create your own .htaccess file to use Apache's mod_rewrite.

The first change to your markup is to add the xmlns attribute to your tag:

Next, we need to sniff the user agent string (typically a bad approach, but justifiable when targeting such a specific group of users). If the Gecko build is less than 1.9, then we need to set the Content-type header to application/xhtml+xml.

If you want to use mod_rewrite in an .htaccess file (or the httpd.conf file), you need the following rules:

RewriteCond %{REQUEST_URI} \.html$
RewriteCond %{HTTP_USER_AGENT} rv:1\.(([1-8]|9pre|9a|9b[0-4])\.[0-9.]+).*Gecko
RewriteRule .* - [T=application/xhtml+xml]

This rule sends the proper Content-type header to all Gecko based browsers where version is less than 1.9, or "rv:1.9pre" or "rv:1.9a" or "rv:1.9bx" where x is less than 5.

If you don't want to use the mod_rewrite approach, you'll need to manually send the header in your server side scripts. Here's a solution for a PHP script:

if (preg_match('/rv:1\.(([1-8]|9pre|9a|9b[0-4])\.[0-9.]+).*Gecko/', $_SERVER['HTTP_USER_AGENT'])) {
  header('Content-type: application/xhtml+xml');
}

This snippet needs to be included before anything has been printed by your script — i.e., as early as possible.

Gotcha: Yellow Screen of Death

The Yellow Screen of Death shows up whenever there's an XML error on the page. If we're serving markup as XML and telling the browser to interpret it strictly as XML, then we can't serve any characters it doesn't recognise or else it's going to bork:

Below are a few ways to avoid XML parsing errors.

Create strict markup

You need to ensure your markup is squeaky clean — but that's easy, because you're already a Markup Jedi, right?

Use XML entities

HTML entities are a no-no. Sorry, but • isn't going to fly anymore. You need to use XML entities, the numerical representation of these characters.

I've built an entity lookup tool that shows the HTML entity and the XML value of that entity. For example, • is 8226, so the XML entity is •.

Sanitise user generated content

If your site relies on any user generated content (e.g., blog comments), then you need to sanitise the output to ensure there are no validation issues to trigger the Yellow Screen of Death.

This issue alone may justify further investigation of a JavaScript solution.

Worth the trouble?

All that said, Firefox has a very good automated upgrade path. Looking at the stats on W3Schools, it's safe to say that the number of users with this Gecko bug is rapidly diminishing.

HTML5 Doctor » ie

Your Questions Answered #7

dd-details wrong again

How we got here

The problem with dt/dd

Is there hope?

We want the details

Reference links

Related Posts:

How to get HTML5 working in IE and Firefox 2

IE doesn’t believe in HTML 5 elements

The fix

One hit solution

Conditions & Gotchas

JavaScript required

A little head is always good

Firefox 2 and Camino 1 rendering bug

Title

The fix

The JavaScript solution

The XHTML solution

Gotcha: Yellow Screen of Death

Create strict markup

Use XML entities

Sanitise user generated content

Worth the trouble?

Further reading

Related Posts: