Monday, August 10th, 2009

Microsoft dips toe in HTML 5 water

Category: Browsers, Microsoft, Standards

<p>Stephen Shankland pointed to Adrian Bateman of Microsoft speaking up in a W3C list on HTML 5.

Microsoft has been incredibly quiet until now (the IE team at least, Chris Wilson is in another team now) and so it is interesting to get a glimpse of their thoughts (and try to work out what they will ship in IE 9!)

To be honest there isn’t much to learn here though. This first set of feedback talks about some of the tags that are proposed… and there are a lot of them. It is quite easy to pick on the odd tag here and there to ask “do we really neeeeeed it?”

So, I am glad that Microsoft has joined the fun, and I look forward to more conversation. You know, stuff like: Are you going to implement Canvas guys? Web Workers? CSS goodness? Tell me you have a kick arse JavaScript VM ready to shock the world? Game on.

Related Content:

Posted by Dion Almaer at 6:55 am
35 Comments

++++-
4.3 rating from 22 votes

35 Comments »

Comments feed TrackBack URI

The mere fact that MS is so closed about IE development is indicative that we won’t get what we want out of IE9. You can’t develop an open platform with a closed team.

Comment by Joeri — August 10, 2009

Oh boy, let the wargames around MSHTML5 begin.

Comment by BonoboBoner — August 10, 2009

IE is toast. I’m basically ignoring it from now on and I really think it’s about time everybody did the same. Nobody is going to upgrade from IE6 to 7, 8, or 9. Anyone with enough sense to get a newer browser has surely heard of FF, Chrome, Safari, Opera, etc. I’m all for competition in the browser market (we’ve seen what happens when there isn’t any) but there is no reason MS needs to be a part of that competition ever again. There are enough contenders out there doing really good work to keep things fresh. MS cannot compete, cannot innovate, and cannot be trusted to adhere to accepted standards. They should be ignored by developers, standards bodies, and consumers alike. It’s time to move forward with the future of the web and no sympathy for Redmond.

Comment by okonomiyaki3000 — August 10, 2009

I wonder if MS is so resistant to changing IE because it would have to retool all it’s own webpages. Unlike Google which has GWT and can recompile its webapps. Maybe MS is being bitten by it’s own proprietary efforts. Just some thoughts.

Comment by tercero12 — August 10, 2009

@okonomiyaki3000: Did you read Digg’s poll results on IE6? The basic rundown was that most Digg users still use IE6 because they have no other option (i.e. locked down work environment). You should run some statistics on your website to see how many users you are alienating before making such a rash proclamation. I still have subscribing users to my website that are stuck on Win98. IE6 is the best they can do. I’m surely not going to alienate 30% of my subscribers even if it means a better internet. (Besides, I would probably lose my job if I did.)

Comment by tercero12 — August 10, 2009

IE is toast. I’m basically ignoring it from now on and I really think it’s about time everybody did the same.

@okonomiyaki3000: Yeah, good luck with that.

Comment by FunPackedShow — August 10, 2009

@okonomiyaki3000 – that philosophy could work if you have a site targeted at developers. But if you’re doing enterprise business web apps, dropping support for IE means dropping support for ~99% of users.

Comment by WillPeavy — August 10, 2009

Regarding “section”, “nav”, “article”, “aside”, “header”… Adrian Bateman from IE wrote – “It’s not clear why these new elements in particular are necessary. Those that use HTMLElement for their interface provide no extra functionality beyond or .”

Is he kidding? He really can’t see why having a standard for elements that exist in nearly all web pages would be a useful addition to a markup language?

Comment by WillPeavy — August 10, 2009

Maybe they should dip their toes into the rest of CSS2 first.

Comment by pendensproditor — August 10, 2009

@WillPeavy

I’ve got to agree with Microsoft here, section, nav, article, aside and header provide nothing we can’t already do with Div tags, ID and Rel attributes.

It’s placing value where unnecessary, plus I strongly disagree with the Nav tag being that navigation could be handled anywhere in the page, such as in the Header.

