I am really sorry that I couldn’t be at the event in person. Some things in life are just more important than browsers (not many though) -my wife was involved in a nasty car accident yesterday so I needed to be at home to look after her.
However, I thought I would try and answer your questions from twitter in-between fetching cups of tea and playing nurse for my wife.
If you have anymore question just tweet me at @thebeebs, I will do my best to answer anything I get.
- Does IE9 support new HTML5 form input types?
- Can you explain the design decisions behind the hideously small horizontal space for tabs?
- How do you switch on do-not-track header in IE9?
- Why/how text-shadow didn’t make the feature cut?
Does IE9 support new HTML5 form input types?
Asked by @chrisdavidmills from Opera during his talk, also @simnom on twitter
The simple answer is No. In IE9 we don’t. As Chris mentioned in his talk there are an number of issues still to iron out and so the W3C spec is very likely to change. We generally don’t put implementations that are not stable into our final released browsers. We take our responsibility to the future of the web seriously (or at least we do nowadays) and we believe that implementing a standard before it ready would cause headaches for developers in the future.
Lets say we implemented the new input types in IE9 then in 2 months the spec changed to fix accessibility or JavaScript styling. We would then have released a browser into market that doesn’t conform to the standard. Developers would have to hack around our implementation. I think it’s better for everyone if we wait for this one to become more solid.
Implementing stuff which wasn’t ready or properly thought out was the exact thing we did wrong with IE6…. And we are still paying for it 11 years later.
As a developer I share the frustration – this stuff is really helpful and I want to use it too.
The good news is because we don’t support it; it makes dealing with adding support quite simple using Feature Detection.
- Use the new HTML5 form Inputs.
- Feature detect if the viewing browser supports it. True (You’re Done) False (Go Next)
- If it isn’t supported, browsers will just render standard textboxes.
- Apply a JavaScript shim to replicate the validation.
- You’re Done
The method described above will ensure that when we do support HTML5 forms you won’t need to change your site to support IE. It will just work as our implementation will be interoperable and based on a stable W3C standard.
Outside of the HTML5 spec, there are certain working draft specs that we wanted developers to try out. That’s why we created HTML5labs.com. You can test out our current implementation of WebSockets and IndexedDB there.
Can you explain the design decisions behind the hideously small horizontal space for tabs?
Asked by @subcide on twitter
Most of the design features in our new UI was based upon Telemetric data that we receive via people that opt into allowing their browser to send information back to Microsoft so we can Improve. We use telemetric research in most of our product design as it helps our designers understand how people actually use our software rather than them having to make assumptions. It’s how we designed the ribbon UI for Microsoft Word and why the Back button is larger in IE9 (its far and away the most used button in our browser)
One data point showed, that on average, most users browsed with 3-4 tabs at once. As a percentage very few had more than this. Our designers used this information to reduce the screen real estate that the the tab bar took up, giving more space to the website.
Despite the fact that 3-4 tabs was the general use case, many of our more savvy users pointed out that they commonly have 10+ tabs open at once.
It was therefore decided in the final release to default to a smaller space for the tabs and save on screen space, but give users that wanted tabs on a separate row the ability to do so.
How do you switch on do-not-track header in IE9?
Asked by @patrickf on twitter
First go to Safety > Tracking Protection:
Then hit the enable button:
You can read more about how we are working with the W3C and other browser vendors to standardise tracking in this article I wrote last week for ubelly.
Why/how text-shadow didn’t make the feature cut?
Asked by @subcide twitter
I can’t give you a definitive or official answer to this one as, honestly, I don’t know. I will however give you my opinion.
As I mentioned in the first question, we usually take a “wait till it’s stable” approach to implementation. In the instance of text-shadow I think it’s fair to say that most would consider it both mature and stable.
Over the past year we have released 8 developer previews, a beta, a release candidate and a final version of the browser. With each one we have surprised many with the amount of CSS3 and HTML5 support we have added. We took the approach of adding features that we felt developers wanted and needed. Our support for standards like Canvas, Geolocation and transforms were all pretty big surprises when they were released.
I think it was right to focus on some of the basic issues and some of the exciting new features first. A feature like text-shadow, whilst it’s a nice thing to have, isn’t going to revolutionise the web and not supporting it won’t lock users out of experiences. Users will simply lose a touch of polish on certain websites. I’m firmly of the opinion that websites don’t have to look exactly the same across all browsers and text-shadow degrades very nicely.
I’m not dismissing text-shadow, far from it, I’m just suggesting that the team were probably right to focus on bigger issues first.
Also I think the work that has been done in regard to text legibility in IE9 is fantastic. We used hardware acceleration to achieve sub-pixel rendering which improves the quality of the text in the browser. Take the Paul Rouget post below. Although we don’t support text-shadow I think it’s fair to say our text looks a great deal smoother (check out the o in no)
In conclusion I think its a little disappointing that we don’t support it. However, I’m glad we chose not to support it, rather than rushing something out that wasn’t well tested; just so we could tick a box on a CSS3 support Matrix.
As I have said before: a bad implementation is worse than no implementation.
Pingback:IE9 的美中不足的地方 – 2011-03-21 | Share ChiWai/Share 智慧/智慧分享 – 技術分享/Tech Blog
Pingback:State of the Browser » Broken Links
Thanks for the post, I imagine some of this would be avoided if IE iterated faster. I really do appreciate the frankness in this post and IE9′s release. Looking forward to the continued momentum!
BTW small typo: Your Done should be You’re Done.
I have another question for you. Will you try to decrease the time between IE releases? Chrome, Firefox, Opera and even to a lesser extend Safari have been pushing releases of their browsers out much faster these days, and it has been nice to see the improvements come more rapidly to users. Things that didn’t make the cut for IE9 like text-shadow, css gradients, transitions, HTML5 form features, etc. are all nice things to have, and I’d rather not wait 2 years for them to show up in IE10. Thoughts?
Oops, just totally asked the same question as Seth at the same time. Whoa!
I think the biggest beef for me about text-shadow was not answered in the response here.
The confusing thing for me, is that box-shadow IS supported, however text-shadow is not. If I were to prioritize various CSS properties, I would DEFINITELY put text-shadow ahead/above box-shadow since it can actually change the legibility of content, whereas box-shadow is 100% decorative.
The only rational explanation I can come up with, is that box-shadow would be easier to implement than text-shadow? I would have definitely have preferred the energy be put into text-shadow though.
Here’s the information you need. All browsers support (fill in the blank). IE9 does not support that.
Glad to see that “hardware acceleration to achieve sub-pixel rendering” was apparently higher priority than the text-shadow property, which, despite Microsoft’s reality distortion field, is and has been in use in half-decent browsers since 2009, and what web developers actually need and want to use to create a modern UI. Instead we get “hardware acceleration”.
Yes, the myriad IE9 improvements over their last browser are great, and there are a couple sadly misguided but smart and good-natured people at Microsoft. The people that wrote this blog post and created this site are perfectly swell and talented people. But as a company, Microsoft have proven beyond a shadow of a doubt with their posturing on IE over other browsers[1] and with the Outlook 2007-2010 “let’s use Word to render HTML” debacle[2] that the needs of their marketing department come first, and developers that actually need to work with their products can go figure something out, because “we can embed SmartArt in email, so who needs antiquated CSS properties like padding or margin or or background or float or position?”
[1] http://windows.microsoft.com/en-US/internet-explorer/products/ie-9/compare-browsers
[2] http://www.campaignmonitor.com/blog/post/2799/microsoft-to-ignore-web-standards-in-outlook-2010/
“We generally don’t put implementations that are not stable into our final released browsers.”
Go and eat dust.
Ok, first you say ” … We would then have released a browser into market that doesn’t conform to the standard. Developers would have to hack around our implementation.”
Then you say ” … Apply a JavaScript shim to replicate the validation. ”
WTH?! By not supporting a well documented and widely supported and used features, you are telling developers to install a hack, so when IE does come around to finally supporting this feature, then I have dead code?
It is great that IE went out on a limb and started supporting a lot of the backend features, but even these features are really bleeding edge and not widely used, while features that developers REALLY WANT TO USE are left in the dust.
I mean NO FORM TYPE support. Not one. I would have been happy if you even tried for a few.
IE, if you think that you can keep stalling on developing features and ‘waiting’ for stable standards, you will always be yesterdays browser. If you haven’t heard, the development of the browsers is what is pushing the standard forward.
To these responses, I call bull.
Fair enough. Forms in IE9.1 or IE10 though?
Will progressive enhancement (sorry, graceful degradation) still be needed for some of the HTML5 input types? like having to use the jQuery UI datepicker instead of a native one?
It’s all well and good saying you’ll wait for features to be finalised in the specification until they’re launched, but the main issue is that it will never be completely finished – ever.
I don’t quite understand why the rest of the browser industry can get it right, but the top-dog can’t. Why not enforce browser updates a la Chrome? Surely having a constantly iterating browser that adapts to a changing feature-set and security fixes is better than waiting for the W3C to stop arguing and rubber-stamp something? That would fix the main issue most people have had with IE for the past decade, that changes aren’t implemented quickly enough and aren’t enforced.
Its really their small development cycle holding them up.. Firefox and chrome change features very often..
So I have been thinking that moving forward I will specify in our contracts that we will build websites to W3C standards and not guarantee IE support. We will add the HTML shim and support for CSS3 and go with that. Apparently Microsoft is in agreement. Let them catch up with me, if they can.
Thank you for your thoughtful responses to these questions. I would respectfully disagree with this statement regarding drop shadows: “not supporting it won’t lock users out of experiences”.
Drop shadows add significant legibility when text is placed on top of variable backgrounds. Placing a dark drop shadow behind white text overlaying a picture helps distinguish the letters where the photo provides lack of contrast. So, in this instance, IE users are locked out of an experience.
Regarding HTML5 form support, I hope the IE team would consider releasing this capability as soon as you deem it acceptable, even if it is an incremental release. As the best practice is now capability testing (as you referenced), I do not see any reason to hold off on such features until the next major release. I’d hate to see a 2 year delay on this capability, if only 6 months is needed to bring stability to the specs.
oh wait a minute, for those wanting to use full HTML5 support (well as much as Google Chrome anyway) you can “force” the end user to download and install Google Chrome Frame with this line
For more check here
@seth @devon Sorry I don’t have an update about that. Things have improved a lot over the last year. The platform previews that dropped every 8 weeks really shows the momentum and flow that the team has got into.
The people working on IE are clearly idiots and have never used the web. Not including text shadow is idiocracy. Some websites actually depend on the shadow to be legible. Also the lack of inclusion of auto-update is shooting themselves in the foot. No wonder people are stuck on ancient ie versions. IE team, you need to grow up.
The issue that web developers are having is that MS’s release cycle is not sane in the web world. New generations of mobile devices are released like clockwork every year. Chrome iterates a new version out every couple months. Firefox took a while on 4.0 but still nothing compared to IE’s cycle, and is planning on speeding up.
The web is being held back by IE’s slow release cycle. Since we won’t see IE10 until 2015, and there’s still no auto-updating to speak of, we’re going to be supporting an already out of date browser into the next decade.
This is not acceptable.
“We generally don’t put implementations that are not stable into our final released browsers.”
and yet pretty much all the other browsers are able to put those in. hmmm…
Pingback:Rob Turner » Blog Archive State of the Browser
Valuable information. Lucky me I found your site by accident, and I’m shocked why this twist of fate did not took place earlier! I bookmarked it.
I’m just fascinated to understand what is not stable about the idea of being able to use a simple attribute to tag input fields with the ID of the associated form, rather than have strictly non-overlapping forms. Does any actually know? I hate the “its so dodgy but I wont explain” approach. Since there is still only ever one form for each input field I can’t see the complication – is it not a stroke of genius by the HTML5 guys.
Naively it seems a really simple concept, but incredibly powerful, and a final resolution to the problems of ASP.Net Form websites and their all-encompassing FORM tag.
Bemused.