12
The IE team speaks HTML5 on W3c List, better now than never?
Microsoft finally decided to share the IE team thoughts on HTML5, unfortunately their feedbacks are mostly negative, and are a bit late for some elements they are arguing.They review a lot of “established part” of the recommendation, and would they have joined the discussion before this point, most of their feedback would have not been necessary today.
It is unfortunate that they do not speak about canvas, audio and video tags. These tags are a major update over the HTML4 specs. Some people (including me) think that they will not implement these tags because of the competition it would provide to Silverlight, which they have been trying to bring to the global market for years.
Actually saying that they will not implement these would be a PR nightmare, every web news outlet would squash them to ground. If Microsoft choose this path, we might not hear about them for years. It would also prove difficult for video providers to implement a generic HTML5 solution if Microsoft is not implementing the video tag (or implement it in 2022). You can see the entire Microsoft post here.

But let’s go a bit in details,
On the <nav>,<aside>,<header> and alot of other tags, Microsoft says:
“It’s not clear why these new elements in particular are necessary.Those
that use HTMLElement for their interface provide no extra functionality
beyond <div class=”xxx”> or <span class=”">. If they are necessary, do
we know if this is the correct set? Are there any missing? “
A bit late? Of course they are useful, theses tags are providing a better HTML semantic, it will prove useful as web developer will be able to indentify website sections more quickly. It is really easy to ask if these elements are really useful, this is why this has been a debate for years on the W3c list. Personnally I feel confident that the current new set of tags will be useful.
on <keygen> Key/value pair generator control. Microsoft says:
“<keygen> is based on an old Netscape implementation and is very basic. It’s not clear that it is widely adopted today. We have some concerns about including <keygen> in the spec. We’re not sure this is the right design to be encouraging given that it wasn’t in HTML 4.01.”
I find very weak their remarks on the fact that this was not part of HTML 4.01. When this spec was created, the web was not about complex forms, web2.0 apps and captcha, and while Netscape was maybe to much ahead of it’s time with this tag, the web needs have evolved in a very complex entity where this tag will prove useful.
On event handling (ondragover, onmousemove, onbeforeunload, ondragstart, etc), Microsoft says:
“The potential risk of supporting all of these events is that websites
could hijack events and confuse users with inconsistent experiences. For
example, developers could create their own dialog that is displayed when
the onclick event takes place.”
I do not see how this is a change of the current spec, we can already hi-jack via JavaScript, this issue will not be resolve easily.I think that the level of customization these events will provide is really important for web application to grow in the future.
Conclusion
Can you see a pattern in the IE team feedback? There is mostly no solution proposed on these issues. This is puzzling me, if you are Microsoft and will go into the trouble to finally post something on the W3c list, would you not at least try to provide solutions to issues your are seeing? Maybe it’s in a post to come.
15 Comments to “The IE team speaks HTML5 on W3c List, better now than never?”
Leave a comment
Articles
Some Tweets
- good day today, did an autocomplete widget that use the binary algorithm in pure JS,
- doing a pure js widget.. it's like going back 5 years ago
- Inspire the web with just 10K. A competition from ALA http://10k.aneventapart.com/
- binary search rock large javascript array
- Photoshop just crashed on me, been a while...
- Introduction to the Google WebFont Loader and how to avoid @font-face text flickering with it http://bit.ly/at8Pus









