I assume the parent was referring to IE's use of pointer events instead of the touch events. While many may accuse Microsoft of trying to split the web, this move was most likely done for two reasons.
- Apple has been working to patent touch events
- The ability to simplify event handling with one type of event that is input method independent -- working for mouse, touch, and pen.
As a web developer I find the pointer event method to be technically superior to touch events. At present, patches to add pointer events to Blink-based browsers (the patch might have been added before the split from WebKit) and to Firefox exist, but I do not believe they have yet landed in other browsers. Sadly, with the lack of touch events it does bloat up code to support two different event models for touch browsers at this time.
Actually, IE's ability to use their old rendering engine only goes back as far as IE7, not IE6. It's funny, given that quirks mode is really IE5.5 rendering you can test every version of IE from 5.5 up except for IE6.
Going back to the VM solution, Windows 7 Professional users are allowed to download something Microsoft calls Windows XP mode (using Virtual PC) and can create their own VMs of XP that do not require you to purchase another license. If you truly need to test in IE6, IE7, and IE8 all you need do is run all of the updates for XP for IE6 but do not install IE7, then copy that VM and run the update to IE7 and run the updates for that but do not install IE8, and then create another copy where you upgrade to IE8.
Windows XP mode is not available on Windows 8. Yet another reason why businesses may hold out on upgrading
If the developer opportunities are good, i'm in. Problem is, calling something an App Store doesn't really change things much if you're just giving people access to a web site. Maybe they're going to focus on local apps written in html+css+js?
What you're looking for are called W3C Widgets. W3C Widgets currently run on Opera, and Vodafone, while T-Mobile and the Nokia S60 have have near standard W3C Widget implementations. It looks like Android is working on it, but Apple is doing everything in their power to fight this (all while touting how great HTML5 is).
The bottleneck is mostly implementation, not standardization. For instance, Firefox 4 is going to be the first good implementation of HTML5 form enhancements, and those were first standardized in Web Forms 2.0 – in 2003. The spec hasn't changed all that much since then (although it has changed), and has been stable for years, but none of the major browsers gave it high enough priority to implement it well. Browser implementers have lots of things to do, like revamping UI and improving performance and security, and they can only implement so many standards per release. Then, of course, they report back all sorts of problems with the proposed standard, so it has to be changed, then changed again.
Correction -- Firefox 4 is going to be Firefox's first release that begins to support the HTML5 form enhancements. Opera has already supported those form enhancements since version 9.5.
Have the Feds, or any other major service, looked at using DOM Storage as an alternative to cookies? DOM Storage allows for more data to be stored, and it removes extra data being transferred via every HTTP request. Yes, it is only available in modern browsers, but that need not stop its use, or at least making policy towards its use.
CSP is effectively server-side NoScript. And it isn't exactly new either. This has been in development as a Firefox extension for at least a year. The article mentions it being first crafted back in 2005.
The issue I take with this article is that they suggest this feature could even possibly be integrated into eBay or MySpace. These two giants seem like the exact opposite type of market that would use this -- any site that allows users to post their own data is not going to possibly survive the wrath they would catch if users had to explicitly allow the domains they want scripts to run on. For a corporate Web site yes, but for something for the masses or those of us that run a CMS? I don't see that as happening anytime soon.
I am honestly torn on the idea of CSS sprites. While yes, they do decrease the number of HTTP requests, they increase the complexity of maintaining the site. Recently, Vladimir VukiÄeviÄ pointed out how a CSS sprite could use up to 75MB of RAM to display. One could argue that a 1299x15,000 PNG is quite a pain, but in my experience sprites end up being pretty damned wide (or long) if you have images that will need to be repeated or are using a faux columns technique.
Some times it gets to be a better idea to make a few extra initial requests, then configure your server to send out those images with a far future expires header (which you should do for the sprite anyway). At that point you're just talking about the initial page request, and then subsequent visits get the smaller sized. With one site I am working on the initial page view is hitting 265 KB on the initial view, 4.75 KB for the next month.
I don't see this mentioned anywhere, but Google has already switched to the HTML5 Doctype. It is much shorter the other flavors.
- Defer, though being a part of the HTML 4.01 spec, is only supported by IE. And even if other browsers supported it they could not use it because they need to know that the content had been loaded before they execute the tracking code.
- The vast majority of developers just copy and paste the code as given. This code is an internal script tag that derives the protocol that is currently being used to then refer to the HTTP or HTTPS file using document.write, and then a second internal script tag that starts the tracking using your unique id while inside of a try/catch block.