All I need Microsoft to do is support the Canvas, Audio and Video tags, SVG format, CSS rounded corners and the database api and I’ll be happy.

Comment by HughIsaacsII — August 10, 2009

New tags in HTMl give more symantic meaning to page markup which is clearly useful.

If IE doesn’t increase it’s JS performance ten fold in the couple of years it will be in alot of trouble as web 3.0 unfolds.

Comment by mrfator — August 10, 2009

“Maybe they should dip their toes into the rest of CSS2 first.”

@pendensproditor – Um…Internet Explorer 8 is currently the only browser that fully supports the CSS 2.1 specification. That’s right, It has better CSS2 support than Firefox, Safari, Opera or Chrome.

Now, there’s many many other shortcomings that make it suck compared to other browsers (CSS3, SVG, upcoming HTML5 features), but CSS2 is the one thing they finally got right in IE8, and they deserve to be recognized for that.

Comment by Fyrd — August 10, 2009

Don’t discourage okonomiyaki3000. I believe that it is possible to drop support for ie if your web app is really cool and targets “cool” people, or at least those who are in desperate need to be cool (teenagers, for example).
Message that you’re not cool enough to join my party if you’re using ie could work on some apps. The only problem with that is that you need to make a killer app…..

Comment by mare — August 10, 2009

Screw IE6 users, as a developer I’ve suffered for far too long, now it’s their turn.

:-)

Comment by RoryH — August 10, 2009

@okonomiyaki3000
Where is the VOTE button Dion…!!
I would SO much like to vote this guy UP!!! :P
.
Totally agree…!

Comment by ThomasHansen — August 10, 2009

Ohh yeah, in regards to “loosing users”…
15 years ago only a fraction of people even HAD a computer, did we “loose users” back then because so “few people” had computers…?
.
I’d rather spend 75% of my development time doing something ELSE than fixing Redmond bugs, even if that means loosing 50% of my users. It’s plain and simple math … ;)

Comment by ThomasHansen — August 10, 2009

Personally, I’d rather they’d start with implementing the stuff that’s been out there for years, like W3C DOM events and XHTML with XML mime type. It would also be swell if they could have a DOM that doesn’t give its best imitation of a snail as soon as you move past trivial hello world pages.

After they’ve done that, they need to add in canvas support, svg support, web workers, html offline, and a fast javascript engine. Then they’ll have parity with the other guys. Then, to not be outclassed from the release date, they need to go beyond that and implement local database storage, and html5 form controls.

In short: never gonna happen.

Comment by Joeri — August 10, 2009

@Fyrd Yeah, but how much of that CSS2.1 specification that IE supports is stuff they specifically added to the standard, just so that they could claim they “supported it better?” ;)

Comment by mdmadph — August 10, 2009

I seem to be one of the less non-ms-fanboys who think the microsoft action is good. As far as I can tell the WHATWG / HTML 5 standard process is open for everyone and everyone can suggest features and improvements.

MS has a lot of skilled programmers, so what makes everybody think that it is a bad idea.

When MS suggest a new tag to make some stuff easier for everyone, then the other browser guys will look over it and have a smart discussion about that.

That “feared” tags like <directx&rt; are never ganna make it into the next standard is crystal clear.

Comment by Aimos — August 10, 2009

@HughIsaacsII –

