You act like google and mozilla are competitors. They're not. There's nothing mozilla does that competes with google. Both are working towards a larger and more capable web, and google has bet the farm on that web becoming the de-facto application platform. Mozilla's activities are a benefit to google, not a risk.
In essence, google is getting a very cheap deal with mozilla, and they know it (which is why the contract has been extended twice so far, and will likely be so again in the second half of 2011).
Do they? They win if people visit Google properties. Whether that needs multiple high quality browsers is debatable. It probably does need _a_ high quality browser
Competing browsers advance the state of the web art faster than a single dominant player. Google entered the browser market not to win, but to increase competition. Mozilla has much the same goal (firefox is the reason microsoft restarted IE development). There's no denying that the competition in the browser space is fierce and that this is leading to rapid iterations of these browsers.
That's nonsense. I was bullied heavily as a child, but I'm not insecure anymore. Every victim has the choice to overcome the lack of confidence that being victimized gave them. We should stop treating victims like victims. Send them to karate class! Make them talk to large audiences! Why do we correct only the behavior of the bully when the behavior of the victim is just as much at fault?
You might argue that webkit doesn't need HTML anymore either (except for the canvas tag). Canvas and javascript can render anything, like the bespin web-based code editor, which uses only canvas.
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.
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.
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.
These tests were submitted by people who NEEDED to have their software tested.
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.
Much of the software out there doesn't deal with sensitive data, and much of it is too simple to serve as a system security risk
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...
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.
Actually, microsoft's recent track record with the W3C is quite positive. In IE8 they implemented full support for CSS 2.1 (they even released a large test suite to help the other browsers improve their CSS 2.1 support) and a decent level of support for WAI ARIA (accessibility spec). They also looked ahead and implemented native json encoding/decoding (part of HTML5), and the web storage spec (yet to be finalized). And they've contributed positively to the HTML5 working group.
So really, if you look at the past few years, there's no reason whatsoever to deny them access, because they've been pretty good W3C citizens.
Actually, C# might be a better language than AS3, but it just doesn't matter. AS3 is good enough. Even AS1 was good enough, given that it was basically what javascript still is, and javascript is also "good enough". I would say both in terms of features and of performance the flash and silverlight platforms are roughly comparable.
There's only one thing that matters in the flash/silverlight competition: ubiquity. Whichever platform is most ubiquitous automatically has a leg up in developer mindshare. Flash is still getting used more because of this. I could see them losing their edge though. Office web will run better on silverlight, which is going to greatly boost silverlight adoption. At the same time, adobe isn't managing to close the security gaps in the flash player, which makes it a big risk in corporate deployments.
By the same logic, let the business decisions be made by business people.
What's a "business" person? What knowledge falls under "business"? There's no such thing as a business decision. There are H.R. decisions, product strategy decisions, accounting decisions. But these are all disparate domains with specific knowledge. It's like saying "hey, the decision has to be made by an I.T. person". What good is it letting a sysadmin decide on the development framework of a new application? Might as well let a "business" person do it. Odds are their choice will be just as good (or bad).
By which I only mean to say that the problem with modern business is too many people knowing too little having too much decision-making power.
The systems aren't put in help the doctors. They are put in by the non-medical managers to help their jobs.
I've seen this in action now several times, even at my current job. Management often don't understand the job of the people they're supposed to manage, so they introduce these systems that cater to managers in the hope that it will make up for their lack of understanding. Quite often it doesn't help. This is why companies that require their management to regularly work "on the factory floor" generally do better.
Another big problem is misapplication of tools. Using software aimed at one problem domain in a closely adjoining problem domain might not be a good solution. It's like using the wrong type of screw driver. "It turns screws, that's good enough" doesn't cut it in the real world.
Then again, much business software is designed without really understanding what it is that is supposed to be done with the software when it is finished, mostly because the problem domains are heavily underestimated. I've had to fight epic battles to actually get to speak to end users before I start on the functional design of an app module. The only constant is that users will always tell you some new aspect of the problem that you didn't know about yet.
Slashdot Mirror
You act like google and mozilla are competitors. They're not. There's nothing mozilla does that competes with google. Both are working towards a larger and more capable web, and google has bet the farm on that web becoming the de-facto application platform. Mozilla's activities are a benefit to google, not a risk.
In essence, google is getting a very cheap deal with mozilla, and they know it (which is why the contract has been extended twice so far, and will likely be so again in the second half of 2011).
Do they? They win if people visit Google properties. Whether that needs multiple high quality browsers is debatable. It probably does need _a_ high quality browser
Competing browsers advance the state of the web art faster than a single dominant player. Google entered the browser market not to win, but to increase competition. Mozilla has much the same goal (firefox is the reason microsoft restarted IE development). There's no denying that the competition in the browser space is fierce and that this is leading to rapid iterations of these browsers.
No, Glenn Beck is to entertainment what McDonalds is to nutrition.
That's nonsense. I was bullied heavily as a child, but I'm not insecure anymore. Every victim has the choice to overcome the lack of confidence that being victimized gave them. We should stop treating victims like victims. Send them to karate class! Make them talk to large audiences! Why do we correct only the behavior of the bully when the behavior of the victim is just as much at fault?
You might argue that webkit doesn't need HTML anymore either (except for the canvas tag). Canvas and javascript can render anything, like the bespin web-based code editor, which uses only canvas.
Canvas and SVG serve very different purposes.
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.
These tests were submitted by people who NEEDED to have their software tested.
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.
Much of the software out there doesn't deal with sensitive data, and much of it is too simple to serve as a system security risk
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.
Actually, microsoft's recent track record with the W3C is quite positive. In IE8 they implemented full support for CSS 2.1 (they even released a large test suite to help the other browsers improve their CSS 2.1 support) and a decent level of support for WAI ARIA (accessibility spec). They also looked ahead and implemented native json encoding/decoding (part of HTML5), and the web storage spec (yet to be finalized). And they've contributed positively to the HTML5 working group.
So really, if you look at the past few years, there's no reason whatsoever to deny them access, because they've been pretty good W3C citizens.
Actually, C# might be a better language than AS3, but it just doesn't matter. AS3 is good enough. Even AS1 was good enough, given that it was basically what javascript still is, and javascript is also "good enough". I would say both in terms of features and of performance the flash and silverlight platforms are roughly comparable.
There's only one thing that matters in the flash/silverlight competition: ubiquity. Whichever platform is most ubiquitous automatically has a leg up in developer mindshare. Flash is still getting used more because of this. I could see them losing their edge though. Office web will run better on silverlight, which is going to greatly boost silverlight adoption. At the same time, adobe isn't managing to close the security gaps in the flash player, which makes it a big risk in corporate deployments.
moderation now serves me to mark postings which were compelling enough for someone to moderate them.
But how does that rhyme with the notion that all things are good in moderation?
Yes, you can in fact groan out loud at that one.
By the same logic, let the business decisions be made by business people.
What's a "business" person? What knowledge falls under "business"? There's no such thing as a business decision. There are H.R. decisions, product strategy decisions, accounting decisions. But these are all disparate domains with specific knowledge. It's like saying "hey, the decision has to be made by an I.T. person". What good is it letting a sysadmin decide on the development framework of a new application? Might as well let a "business" person do it. Odds are their choice will be just as good (or bad).
By which I only mean to say that the problem with modern business is too many people knowing too little having too much decision-making power.
The systems aren't put in help the doctors. They are put in by the non-medical managers to help their jobs.
I've seen this in action now several times, even at my current job. Management often don't understand the job of the people they're supposed to manage, so they introduce these systems that cater to managers in the hope that it will make up for their lack of understanding. Quite often it doesn't help. This is why companies that require their management to regularly work "on the factory floor" generally do better.
Another big problem is misapplication of tools. Using software aimed at one problem domain in a closely adjoining problem domain might not be a good solution. It's like using the wrong type of screw driver. "It turns screws, that's good enough" doesn't cut it in the real world.
Then again, much business software is designed without really understanding what it is that is supposed to be done with the software when it is finished, mostly because the problem domains are heavily underestimated. I've had to fight epic battles to actually get to speak to end users before I start on the functional design of an app module. The only constant is that users will always tell you some new aspect of the problem that you didn't know about yet.