The W3C gives us the First Public Working Draft on HTML5, and outlines what exactly we’ll see that’s different from good ol’ HTML4. Really cool stuff here, on a semantic, mark-up geek level. I’m as exctied about input type="email" as anybody.
Edit: Snook points out that using the HTML 5 Doctype will automagically put IE into "IE 8 mode" without the use of the meta tag.
Tags: html
Another great opinion, from the comments on Anne van Kesteren’s take on the issue:
Solutions? We can ignore this all together.
Ignoring issues seems convenient but there’s a high risk that things get worse in the end than if we didn’t ignore it.
We can get popular Web server software to set IE=edge.
No. This only leads to IE9 getting a different mechanism for the opt-in switch, because, obviously, if a lot of pages uses “IE=edge” without the author’s consent, IE9 would break all those pages, and that wouldn’t be acceptable to MS. So we end up with yet another switch.
We can convince the world to use a browser that does not have the ability to lock pages into a specific rendering mode.
Yes, but how? I wouldn’t expect IE8 standards mode to be on par with other browsers’ standards mode. People expected IE7 to be CSS 2.1 compliant, but it was the same IE with some bugs fixed, some new features, and a bunch of new other bugs.
For damage minimization, I would recommend Web developers to not use IE8 standards mode, as tempting as it seems. You still have to work around IE7. You know what the workarounds are. Continue to use quirks mode or “IE7 standards mode”, whichever you use today. If people don’t use IE8 standards mode, then MS won’t break many sites by continuing to improve “IE8 standards mode”, and thus they don’t have any reason to introduce yet another rendering mode for IE9.
The Internet Explorer lock-in - Anne’s Weblog
Tags: ie8
The IEBlog predictably announces that Web developers will have to use a tag or HTTP header to get IE to treat a page with post-IE7 standards compliance. Obviously a lot of people are going to be upset about this. I’m actually just puzzled. I see the business argument for taking this approach in the short term, but in the long term, it seems to impose a crippling burden on IE development.
Via Roger Johannson’s 456 Berea St., here’s a nice counter argument to the "IE8 Standards Meta Tag Solves All Our Problems" sentiment. Some good points here, and it echoes my question about code footprint size.
We could spend hours explaining why our sites broke, but wouldn’t it be better if they didn’t break in the first place?
A List Apart: Articles: Beyond DOCTYPE: Web Standards, Forward Compatibility, and IE8
Snook has something on it, too. Interesting to see how they were going to do it. I find the concept interesting (kind of like "freezing" your Rails version), but I wonder how much overhead it will cause browser vendors: will they have to keep old versions of the same rendering engine lying around, just in case?
Tags: ie8, meta, doctype, versioning
<style type="text/css"> @import(mystylesheet.css); </style>
vs.
<link rel="stylesheet" type="text/css" href="mystylesheet.css">
Which is the way to go? It’s link, and here’s why:
link is easy to skim. @import very quickly gets hard to skim as it’s more than a single line. If you’re trying to quickly browse through a lot of source, you’ll want as few lines as possible. If you’re searching through source, it’s quicker to type "link" then glance to the right.
What about including multiple stylesheets on a single page? Well, that depends on two things: how many stylesheets you’ll have on a single page and who is going to be maintaining those pages.
If you have a ton of stylesheets, it’s best to create a single, master sheet, then use that to @import what you need: write it once, include it where you need it, and it’s done. The same holds true for the latter point: unless you’re going to be the one maintaining those pages and you’re absolutely sure that you’ll remember exactly which page needs exactly which stylesheet, use the one-sheet-only approach.
Get rid of the need to keep track of more than one stylesheet in all but a single place. If you need to make an update, you’ve got an all-in-one fix, otherwise you’ll have to go page-by-page, and that’s never good.
Finally, I like the modular approach to stylesheets: make a separate sheet for separate page types or pieces of content (put your navigation in one, promos in another, and content in a third). Yes, it makes for more stylesheets in the long run, but you’ll save a great deal of maintenance effort, and that’s what counts the most: it’s just easier to find things when they’re kept in sensible modules than when they’re all lumped together.
Tags: stylesheets, css, link
Over at the day job, I ran into a situation where I couldn’t use conditional comments to insert my IE-only stylesheets into the Document. In fact, I didn’t have access to the <head> of the Document at all.
Without any access to the <head> at all, how can we add a stylesheet to the Document? Well, we can do it improperly, by using JavaScript’s document.createStylesheet method to cram our CSS into the body of the Document. Is this where it should go? No. Does it work: yes.
What about making that IE-only? Conditional compilation. By placing the document.createStylesheet call inside some conditionally compiled JavaScript, we’ve achieved the same effect as our conditional comment would. But, what about targeting a specific browser?
With conditional compilation, we have access to the @_jscript_version property of the browser. IE7 uses Jscript version 5.7 and IE6 uses 5.6. Knowing that, we can create an IE6-and-lower-only stylesheet with a one-line test:
@if (@_jscript_version < = 5.6) document.createStylesheet('/path/to/ie6andlower.css');. Voila! A working structure.
Put it all together, and we have a solution that looks something like this:
/*@cc_on
document.createStyleSheet("/css/all_ie_fixes.css");
/*@if (@_jscript_version < = 5.6)
document.createStyleSheet("/css/ie_6_and_below.css");
/*@end
@*/
Is it pretty? Nope, but it works.
Tags: crossbrowser, conditionalcompilation, ie6, ie7, stylesheets, conditionalcomments
HasLayout will be history with IE8 (it was an internal data-structure to begin with and should have never been exposed).
Ajaxian » Infamous IE hasLayout is toast
This is good if they patch up their rendering engine so that we don’t need to "force" layout to get things to work. This is bad if they don’t patch up their rendering engine and we lose the ability to get things to work through "forcing" layout.
Tags: ie, crossbrowser