“plus I strongly disagree with the Nav tag being that navigation could be handled anywhere in the page, such as in the Header.” —- Huh? There is no restriction on nav being placed either inside or outside of header. ( http://dev.w3.org/html5/spec/Overview.html#the-nav-element )

“I’ve got to agree with Microsoft here, section, nav, article, aside and header provide nothing we can’t already do with Div tags, ID and Rel attributes.” — But why continue using instead of ? Where’s the benefit in that? The purpose of markup is to describe content. If there was a standard element to describe navigation it would be a big win for accessibility.

Comment by WillPeavy — August 10, 2009

“But why continue using instead of ?” — HTML was stripped should be … why continue using <div id=nav> in place of <nav>

Comment by WillPeavy — August 10, 2009

I really don’t need IE to support the new semantic tags (header, nav, etc) because I am probably already going to explicitly set their display types in CSS for other older browsers, so no biggie. My suspicion with MS entering the standards process is that they seek not to improve and implement the standard, but to delay and weaken it while they advance their own alternative. I’m reminded of their efforts in the ODF standards while they advanced their own XML document format which was ‘open’ but patent encumbered and not very interoperable with other suites. Canvas, offline storage, audio and video tags seem in direct competition with silverlight. I feel pretty certain that MS’s aim here is to delay and weaken the open technologies so they can keep their dominant position intact with IE and silverlight.

Comment by tack — August 10, 2009

@WillPeavy

I dunno, I feel there should just be an attribute for describing content not a whole tag.

Especially if it’s for machines to read. Google already supports microformats, why make an entirely new standard for this?

Comment by HughIsaacsII — August 10, 2009

@Tack

I don’t think Microsoft is opposed to web standards because of Silverlight. Those features aren’t why people use Silverlight and they could actually be of benefit to Silverlight.

Plus despite them being notoriously evil, I think they’re smart enough to know not to repeat Adobes moves by only providing functions that the web will most likely support.

I think Offline Storage, Canvas, SVG, Audio and Video are in the pipeline for future IE versions (especially since IE already has features that are similar to these functions). Silverlight is more geared towards making desktop like applications for the web, things that even HTML5 can’t do.

It’s more of Silverlight vs Googles Native Client, not Silverlight vs HTML5.

Comment by HughIsaacsII — August 10, 2009

Actually I agree with MS, the comments are right. MS is really good at making standards (who has dealed with .Net Framework will understand me) and it’s really pity that MS has such a low impact on HTML5. Really why not to add , , , , . If to make set of elements, than to make it right or not at all.

Comment by Headlong — August 10, 2009

I mean why not to add:

, , , or .

Comment by Headlong — August 10, 2009

lol, it’s not easy without preview button, so what i wanted to write was:
“chart”, “treeview”, “breadcrumb”, “toolbar”, “sidebar”, why not to add these elements too? :)

Comment by Headlong — August 10, 2009

I think it’s hilarious that whenever IE is mentioned, the comments light up. So here’s mine…

I wouldn’t be happy enough with HTML5 support, nor even a JIT JS (though that would be a start). Fact is, their rendering engine sucks. I just did some browser speed tests (you can see on sitepen’s blog) and there are indications that IE’s performance is actually going backwards. They are still patching the same thing they wrote for 4.0. They need to start over and do it right. The fact that they don’t know the value of a ‘nav’ tag tells me this is not the plan.

Comment by AnM8tR — August 10, 2009

@WillPeavy and those who are in favour of new tags. I wonder if this is a classic market regulation situation. It is a fact that ridiculously complex web applications have been built without these tags. It is not really controversial to say that they are not necessary — the argument for them being necessary would need to prove that their absence hinders something of universally agreed upon value — internet usage, innovation, browser compatibility. It is unclear to me how that argument could be made. The reason that argument is difficult to make is that history has shown that participants in this market (the internet) have found ways to deliver what they intend and to receive what they desire. Browser incompatibility brought us $. $ has validated javascript as a development language. The bad parts of javascript almost forced the discovery of $. Selectors lasso loose taxonomies — a tool born of a need. Javascript muckery brought us css-only foldout menus. In robotics great advances were made when it was realized that the problem with robots is that they try to be *perfect* — when you *accept* error, missteps, mistakes, entities learn, empathy and collaboration being the result; when you insist on a set group of patterns, entities replicate, with great prejudice therefore inherent in the system. So, would you rather have a fixed way to define a page, or JQuery? And just who does it benefit to introduce yet another incongruity, between browsers which support this large set of unnecessary tags and those which do not?.

Comment by nataxia — August 10, 2009

I think Microsoft lost interest in the browser after they killed off Netscape. It doesn’t really matter now that other browsers have taken share away–the browser war is not Microsoft’s biggest problem now. That’s a war from long ago, and IE doesn’t make any money (directly).

