Internet Explorer 8: The X-UA-Compatible meta element and conditional comments
22 August 2010 | Posted by Jeffrey Barke | 4 comments
I woke up this morning to discover that Paul Irish had left a comment on one of my GitHub commits:
A user reported that this actually didnt work.. the ie=edge never jumped ie8 into standards mode..
did you see it succeed?
Hmm… this didn’t sound good. The error in question was on our HTML5 template for The Knot. We had wrapped the X-UA-compatible meta element with an IE conditional comment. I don’t remember exactly why we did this, but I think it had something to do with HTML validation.
Now, I know that HTML validation doesn’t matter (see also “The value of HTML validation”), but I do like using it as a lint tool (and yes, I prefer to just see a green favicon in the title bar). However, I also understand that pages don’t have to validate in the wild and I had never actually tested wrapping the X-UA-Compatible meta element with a conditional comment. I just assumed it would work, because, well, why shouldn’t it?
Damn. Once again, I learn the value of assumptions. It turns out that the way it’s coded doesn’t work. IE8 completely ignores the X-UA-Compatible meta element. Since I recently read about conditional comments blocking downloads, I was curious if this had anything to do with it and if the solution I had settled on for that problem would also help with this one. Voilà!
Since the download blocking also affects conditional comments around the body element and I wanted to avoid putting an empty conditional comment in the head, I moved the conditional comments to the html element. This solution also causes the conditional X-UA-Compatible meta element to be seen by IE!
UPDATE: There is one problem with this technique: it breaks Google Chrome Frame. Chrome Frame ignores IE conditional comments, so it never gets invoked. If you want your page to work with Chrome Frame and you want it to validate, send an HTTP header. If you can’t set the header, don’t wrap the meta element with conditional comments. Besides, validation doesn’t matter anyway, 
.
<!--[if lte IE 6 ]><html lang="en-us" class="ie ie6"><![endif]-->
<!--[if IE 7 ]><html lang="en-us" class="ie ie7"><![endif]-->
<!--[if IE 8 ]><html lang="en-us" class="ie ie8"><![endif]-->
<!--[if !IE]>--><html lang="en-us"><!--<![endif]-->
<head>
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge" /><![endif]-->
</head>
</body>
</body>
</html>Tests
IE=7. Works!IE=edge. Works!IE=edgewrapped in conditional comment. Does not work!IE=edgewrapped in conditional comment with conditional comments around thehtmlelement. Works!
Notes from the SXSWi Web form design panel
15 March 2009 | Posted by Jeffrey Barke | No comments
Designing Our Way Through Web Forms
Although forms make the Web go around, they are often ugly due the generic way in which browsers display them, not to mention irritating to our site's visitors when they don't work as expected. In this session, panelists will provide specific details on ways to successfully create compelling forms for your users.
- Christopher Schmitt, Web Design Specialist, Heat Vision
- Eric Ellis, VP Sr Designer, Bank of America
- Kimberly Blessing, Senior Web Development Manager, Comcast Interactive Media
Canonical URL links
22 February 2009 | Posted by Jeffrey Barke | 4 comments
From Yoast and very cool:
Google, Yahoo and Microsoft have just announced a new tag, which we can use to tell the search engines which URL it should have for the current page. This is probably best explained with an example, so here goes.
Suppose you have read my Twitter Analytics post, and you've started tagging all the URLs you spread on Twitter with Google Analytics campaign variables. So at some point, Google enters your site through this URL:
http://yoast.com/twitter-analytics/?utm_source=twitter&utm_medium=twitter
&utm_campaign=twitterIf it did, in "old times," this would mean you'd have a duplicate content issue: the same content indexed under two different URLs. An issue SEOs have been trying to solve on web pages for ages, which sometimes created huge limitations. This is where the new tag comes in. You add this code to the
<head>section of your page:
<link rel="canonical" href="http://yoast.com/twitter/analytics/" />
Read the rest of Yoast's post and learn more about canonical URLs at http://yoast.com/canonical-url-links/. Google's official post on canonical URLs is at http://googlewebmastercentral.blogspot.com/2009/02/specify-your-canonical.html.
To make things easy for us, Yoast has already prepared a WordPress Canonical URL plugin , as well as a Magento extension and a Drupal module! Thanks, Joost!
While I appreciate Yoast blogging about this and their work in preparing the plugin, extension and module, one small critique. Technically, this is not a new "tag," rather it is simply a new value for the rel attribute of the existing link tag.
WebTechNY presentation—HTML validation, microformats, jQuery
12 October 2008 | Posted by Jeffrey Barke | No comments
Slides from my presentation on HTML validation, microformats and jQuery to WebTechNY on 8 October 2008:
Thanks to everyone who attended!
My favorite "new" tag: <wbr>
9 October 2008 | Posted by Jeffrey Barke | No comments
While it's nowhere near close to new, I discovered the <wbr> (word break) tag today. The need for a tag like this occurred on a client's website: the title of one of their publications, which included two relatively long words separated by a slash, was poking outside of the side navigation in IE 6. Since the title looked fine in other browsers, I wanted a way to "suggest" a line break after the slash to IE without forcing a line break on every browser. <br> was out.
Enter the <wbr> tag. <wbr> "marks a place where a line break can take place. It does not necessarily always result in a line break; rather, it says that line breaks are allowed at this place." To use <wbr> in XHTML, use the XML syntax for empty elements: <wbr />.
Not all browsers support <wbr> (including Opera), however IE 5.5–7 and Firefox 2–3 do. Opera compatibility can be achieved via the following CSS rule:
wbr:after { content: "\00200B"; }
QuirksMode.org has a browser compatibility table for <wbr>. While not mentioned there, <wbr> does work in Chrome.
Note to standardistas—<wbr> is not in any of the HTML specifications. This means it will cause validation errors.
References
- "Word division in IE." Jukka "Yucca" Korpela
- QuirksMode.org Peter-Paul Koch
Standardistas? Are you serious?
3 August 2008 | Posted by Jeffrey Barke | 2 comments
I probably shouldn't be so critical, but it's Saturday night and I'm at home working. During a brief Wikipedia break (computer jargon), I decided to read the standardista entry and followed an external link to webstandardistas.com.
I'm not sure what I expected to find, but I guess it wasn't a placeholder for a forthcoming Friends of Ed book. Regardless, it was disappointing to see that while these standardistas did have a valid DOCTYPE, it was neither HTML 4.01 Strict nor XHTML 1.0 Strict, but XHTML 1.0 Transitional. It was also disappointing to see inline JavaScript and CSS in the head instead of an external stylesheet.
And, while it was only a single error, it was the use of an incorrect inline JavaScript onsubmit (they have it incorrectly specified as onSubmit) handler that causes the page to not validate!
I'm also not sure how I feel about the use of h3 and p tags within unordered lists. Is this really necessary? Why not just have multiple uls below the headings? Or instead of the li with child p construct, use definition lists?
Finally, there's no server side validation on the "Keep me posted form"!
Call to Action: Help Keep Accessibility and Semantics in HTML
9 May 2007 | Posted by Jeffrey Barke | No comments
Standardistas and accessibilitistas: This call to action via 456 Berea St concerns a disturbing direction the next HTML specification is heading. Roger Johansson writes:
What is currently going on in the W3C HTML Working Group is very disappointing and something I never expected to see when I joined it. I was naive enough to think that everybody joining the HTML WG would be doing so out of a desire to improve the Web. Unfortunately, that does not seem to be the case […]
In Roger's opinion, if nothing is done, "the next version of HTML will do nothing to improve the Web," and conscientious designers will be "better off sticking to HTML 4.01 Strict."
So, if you have an interest in improving the accessibility of HTML, want more semantic and less presentational markup, and are good at arguing your case, apply for HTML Working Group membership by following the instructions for joining the HTML Working Group. Do it now.
