The current state of things is that the following editor drafts are separated out from HTML5:
EventSource API.WebSocket API.Meanwhile DanC created an initial draft that will lead to splitting out the URL section as detailed in my last post. I did some testing on CSS URL handling and found out it uses exactly the same algorithm as HTML5 in user agents except that the URL character encoding is always set to UTF-8, just like it works for XMLHttpRequest. In light of this it would make sense to simply revise the IRI specification to make more sense, but there are not enough proponents for that apparently as it would affect e.g. Atom. I guess creating a separate IRI specification (which is what the HTML5 URL handling is) creates less theoretical issues… I wonder though whether anyone has actually tested Atom clients. Do they really refuse to handle spaces in URLs? Do they really do the right thing per the IRI specification and normalize URLs when the encoding of the feed is not a Unicode encoding? Do any clients that handle IRIs do that properly? I doubt it.
It seems every time I turn around parts of HTML5 are being separated out. Won't the diluted specification lessen the impact of the HTML5 name?
Really it's just a marketing tactic. It's easier to say HTML5 than HTML5 and Server-Sent Events and Web Storage and The Web Sockets API and The Web Socket protocol and ...
Yeah, some people are thinking about a new name. Web 5.0?
No no, we need to market this. How about "Shinygem", "Twinklestar", "Gloss", or "Lensflare"? Or we could go the other direction and call it the Open Web Content Presentation Foundation Standards Collection. Something with that many big words can't fail to sound impressive.
I would say let's make HTML 5 as tiny as possible, but not tinier.
The modularization of the CSS3 specification hasn't lesened the impact of "CSS3" as a name but it has helped the industry keep better track of the status of different parts of the specification and their implementations.
To my knowledge, every other current browser (ie, chrome, safari, ff) has some implementation of webstorage. Last I heard you (Opera) were waiting for the spec to mature. What state do we have to wait for webstorage to get to before we can expect to see it in Opera?
Server-sent events is low priority until there is more interest from other vendors. Web Storage is relatively high priority, but post Opera 10. Having said that, please ask these questions on some more appropriate forum next time. My blog is hardly the place for it.