Microsoft has bigger fish to fry. I think IE progress will be ever slower.

Comment by Nosredna — August 10, 2009

The proposed tags that Microsoft thinks may be unnecessary are provided so developers can include additional semantic meaning in web application markup for common tasks. Microsoft is asking a stupid question, but also asking a great question; but they’re passing it off as if the two are interchangeable.

The stupid question is whether the proposed tags are necessary. Of course they’re not strictly necessary, but I think it’s self-evident that the bulk of the proposed tags semantically describe very common use cases—this is the basis for all of the existing tags besides div and span, and proposing them is consistent with the purpose of the HTML standard.

The great question is whether the set of tags proposed is the right set… whether there are equally “necessary” tags being left out. Headlong’s question—why not add “chart”, “treeview”, “breadcrumb”, “toolbar”, “sidebar”?—is addressed somewhat by the specification: “treeview” is handled by the datagrid element, “toolbar” is handled by the menu element, and the meaning I think you intend for “breadcrumb” is handled by the nav element.

“Sidebar” (in document structure terminology) is handled by aside, but I’m fairly sure that’s not the sense you mean; the design element “sidebar” can be handled by any of header, footer, nav or section (depending on semantics). Adding the semantics of “sidebar” (again, as distinct from that handled by the aside element, which has a structural meaning distinct from what I think you mean) introduces semantics that are presentational rather than descriptive or structural. That runs counter to the purposes of the HTML standard. (Note that header and footer carry semantic and structural meaning in a document regardless of their design placement).

I’m unsure of the semantic meaning of “chart” and how that would be defined, but there are the figure element, the table elements, as well as the embedded elements such as img, canvas, video and object all of which might represent “chart” in some way.

