Who modded this guy insightful? I'm not sure who he's referring to by "A person involved with WHATWG and HTML5", but it sure as heck can't be me. As I mentioned above, I am not "involved" in it in HTML 5 any official capacity. All I did was go to their website and signed up for the mailing list so I could get spammed on a daily basis! (Ostensibly to "keep track" of their progress and ensure that my needs as a developer are met.;-))
"[R]eads this and gets upset". Again, who is he talking about? This hardly sounds "upset":
I have the highest respect for Mr. Crockford, but my opinion is that he should study the reasons behind HTML 5 a bit more carefully, as well as solicit a bit more feedback from the community before attempting to push a non-solution to their problems. Best of luck to him.:-)
?
Now for some real fun. JSON vs XML... go!
Here's an amazing answer for you: Each has its advantages and disadvantages. Evaluate your project needs before choosing a solution.
Seriously, you mods need to lay off the crack. Or at least share with the rest of us.:-P
Scripts on one side of the module barrier are unable to call scripts on the other side to to access or modify the other side's data structures or document structures.
(Emphasis mine.)
According to his spec, I call module.send() which forwards the message to module.window.document.receive(). Which means that this situation breaks horrendously:
Yes it is. But the other article by the same title that I posted to 5 minutes before this one showed up didn't have that link. One copy and paste later, and you have a post that appears to be stupid when in fact the "editors" were trying an new thing called "editing" for a change.:-)
To enable communication with a module, you provide hook functions.
Rereading it, I can see what you mean. That's almost as bad, though, because now if you need a subscriber system you have to construct it yourself. Basically, he ignored the very problem that DOM 2 Events was created to solve and instead went back to the DOM 0 event system. It's still a very poor design.
As an example, let's say that someone develops a standard for JSON messages so that individual JS modules can use the functionality without interfering with each other. Now let's say that I use an open source JS script that expects messages of type "foo". I also plug in another JS script that expects messages of type "bar". In theory, "foo" should ignore "bar" messages and "bar" should ignore "foo" messages. So far, so good.
However, with the "module" spec only one of those two scripts can actually "hear" the messages. When you include "foo" in your module, "foo" will register the document.receive function. But then when you include "bar" in your module, it will override the registration of "foo" in favor of its own "bar" listener. The only solution is to define a new event model and change "foo" and "bar" to meet that model.
One solution would be to place "addEventListener" and "removeEventListener" functions on "document" to allow scripts to register to "hear" messages being passed to them. Which, interestingly enough, is exactly what HTML 5 does:
document.addEventListener('message', receiver, false); function receiver(e) {
if (e.domain == 'example.com') {
if (e.data == 'Hello world') {
e.source.postMessage('Hello');
} else {
alert(e.data);
}
} }
If an employer budgets X amount of dollars and resources for a project based on the fact that it's fairly simple work, but I have to send it back with a higher set of estimations due to problems introduced by a poor product in the market (namely, Internet Explorer), that is costing time, money, and credibility even though I've done nothing incorrect.
Worse yet, it increases project risk due to unexpected issues in IE's scripting engine, renderer, HTTP handler, and other points where its behavior fails to meet specs. We can't even mitigate that risk by looking at IE documentation, because these failures to meet the spec are not documented by Microsoft. At best they have been exposed by my peers across the 'net. So to even attempt mitigation would require that I trawl the Internet to double-check every minor piece of functionality I'm implementing because IE might blow it into a show-stopping bug.
The pixel perfect web that most designers want really was never part of the design. HTML was never intended to get exactly the same result in all browsers.
The first sentence does not jive with the second sentence. You are correct in saying that HTML was never intended to be pixel perfect. You are incorrect in stating that pixel-perfect rendering was never part of the design. CSS is very much designed to provide pixel perfect rendering to nearly any markup via a method that can implement backward-compatibility with the original HTML specs. (i.e. The Default Stylesheet for HTML 4)
While it's true that HTML has become the most popular framework we use for delivering CSS layouts, HTML 4 and 5 are light years away from the HTML 2 and 3 specs we designed for over a decade ago.
But, you know, it's always nice to karma-whore by ripping IE. Sure, IE development may make extra work for you -- but then again, you're being paid for that work. Why not be happy that "that cowboy Internet Explorer" helped you find gainful employment?
I don't know about you, but I get paid to deliver technological solutions to my employer. Problems caused by poor implementations like IE cost my project time, can cause it to go overbudget, and reduce the effectiveness of my team and my employer's dollar. In extreme cases it can cause the project to fail, which will reflect badly on myself and my team.
There are more than enough useful jobs in the world without a monopoly creating jobs by abusing it power.
"Let's get rid of HTML features that I believe cause problems."
Is not the same as:
"These HTML features have been empirically shown to cause more problems than they solve. Deprecating them will therefore improve the quality of the standard."
I think it's kind of self-defeating. On one hand he advocates custom-tag creation, then he advocates elements by tag selector. Encouraging one or the other is fine. But offering both will only confuse developers and undermine both options. Going with custom tags is probably the better solution as it encapsulates the semantic information a programmer would be looking for while still being unique enough to style with CSS.
I want javascript access to the css parse tree just like with the DOM.
I think you want to read the DOM Level 2 Style Specification. The short answer is: Yes, the CSS is accessible through DOM APIs. The long answer involves lots of shouting and complaining about Microsoft and their stranglehold on the market.:-)
Seeing as you seem to be involved with the HTML 5 proposal
If you count arguing on the mailing list a few times and coming up with a new Canvas adapter (still WIP) for IE, then I suppose.:-)
When will HTML 5 be finished? It is estimated that HTML5 will reach a W3C recommendation in the year 2022 or later. This will be approximately 18-20 years of development, since beginning in mid-2004.
Reading that FAQ entry in its entirety helps clarify the issue; at least for me. The WHATWG is being pragmatic about how long it will take them to both get a 100% complete standard (it has continued to evolve, even after being submitted to the W3C) and get everyone on board with it. People don't realize quite how long it took to get the variations of CSS, DOM, and HTML4 standardized and implemented. They've been available for over a decade, but we're only reaping the benefits of these standards now.
That being said, the W3C does expect parts of the specification to be implemented sooner rather than later:
The details are still being worked out, but the plan is to indicate the maturity level on a per-section basis. Sections like the Link Types, which is relatively simple, isn't going to take long to become interoperably implemented. In fact, Mozilla is already implementing the new autodiscovery features for Firefox 3.0, and it shouldn't take long for places like Technorati, Bloglines, etc. to implement follow.
In result, it really doesn't matter when the HTML 5 standard is fully realized. We will be (and already are) reaping the benefits of it long before it's 100% complete.
Of course, they did get it submitted to the W3C ahead of schedule. And the W3C is taking it more seriously than originally expected. So don't be surprised if they're ahead of schedule on completion.;-)
There is probably some irony in the fact that inter-document communications feature in HTML 5 would allow him to implement his "module" concept in an HTML 5 compliant browser. In fact, the HTML 5 proposal is actually superior to his "module" proposal in the method it uses to receive messages. Rather than polling for a JSON packet (which could be costly in both processor time and responsiveness), the HTML 5 solution adapts the existing DOM 2 event model to make the messaging smooth, seamless, and fast.
Make sure you have about 2 minutes to spare. You're going to need about that long to read it from beginning to end. What you'll probably find is that he hasn't really solved any of the major issues plaguing HTML or even thought through many of the problems and use-cases that HTML 5 is trying to solve. In fact, his entire "design" can be summed up with the following sentence: "Let's get rid of HTML features that I believe cause problems."
Meanwhile, he still leaves the problems of consistent parsing, semantic meaning, multimedia presentation, and a whole host of other issues unaddressed. Which means that his "design" fails to compete with the intended purpose of HTML 5 at even the most basic level.
I have the highest respect for Mr. Crockford, but my opinion is that he should study the reasons behind HTML 5 a bit more carefully, as well as solicit a bit more feedback from the community before attempting to push a non-solution to their problems. Best of luck to him.:-)
Come on. Do you really believe I think that? You've been around Slashdot long enough to know a bit about me. Can you honestly say to yourself that I'm that shallow and naive?
"Who said anything about firing in an urban area? That would indeed be stupid."
But if it makes you happy: "I don't advocate firing DU rounds down roads in urban areas." Or HEAT rounds for that matter. Unless the area is an otherwise evacuated warzone. (Which does happen.)
Just a thought, what percentage of IEDs are used in areas where a DU round would cause major collateral damage?
That's a difficult question to answer as I'm not in the military. (My brother served several tours over there, however.) I *do* know that many of the IEDs are planted in areas of high troop movement/low population. There are a variety of videos on the 'net posted by insurgents using IEDs on low-traffic roads. (My brother showed them to me as it was the thing that freaked him out more being over there. Battles he could handle. There's a degree of control there. Hidden explosive devices? Not so much.) What you *don't* usually see are roadside bombs on high-traffic Iraqi highways and freeways. Car bombs and other more mobile forms of IEDs are usually employed in these environments as the insurgents have many of the same collateral damage issues that US troops do. (Though I think they're more worried about actually hitting the US troops rather than accidentally killing innocents.)
"The redeployment without replacement reflects overall improved security within Iraq," military spokesman Rear Admiral Gregory Smith told a news conference.
[...]
Killings, kidnapping and suicide attacks had decreased in Diyala by over 68 percent since April, he said.
Sutherland said U.S. troops had particular success against Sunni Islamist al Qaeda.
He also credited much of the improvement in Diyala to more effective Iraqi police and army, and to around 3,000 local men who had joined neighborhood watch patrols.
Some 700 of the so-called "concerned local citizens" had since signed up to join the Iraqi police, he added.
No one had to die after Baghdad was captured. The government was toppled and Saddam was on the run. We didn't continue shooting and bombing people because we wanted to install a hyperspace bypass and they were in the way. They were shooting at us. We shot back. That pretty much sums things up.
Who said anything about firing in an urban area? That would indeed be stupid. We have Apaches with precision machine guns and low-yield missiles for those situations. (EVIL GRIN)
Seriously, what's with placing words in my mouth? I know it's a Slashdot tradition, but there are a lot better things to argue about without setting up a strawman.
Through September 22, 2007 approximately 19,429 insurgents/militia were reported to have been killed according to the U.S. military, including 1,309 bombers
In addition as of November 21, 2007 approximately 1,357 suicide-bombers have also been reported killed
#1 - There's a reason for a propaganda machine in any war. If the locals are blaming us for deaths, then the propaganda machine is not doing its job.
#2 - "A more efficient killing machine" in modern military parlance is a machine that strikes more of the right targets and fewer of the wrong targets. We already have the military might to simply wipe Iraq off the map. That would solve the problem, real quick. But it's not the goal. Ergo, more efficient killing machine == good.
More like blame the generals who shot spreadsheet "simulations" back and forth instead of large scale wargames to shake-out the technology. The networked battlefield went out untested with an expectation that it would work as promised. Which is a really dumb assumption for military hardware.
Besides, a more efficient killing machine is the last thing you want in an insurgency like Iraq.
'Scuse me? If you've got insurgents setting up an ambush, blasting the frak out of them sounds like a good solution to me. Fire a DU round from a tank down the road, all the IEDs go "boom" and the insurgents waiting on the side go "slwooop" as the massive air pressure changes suck them inside out.
Efficient killing machine == Good when there are bad guys trying to kill you.
One might argue that the insurgents are not terrorists and are thus not our enemy. A reasonable argument, save for one missing piece of logic. If the insurgents would wait we'd already be out of Iraq and they could be dealing with the local, underpowered government. Instead, they decide to take on the most powerful military in the world. Even on our bad days, that's not such a good idea.
if "Judge Judy" who is as much a Judge as Judge Reinhold, were to act that way in a court room she would be rightly disbarred (i.e. Benched).
WTF are you talking about? "Judge Judy" was very much a "real" judge up until her retirement in 1996, albeit a small claims judge. She got her television show thanks to a large amount of press about her outspoken nature in real courtrooms. While the "court" in her show is merely an agreed-upon arbitration session, she is demonstrating much of the same behavior that she became famous for when in public service.
More to the point, Judith is not the only judge known for rather outlandish behavior. Judge Samuel B. Kent is also well-known in the legal community for his humorous and razor-sharp wit, especially in his written orders. One of his more famous incidents was when he dismissed a case for being "asinine tripe".
Last but not least, you do not "disbar" a judge to remove him/her from office. Judges are either elected or appointed officials. Disbarring means they can't practice as a lawyer anymore. (Annoying, but not a huge problem for someone not appointed by the Bar.) Judges must be impeached or dismissed from office like most other government officials. Disbarment usually follows impeachment or dismissal to prevent the Judge from continuing to practicing law after being dismissed.
if Wii owners don't keep buying games, did Nintendo really win?
Yes, actually. Because Nintendo made a profit on the Wii from Day #1. As other console manufacturers optimize their manufacturing costs to produce their consoles at a lower loss (or simply reduce the street price and take the same loss), Nintendo's profit margins simply grow as they optimize their processes. Thus Nintendo "wins" regardless.
The real question is, what happens to the game producers? The argument exists that if the Wii wins, all we'll end up with is Mario and Wii Sports. To which I think it's important to turn around that argument and look at it from another angle. Nintendo currently has about 14 million consoles out there, and a shipped Wii is effectively a sold Wii. Thus the Wii presents a tremendousopportunity to game producers.
This huge market payed $250 for Wii Sports. As a game producer, it then becomes your job to understand that market and produce more content for it. More to the point, it becomes the job of game producers to produce content that the market wants. Wii players are less likely to want Assassin's Creed or Call of Duty 4. (Oh look, another military FPS! Who would have thought?) So stop trying to sell them the same games you've been selling teenage boys, and start doing some market research. Make games that are compelling to the casual market, and you will win.
The best part? You don't even have to spend tens of millions on the game! A sizable sum of Wii players are attracted to casual games, which have far, far lower budgets than the so-called "triple-A" titles. Perhaps this generation could even see the downloadable game surpassing the sales of the traditional shrink-wrapped game. (If Nintendo ever gets off their butts and offers WiiWare games, that is.:P)
Slashdot Mirror
"[R]eads this and gets upset". Again, who is he talking about? This hardly sounds "upset":
?
Here's an amazing answer for you: Each has its advantages and disadvantages. Evaluate your project needs before choosing a solution.
Seriously, you mods need to lay off the crack. Or at least share with the rest of us.
Then why does his spec explicitly say:
(Emphasis mine.)
According to his spec, I call module.send() which forwards the message to module.window.document.receive(). Which means that this situation breaks horrendously:
Yes it is. But the other article by the same title that I posted to 5 minutes before this one showed up didn't have that link. One copy and paste later, and you have a post that appears to be stupid when in fact the "editors" were trying an new thing called "editing" for a change. :-)
Rereading it, I can see what you mean. That's almost as bad, though, because now if you need a subscriber system you have to construct it yourself. Basically, he ignored the very problem that DOM 2 Events was created to solve and instead went back to the DOM 0 event system. It's still a very poor design.
As an example, let's say that someone develops a standard for JSON messages so that individual JS modules can use the functionality without interfering with each other. Now let's say that I use an open source JS script that expects messages of type "foo". I also plug in another JS script that expects messages of type "bar". In theory, "foo" should ignore "bar" messages and "bar" should ignore "foo" messages. So far, so good.
However, with the "module" spec only one of those two scripts can actually "hear" the messages. When you include "foo" in your module, "foo" will register the document.receive function. But then when you include "bar" in your module, it will override the registration of "foo" in favor of its own "bar" listener. The only solution is to define a new event model and change "foo" and "bar" to meet that model.
One solution would be to place "addEventListener" and "removeEventListener" functions on "document" to allow scripts to register to "hear" messages being passed to them. Which, interestingly enough, is exactly what HTML 5 does:
If an employer budgets X amount of dollars and resources for a project based on the fact that it's fairly simple work, but I have to send it back with a higher set of estimations due to problems introduced by a poor product in the market (namely, Internet Explorer), that is costing time, money, and credibility even though I've done nothing incorrect.
Worse yet, it increases project risk due to unexpected issues in IE's scripting engine, renderer, HTTP handler, and other points where its behavior fails to meet specs. We can't even mitigate that risk by looking at IE documentation, because these failures to meet the spec are not documented by Microsoft. At best they have been exposed by my peers across the 'net. So to even attempt mitigation would require that I trawl the Internet to double-check every minor piece of functionality I'm implementing because IE might blow it into a show-stopping bug.
Think about it.
The first sentence does not jive with the second sentence. You are correct in saying that HTML was never intended to be pixel perfect. You are incorrect in stating that pixel-perfect rendering was never part of the design. CSS is very much designed to provide pixel perfect rendering to nearly any markup via a method that can implement backward-compatibility with the original HTML specs. (i.e. The Default Stylesheet for HTML 4)
While it's true that HTML has become the most popular framework we use for delivering CSS layouts, HTML 4 and 5 are light years away from the HTML 2 and 3 specs we designed for over a decade ago.
I don't know about you, but I get paid to deliver technological solutions to my employer. Problems caused by poor implementations like IE cost my project time, can cause it to go overbudget, and reduce the effectiveness of my team and my employer's dollar. In extreme cases it can cause the project to fail, which will reflect badly on myself and my team.
There are more than enough useful jobs in the world without a monopoly creating jobs by abusing it power.
Very simple.
"Let's get rid of HTML features that I believe cause problems."
Is not the same as:
"These HTML features have been empirically shown to cause more problems than they solve. Deprecating them will therefore improve the quality of the standard."
It's called NeWS, and it's quite old. As you can see, What's Old is NeWS Again.
I think it's kind of self-defeating. On one hand he advocates custom-tag creation, then he advocates elements by tag selector. Encouraging one or the other is fine. But offering both will only confuse developers and undermine both options. Going with custom tags is probably the better solution as it encapsulates the semantic information a programmer would be looking for while still being unique enough to style with CSS.
That being said, if you really want that feature try this script:
http://simonwillison.net/2003/Mar/25/getElementsBySelector/
I think you want to read the DOM Level 2 Style Specification. The short answer is: Yes, the CSS is accessible through DOM APIs. The long answer involves lots of shouting and complaining about Microsoft and their stranglehold on the market.
If you count arguing on the mailing list a few times and coming up with a new Canvas adapter (still WIP) for IE, then I suppose.
Reading that FAQ entry in its entirety helps clarify the issue; at least for me. The WHATWG is being pragmatic about how long it will take them to both get a 100% complete standard (it has continued to evolve, even after being submitted to the W3C) and get everyone on board with it. People don't realize quite how long it took to get the variations of CSS, DOM, and HTML4 standardized and implemented. They've been available for over a decade, but we're only reaping the benefits of these standards now.
That being said, the W3C does expect parts of the specification to be implemented sooner rather than later:
In result, it really doesn't matter when the HTML 5 standard is fully realized. We will be (and already are) reaping the benefits of it long before it's 100% complete.
Of course, they did get it submitted to the W3C ahead of schedule. And the W3C is taking it more seriously than originally expected. So don't be surprised if they're ahead of schedule on completion.
There is probably some irony in the fact that inter-document communications feature in HTML 5 would allow him to implement his "module" concept in an HTML 5 compliant browser. In fact, the HTML 5 proposal is actually superior to his "module" proposal in the method it uses to receive messages. Rather than polling for a JSON packet (which could be costly in both processor time and responsiveness), the HTML 5 solution adapts the existing DOM 2 event model to make the messaging smooth, seamless, and fast.
You can read his proposal in full over here: http://www.crockford.com/html/
:-)
Make sure you have about 2 minutes to spare. You're going to need about that long to read it from beginning to end. What you'll probably find is that he hasn't really solved any of the major issues plaguing HTML or even thought through many of the problems and use-cases that HTML 5 is trying to solve. In fact, his entire "design" can be summed up with the following sentence: "Let's get rid of HTML features that I believe cause problems."
Meanwhile, he still leaves the problems of consistent parsing, semantic meaning, multimedia presentation, and a whole host of other issues unaddressed. Which means that his "design" fails to compete with the intended purpose of HTML 5 at even the most basic level.
I have the highest respect for Mr. Crockford, but my opinion is that he should study the reasons behind HTML 5 a bit more carefully, as well as solicit a bit more feedback from the community before attempting to push a non-solution to their problems. Best of luck to him.
Come on. Do you really believe I think that? You've been around Slashdot long enough to know a bit about me. Can you honestly say to yourself that I'm that shallow and naive?
But if it makes you happy: "I don't advocate firing DU rounds down roads in urban areas." Or HEAT rounds for that matter. Unless the area is an otherwise evacuated warzone. (Which does happen.)
That's a difficult question to answer as I'm not in the military. (My brother served several tours over there, however.) I *do* know that many of the IEDs are planted in areas of high troop movement/low population. There are a variety of videos on the 'net posted by insurgents using IEDs on low-traffic roads. (My brother showed them to me as it was the thing that freaked him out more being over there. Battles he could handle. There's a degree of control there. Hidden explosive devices? Not so much.) What you *don't* usually see are roadside bombs on high-traffic Iraqi highways and freeways. Car bombs and other more mobile forms of IEDs are usually employed in these environments as the insurgents have many of the same collateral damage issues that US troops do. (Though I think they're more worried about actually hitting the US troops rather than accidentally killing innocents.)
Roads only exist in urban areas? Whoa. Major revelation there! :-/
Again, I demand an explanation: Why are you placing words in my mouth?
Think they'd reciprocate? Honestly?
No one had to die after Baghdad was captured. The government was toppled and Saddam was on the run. We didn't continue shooting and bombing people because we wanted to install a hyperspace bypass and they were in the way. They were shooting at us. We shot back. That pretty much sums things up.
Who said anything about firing in an urban area? That would indeed be stupid. We have Apaches with precision machine guns and low-yield missiles for those situations. (EVIL GRIN)
Seriously, what's with placing words in my mouth? I know it's a Slashdot tradition, but there are a lot better things to argue about without setting up a strawman.
Source: http://www.usatoday.com/news/world/iraq/2007-09-26-insurgents_N.htm
Source: http://icasualties.org/oif/US_chart.aspx
As I said, even on a bad day, attacking the most powerful military in the world is a dumb idea.
#1 - There's a reason for a propaganda machine in any war. If the locals are blaming us for deaths, then the propaganda machine is not doing its job.
#2 - "A more efficient killing machine" in modern military parlance is a machine that strikes more of the right targets and fewer of the wrong targets. We already have the military might to simply wipe Iraq off the map. That would solve the problem, real quick. But it's not the goal. Ergo, more efficient killing machine == good.
More like blame the generals who shot spreadsheet "simulations" back and forth instead of large scale wargames to shake-out the technology. The networked battlefield went out untested with an expectation that it would work as promised. Which is a really dumb assumption for military hardware.
'Scuse me? If you've got insurgents setting up an ambush, blasting the frak out of them sounds like a good solution to me. Fire a DU round from a tank down the road, all the IEDs go "boom" and the insurgents waiting on the side go "slwooop" as the massive air pressure changes suck them inside out.
Efficient killing machine == Good when there are bad guys trying to kill you.
One might argue that the insurgents are not terrorists and are thus not our enemy. A reasonable argument, save for one missing piece of logic. If the insurgents would wait we'd already be out of Iraq and they could be dealing with the local, underpowered government. Instead, they decide to take on the most powerful military in the world. Even on our bad days, that's not such a good idea.
WTF are you talking about? "Judge Judy" was very much a "real" judge up until her retirement in 1996, albeit a small claims judge. She got her television show thanks to a large amount of press about her outspoken nature in real courtrooms. While the "court" in her show is merely an agreed-upon arbitration session, she is demonstrating much of the same behavior that she became famous for when in public service.
More to the point, Judith is not the only judge known for rather outlandish behavior. Judge Samuel B. Kent is also well-known in the legal community for his humorous and razor-sharp wit, especially in his written orders. One of his more famous incidents was when he dismissed a case for being "asinine tripe".
Last but not least, you do not "disbar" a judge to remove him/her from office. Judges are either elected or appointed officials. Disbarring means they can't practice as a lawyer anymore. (Annoying, but not a huge problem for someone not appointed by the Bar.) Judges must be impeached or dismissed from office like most other government officials. Disbarment usually follows impeachment or dismissal to prevent the Judge from continuing to practicing law after being dismissed.
Better solution:
http://passwordmaker.sourceforge.net/passwordmaker.html
One password for all sites, but a unqiue, "fscking crazy" password for all of them. You're welcome.
Yes, actually. Because Nintendo made a profit on the Wii from Day #1. As other console manufacturers optimize their manufacturing costs to produce their consoles at a lower loss (or simply reduce the street price and take the same loss), Nintendo's profit margins simply grow as they optimize their processes. Thus Nintendo "wins" regardless.
The real question is, what happens to the game producers? The argument exists that if the Wii wins, all we'll end up with is Mario and Wii Sports. To which I think it's important to turn around that argument and look at it from another angle. Nintendo currently has about 14 million consoles out there, and a shipped Wii is effectively a sold Wii. Thus the Wii presents a tremendous opportunity to game producers.
This huge market payed $250 for Wii Sports. As a game producer, it then becomes your job to understand that market and produce more content for it. More to the point, it becomes the job of game producers to produce content that the market wants. Wii players are less likely to want Assassin's Creed or Call of Duty 4. (Oh look, another military FPS! Who would have thought?) So stop trying to sell them the same games you've been selling teenage boys, and start doing some market research. Make games that are compelling to the casual market, and you will win.
The best part? You don't even have to spend tens of millions on the game! A sizable sum of Wii players are attracted to casual games, which have far, far lower budgets than the so-called "triple-A" titles. Perhaps this generation could even see the downloadable game surpassing the sales of the traditional shrink-wrapped game. (If Nintendo ever gets off their butts and offers WiiWare games, that is.