Its so Ugly to see them speak on these issues….. how are they not ashamed to open there mouth on these issues, looks like they REALLY understand how a browser should render a page…..
Oh boy, I smell another 10 years of frustration and hacky solutions to non-supported features!
I guess I’ll be the fan boy for today. I saw them asking a lot of questions about the direction HTML5 is headed. That’s a good thing. I think a lot of questions need to be asked. I have very little clue, as do most people as to the direction of HTML5. Not much has been said, an article here or an article there… but not much. I find the explanations vague and a little geeky at times. If you’re going to dumb down the web to the point where HEADER & FOOTER are so obvious, why not give a decent explanation on all of the features.
Well we have another 13 years right? The web moves at the speed of light and it’s going to take 13 more years to get this done?
Why does IE always have to be such a pain to everyone?!!
@Anrkist The W3c HTML5 discussion is open to anyone, those tags has been put in the spec after some good discussions, this is not something that has been decided lightly. There is always some good reasons to implement or not a feature, the problem, I think, is that Microsoft do not participate to this discussion.
Every other browser vendors are implementing and testing CSS3 and HTML5 features a lot faster than IE. If Microsoft was active in this discussion as the other browser, you would not have to wait 13 years to have those features implemented.
I hate IE as much as the next guy, but I have to agree with Anrkist & (I can’t believe I’m about to say this…) Microsoft. HEADER, FOOTER, ASIDE etc have absolutely no place in the markup, when they essentially all serve the same purpose as a DIV.
“it will prove useful as web developer will be able to indentify website sections more quickly”
This isn’t really the function of a HTML tag, Cedric. HTML Comments are there for us to make code more human-readable, but the HTML itself is there to be read by a browser.
If the browser is going to treat a HEADER the same as a DIV and a FOOTER and an ASIDE, why should we have 4 different tags when adding class=”header” would do just fine.
Are we gaining any extra functionality from a HEADER element that we can’t get from DIV class=”header”?
When does the hurting stop…
Strange that you hear MS talk about innovation…. they clearly have a whole other interpretation about it than the greater part of the community.
btw microsoft? How’s DOS doing? Still running, nice…. very nice?
Did yout read the whole text Microsoft posted? There are many points where I totally agree with MS.
The point of MS with unnecessary tags is that they do not behave different than normal divs and that the spec is not detailed enough. Are you allowed to user more than one nav section? Sure. But is there a way to determine which of these sections is the primary navigation that is intented to be used by screen readers or search engines? Nope. So what’s the point with these tags? Semantic tags only make sense, if you are able to determine the semantics
Like h1…h6. Those are clear. With nav it still depends on the human to determine the meanings.
The comment about header / footer makes sense, too. Those two would be perfect for printing, but there’s no word in the spec how exactly or if those tags affect printing.
I just don’t get the keygen tag at the moment. It seems to be about creating certificates. If so, it doesn’t matter if we have complex forms, web 2.0 or captchas. I guess I need to read some more on the topic, because currently I don’t see any relation between the tag and yout comment.
Your point about the events fails completely! Seems like you didn’t read it properly. That paragraph is in the feedback to the bb tag. That one is supposed to be inside the body tag and should have all the usual events which in their view is a security risk. They suggest to put a link tag with a reference to an application manifest in the header part, so it’s not part of the DOM. I fully second that. There’s no sense for meta information to appear inside the body.
It seems to me, that most of the commnentators on this post didn’t read the post. So here we have it: http://lists.w3.org/Archives/Public/public-html/2009Aug/0389.html.
Additionally he doesn’t say “we don’t implement it”. He is about “we have concerns if this is the right way”. And if you read the replies you will find, that Jonas Sicking of Mozilla shares at least the concern about the bb tag and that it won’t be implemented by Mozilla! Another point the IE team mentions (the datagrid) was removed from the spec the same day. HTML5 is not finished yet, it’s still in the works.
Well it give us a standard way to use tags in our semantic, that said you guys have valid points, I totally agree that Microsoft has valid points, the semantic tags are not perfect, but for now this is what has been chosen.
And you know what? If this is a first of a long series of posts from the IE team, I will be happy, we certainly need them there! But if they are gonna step out of the closet one time a year and say, we have concerns about that, fix this, and go away, for me, not good enough!
The IE team speaks HTML5 on W3c List, better now than never?…
Microsoft finally decided to share the IE team thoughts on HTML5, unfortunately their feedbacks are mostly negative, and are a bit late for some elements they are arguing. The IE team could have argued these elements long a…
Controversial?
If Silverlight is their reason for not implementing it then perhaps then HTML 5 developers should adopt the same stance that Microsoft do.
If a user goes to a Silverlight website but doesn’t have Silverlight installed, they’re greeted with a ‘please install Silverlight’ message. What’s to say that HTML 5 developers can’t do the same? “Please upgrade to a standards compliant browser such as ___”
The only difference is that Microsoft have the advantage of being able to disguise Silverlight as an ‘Important Update’.
I can’t believe some of your are missing the point with tags such as header, footer, aside, section. It not only makes your markup much more meaningful, but it makes your CSS easier to read as well. Dozens of IDs and classes will be able to drop out of the markup!
Isn’t this exactly what we’re trying to solve with Microformats? To give more meaning to something which has none? div div div div div div. Search engines could start spidering things differently, disability devices could get users to what they’re looking for faster.
Everyone should actually create a page in Html5 then style it before they comment on it.
-Tateman
[...] The IE team speaks HTML5 on W3c List, better now than never? [...]
From what I can see the point isn’t to just replace divs for readability for the coder but to make it more obvious in a standard way what section is what so that programs may understand the relevance of each part of the page and better index it.
It may seem pointless now with today’s technologies, but surely it creates potential for new, more intelligent applications in the future. After all, what I call you may call at least this way we’re all doing the same thing.
* what I call div id=’top’ you may call div id=’header’
example tags got stripped