Something to keep in mind is that nearly all of the proposed tags for HTML 5 have the quality that they provide additional semantic structure while replacing non- or less-semantic markup (eg. section replaces div#section; input[type=date] replaces input[type=text].date). I think a “chart” element, in particular, would come with the cost of an additional level of structural hierarchy with unclear semantic benefit.

The comment that any of the proposed elements could be provided by div.semantics or span.semantics betrays a poor understanding of the purpose of any of the existing tags. The argument, taken to its logical conclusion, would lead to the elimination of all tags besides div and span, in which case all semantic meaning would be derived from ids, classes, specified and non-standard attributes. At that point the markup structure becomes essentially domain-specific like XML, with the terms div and span serving as unnecessary noise (essentially extended angle brackets) with absolutely no semantic structure at all.

The cost of that attitude is pretty clear: any kind of machine processing of HTML documents for any purpose besides dumb parsing—anything that would rely on semantic structure—is an exercise in futility, or would require exaggerating attribute semantics and expecting authors to adopt markup standards specified outside the official HTML standard. I’d much rather be able to parse the article and nav and hgroup elements of a document than rely on the goodwill of authors to add those class names to anonymous block and inline elements. This will become increasingly relevant as the web becomes increasingly interdependent, interoperable, and as the tools for content creation increase in quality.

Lastly, Microsoft’s participation in the standards process should be welcomed. The web being what it is today, any standard crafted without Microsoft’s participation is likely to be a nightmare from a practical standpoint, as they simply won’t adopt the standard until forced. That said, I think their specific comments by and large betray a poor understanding of the purpose of HTML 5 semantics and direction, and perhaps questionable motives regarding the development of open web standards as a hospitable environment for increasingly complex applications.

There are some points I agree with them on, and I’ll list those in shorthand:

- the dialog element (this is already handled as specified in HTML 4/XHTML 1.x by the dl, dt and dd elements)
- there ought to be a currency element (inline, and a form element would be a necessary corollary)
- progress attributes/contents as recommended
- I don’t really understand the keygen specification, but I’ll take their word on it
- time zones
- discovery of bb
- manifest for standalone applications
- UndoManager

Comment by eyelidlessness — August 10, 2009

Ok, I get it, it’s a great discussion until Microsoft asks a question? MS is not the only one that has questioned the use of the new semantic tags. Granted MS is late to the game so a great deal of that discussion has already been hashed out but HTML5 is not a standard yet so anybody should be able to join in without being trashed just because one doesn’t like their past actions. At least they’re now in the game instead of just ignoring it like they’ve done for years.

Personally I’m not sold on these new tags either. I’m not sure I understand the purpose of them so maybe someone can enlighten me without telling me I need to learn my sh*t. I understand the idea of the semantics but who are they for? If they are for developers then there’s no reason to not stick with the current method of using ids and classes with a particular naming scheme. If they are meant for computers (search engines) then attributes would do the same thing or getting the search engines to agree on naming schemes for ids and classes to look for. I guess one major issue for me is that if we can create new tags with whatever names we want for semantic purposes then where does it stop? Are we possibly going to have dozens of new tags to consider down the road? And then dozens more as people decide on reasons for newer tags? If so, why don’t we just go the xml route and let the developers name their tags whatever they feel like? That’s good semantics for humans but possibly bad for search engines. So again, who is the target for these semantics?

My comment for MS after finally stepping up with HTML5 is not stop with the next version of IE. Get an understanding of HTML5 with their tests then release a patch for IE7 and IE8 implementing the same HTML5 capabilities that recognizes the plain HTML doctype. Therefore, when the standard is ready we don’t have to sit around for ten years after that waiting for enough people to update to IE9 so we can finally start using HTML5 properly without doubling or tripling our workload.

Comment by travisalmand — August 10, 2009

@eyelidlessness

Take your well-worded, rational approach somewhere else! This freetard comment stream is not the place for that kind of thing…

Comment by thnkfstr — August 10, 2009

@travisalmand
The more sematic based HTML5 is for numerous reasons including :- better understanding between development teams, better processing for search engines and better processing for assistive technologies. Remember that Web 3.0 is the sematic web with information being gathered from multiple resources. That is more easily accomplished with standard named and understood tags.

Now the question about http://ishtml5readyyet.com/ is how you want to look at it. October this year is the last call for the working draft, which now because of Microsoft will probably be delayed a bit. During 2012 is when the full spec is supposed to be finished, including test suite. The 2022 date is a guess when at least 2 browsers will fully implement all of HTML5 properly.

You can create HTML5 pages now, but not many users will see them. People are creating Javascript libraries to assist current browsers in some HTML5 features, and the good browsers are implement parts of HTML5 now. By 2012 this situation will be even better, except of course for the legacy Microsoft browsers.

Now last year I saw a video on the channel9 website with some of the developers of IE8, and one let slip that their next html engine is called Triton. The current one is Trident and is still based on some of the code from IE3. So if we are really lucky maybe IE9 will be using the Triton engine and maybe that will do canvas, some CSS3 etc.

But Silverlight looks like the DirectX SDK etc. for IE6, so maybe it’s a migration path for those corporate IE6 users to IE8, while still keeping them locked into the Microsoft world. Microsoft will still get income for licenses and certification training and tests.

Comment by GordonStanton — August 10, 2009

in a way, this entire discussion about what tags to add to html5 is an exercise in futility. i have just done a website using *nothing* *but* non-standard tags except , [title/], [script/], [style/], [body/], [img/], and then some—all other tags were non-standard ones. in the css i hvae to explicitly declare display:block for the block-level tags, and apart from that, everything including layout, display, jquery works like it should.

we will never agree on one fixed set of tags, and this is a good thing. it is like printers had agreed on the one right font or the only true way to layout a book 500 years ago; they didn’t, and it is good. you may argue against the applicability of [nav/], and i do choke on some of the proposed html5 elements, but then for the next guy a [red-gold-and-green-bug/] may be what they need to build their page. you cannot know this in advance.

i believe that we should start to see css (with all the problematic aspects of it, but still) not only as a place to define the appearance, but also a place to define the role of an element. today’s web page writing business has gone so ridiculous with all the [div class='foo']…[/div] stuff, and, as has been pointed out in the discussion above, once you start doing this a lot, [div/] and [span/] become nothing more than obnoxious stand-in-your-ways, scaffolds to hang your banner, the (principal) class attribute.

this is ridiculous and has only been done so some asstight guys can sit on some specs and demand validity. when they invented sgml to organize documentation for boeing 747s inside a corporation, that sure was the way to go.

but then, not a single one of the world’s top 200 most visited web sites validates (can someone find that link?). some things like link areas or embedding video you cannot even make work and validate at the same time!

xml has a long historic record of doing ‘namespace redirection’, which is one of the reasons that whereas in a windows ini file you just say `foo=42`, and in a json file you’d say `{“foo”:42}`, you’d have to say `[key]foo[/key][integer]42[/integer]` in an apple property list xml file. note that out of three formats shown here, only xml thinks this kind of indirection is the thing to do. the other formats have their own limitations to be sure, but it is only xml that insists on this kind of tight control.

with todays html/css, you can already give the `display` property one of these role values: `block`, `inline`, `none`, `inline-block`, `list-item`, `run-in`, `compact`, `table`, some of which are actually more or less or then again not really (a) useful, (b) supported, and (c) working (in some browsers). what the w3c in their finite wisdom wanted to share with the world when they introduced `run-in` remains anybody’s guess (quirksmode.org for one does wonder), but in principle they did the right thing: have the css declare what role a given element should play on the page. too bad they never added roles like `image` or `audio-player`, which is why you can write 90% of your home-brewn html today, and get it work, except you still have to use [img/] for the images. same with all other tags that have side-effects, like [title/], [head/], [body/]; [a/] you can simulate using javascript.

why would anyone want to do this? well, just because we can. for a big majority of people, sticking to their [p/]s and [h1/]s will be just the thing to do. but for some purposes, and this includes all those cases where today we write this ridiculous [ul class='nav'][li]home[/li][li]order[/li][/ul] stuff—having a navigation element parade as an unordered list, then use visuals to make it appear as buttons or anything else—anything *but* an unordered list, this is—moving to [navigation][anchor]home[/anchor][anchor]order[/anchor][/navigation] will actually improve semantics. yes i know know people cry that since those tags have never been sanctioned by a standards body nobody knows what they mean, or where they’re allowed to appear. to this i answer: where is it written that today we should be using [ul/] for navigation? where in the html, the css, or the w3c specs can i find any hint that this kind of [ul/] is used for navigation? people call this ‘semantic’ yet they give fully arbitrary, chosen-at-will, and undocumented, css class names to their unordered list elements and make them visually appear as navigation elements. this is just as semantic as your neighbor’s new-born puppies. unnamed but barf they will.

the answer to validity and semanticity, my guess, lies in doing the following: (1) reduce html to a very few tags, (2) define a set of roles to be used in css, (3) extend css so you can define tags-with-side-effects à la [img/], like i can picture something like this to work: `my-image-tag{display:image;image-source-name:src;}`. other roles could be `video`, `audio`, `page-title` (yes, define your page title in the middle of your document), `style` (the w3c wants us to stick those in the [head/], but then they seem to work in all browsers no matter where they appear), `script`, and so on. plus, how about purely functional roles, like `act-as:navigation`? isn’t that infinitely more useful, extensible, and open than most of the tags being under discussion for html5 at this point in time?

this is not ideal, and still leaves open the big question why it is that i *can* define a background image wether in the html or in the css, but am encouraged to define it rather in the css, i *must* define the source of an [img/] tag in the html. sure people say it is because the [img/] tag defines an essential illustration to the text, while a background image is just decoration.

reality often does not work that way i’m afraid. how often do you use an image inside an [a/]nchor, the classical way, only to find out later you prefer to make the [a/] appear as a floating block-level element with size and background? see how terribly semantic all this is? how form and content are neatly separated? wow.

Comment by loveencounterflow — August 12, 2009

Leave a comment

You must be logged in to post a comment.