A few years back I had to port an "ellipse segment" drawing command to a set of quadratic curves because that was all that actionscript supported and the segment was part of a longer path that had to be rendered as a whole path (filled). It took me quite a while to get the hang of it, and I documented the crap out of that code to never forget how it worked. But yes, the resulting code just chops everything up into smaller ellipse segments until they get small enough to turn into a quadratic arc.

I wrote an actionscript app 5 years ago that rendered SVG to screen using flash's drawing API, which looks a lot like canvas. None of this stuff is particularly novel, but then open standards aren't supposed to innovate, they're supposed to standardize the best practices.

I disagree.

SVG, Flash and HTML don't have a meaningful difference when it comes to their abilities or structure. All three are hierarchies of content nodes, changeable via dynamic scripting. That HTML and SVG use text to demarcate the nodes and flash uses binary blobs is of no consequence, because parsers don't care whether the symbols are text or binary. The fact that HTML is easier to index than flash is not due to any inherent quality of the technology, it's due to the fact that HTML is used for static content and flash is used for dynamic content. Gmail is made in HTML, but it's not indexable (and thankfully so!). It remains to be seen whether SVG's usage will be more static than flash. Quite possibly SVG could end up being just as difficult to index as flash.

I also don't quite agree that staticness can be determined by the absence of dynamic scripting. I think with svg filters and css styles you can do an awful lot of dynamic behavior that isn't actually scripted, similar to the pure-css popup menus that we've seen in HTML.

I think perhaps they get to play too much. The problem with modern society is overstimulation. Creative thinking requires looking inwards. You have to get into a state of flow and delve into your own mind for divergent solutions. As long as there's a never-ending stream of external stimuli, it's very difficult for genuine creative thinking to occur.

I find that I'm most creative when I put down the books, games, computer and everything else, and just sit somewhere quietly and think.

You do realize that flash internally manages a display object hierarchy not unlike the DOM? There isn't much difference between writing apps in flex/flash and writing apps in javascript with something like ExtJS toolkit. All rich app frameworks I know, on any platform, use the HTML-like approach of having an element hierarchy and a set of layout rules that are constantly re-calculated.

HTML may be ill-suited to rich app development, but so is everything else. Win32 and X11 are both truly horrible API's, arguably much worse than HTML+JS+CSS, but combined they hold the majority share of native apps.

And by the way, the browsers of today are designed for rich applications. They have been for a few years now. Cars were originally designed to make it up to a brisk walking pace at best. Things change.

JavaScript is not the problem for blind users, there is WAI-ARIA for that. The newest crop of screen readers can deal just fine with Ajax sites, provided they're wired correctly.

Also, I think the leap from the lightest mobile device to the heaviest desktop user is too big. You have to split your UI into a few key segments and optimize each. If you try to make a single UI fit all purposes, you end up fitting no purpose exactly right, and spend a lot more effort than when building a few dedicated UI's.

As long as you have to pay for mobileme, it doesn't really matter. One of apple's biggest blunders is not considering mobileme a loss leader.

ActiveX is a plugin API, the other guys all had one (netscape had NPAPI). What people blame microsoft for is ActiveX actually being successful, not the concept of browser plugins. ActiveX was used in apps to do stuff you couldn't do in HTML (and still can't do). Why not hold microsoft accountable for the stuff they did that was actually out of the ordinary? The main thing microsoft did wrong was not the development of proprietary features, but rather the complete lack of development between 2001 and 2006.

Saying "Microsoft is standards compliant THIS time" is just too much to swallow.

Cognitive dissonance hurts, but IE9 really is supporting standards well, focusing on open API's, and abandoning proprietary extensions. In IE7, 8 and now 9 they've gradually been disabling proprietary API's, and IE9 in IE9 mode will only have vendor extensions that follow the best practices we've come to expect from all the browser makers (vendor-specific name space, implementing features based on published draft specs).

Hardware-accelerated graphics are not a lock-in strategy, just like JIT-ing javascript engines aren't one either. IE9 will run the exact same code as the other guys, it will just run it faster. Notice how these demos are all compatible with all browsers, but just outline how much faster IE's implementation of the same standards is. It's up to the other guys to innovate and catch up. Firefox 4 will have hardware-accelerated graphics, Safari 5 already has it on the mac. Chrome will need to play catch-up for once.

Somebody has to go first with all of these things. The good thing with IE9 is that microsoft isn't playing the proprietary card. You may question their motives, but you can't question the results. IE9 (preview version) is a fast modern browser, with excellent standards support, and few proprietary extensions, aside from legacy support.

It's fast but can it render the page correctly? It doesn't much matter how fast it is if it doesn't do it right. IE8 is still a big turd - have they actually fixed IE9 or is it all smoke and mirrors by posting speed results?

That isn't my experience at all. My experience is that IE8 got the basics right. They support CSS2 as well as the other guys, or better. Yes, it didn't support next-gen web standards, but most of those weren't even standards when IE8 was in development. With IE9 it's all about the next-gen standards (CSS3, HTML5, canvas).

Many people seem to look at acid 3's score and assume that IE8 is a turd because of that, but as a web developer I have no major issues with IE8. Generally speaking, I can develop web apps without having to take extra precautions for IE8, unlike what I have to do with IE6 and 7.

I think the software submitted for testing is actually more secure than the average software, because it's made by people who actually know about the problem.

All web sites need to have good security. Without good security, you can get all sorts of hijacking attacks, where systems that seem harmless are abused to mount attacks on more sensitive systems.

The biggest problem with security is the degree it is underestimated. Everyone thinks it's somebody else's problem. Collectively though, the web is a one huge gaping security hole, and it's because of this attitude.

Most of the books on web development I've opened up contain security holes in the code samples. Even something as basic as SQL injection is still very prevalent in the code samples you find online and in print. Things get much worse when you start talking about subtler flaws like XSS or CSRF. And don't even get me started on the programming forums...

This article is most definitely not FUD.

It depends on the product, but there are indeed corporate customers who have policies disallowing them from purchasing / deploying software that does not pass independent security audit.

It's a mixed bag, and it depends on the market you're in. For some types of software, security is a non-issue. Security is like usability. You can always improve things, but at some point you have to say "up to here, and no further".

Well - thats it though, if someone is professionally developing with security in mind, they probably know how to test it in office or know somebody who can.

Independent security validation is the only way to verify that your approach to security works in practice.

support XHTML as an XML instance rather than as an HTML extension of an SGML instance. Then at last, I won't have to have a fix for <textarea /> , <div />, <script /> problems that arise after normalising XHTML documents.

More likely you'll just end up staring at "xml parsing error, mismatched tag" all day long. Honestly, why people ever started backing a way of working that completely breaks down with even the smallest vagueness in what crosses the wire is beyond me. Good design is liberal in what it accepts and strict in what it puts out. Generating valid XHTML but parsing it as tag soup, that's the right way to go about things.