Let's face it, processor-wise and capability-wise the Wii is little more than a slightly improved Gamecube.
That's what most people say, and they don't know what they're talking about.
The processor is compatible with the GameCube's Gekko, but its lineage is the same as the Cell's and the Xenon's. It's a throw-away model which Nintendo picked up for cheap, then customised for GameCube compatibility.
As for the rest, the motherboard is completely new. The graphics chipset is much better.
Eh, my Windows 95 PC boots in just 15 seconds after POST, completely ready for use. The time from pressing the button to the end of POST is 20 seconds... As for shutdown, that's 2-3 seconds only.
My Windows XP laptop boots about as fast, though the POST there is quicker. Shutting it down can take a while depending on what you ran that session. It's always at least 5 seconds.
Shit happens regardless. I'd rather have instant feedback when shit happens.
Then what's stopping you from using the W3 Validator or a browser extension that validates locally? As a bonus, it will check for more than just "are all the elements closed neatly"?
A parser is a parser is a parser. Why should HTML be less strict than Javascript?
The difference matters because JavaScript has no set structure, while HTML does. You can make educated guesses on what is missing in many cases.
As for why HTML should be less strict... This way we have a low barrier for entry for newbies who want to make their own page. There's also user-generated and third-party content that you can't always control. Finally, there are legacy pages and legacy tools that don't always output good HTML, which can't always be fixed or replaced.
Again, you're assuming users will ever see this page. Why would they?
Because shit happens? I know I saw a pretty XML error a year back or so when I tried to visit the site that had the Home Button extension. It also happened for a long time with Microsoft's Live Spaces. There are other documented instances out there if you look them up.
It's also a bit like suggesting that Javascript parsers should be able to detect (and compensate for) missing close brackets.
A scripting language is a totally different beast than a mark-up language.
You can use XHTML with HTML5, but the focus is on HTML. The sole deciding factor will be the MIME type. We all know where this leads...
No, Opera's study confirms that it's not standards-compliant. That has nothing to do with whether it's valid XML.
How about the study done by Ian Hixie, then? The result of that study was that 95% of the web is tag soup, malformed HTML.
And how is this an excuse for letting your own tags slide?
Of course not, and I wasn't implying as such.
Nor should users be faced with a cryptic 404 error, but shit happens.
That's something you can't always avoid, and for which there is no fallback content or possible recovery, save for a custom 404 error page.
And if you put a page out there as XHTML, and left off a closing tag, you absolutely deserve for your users to see a cryptic XML error -- because it means you never bothered to check it yourself.
No. Users who had nothing to do with the development of the page do not deserve it.
Spoken like someone who has never done actual web development. Have you heard of Firebug?
Of course I have. It's not compatible with SeaMonkey, though. I use the DOM Inspector. I've done a fair share of web development, actually. In HTML4 Strict!
Firebug and DOM Inspector are web development tools that hook into the web browser. That doesn't make the web browser itself a development tool.
It wasn't going anywhere. Look at the XHTML2 drafts. It's out of touch with reality.
As Opera's study confirms, 95+% out there is tag soup, and this is not going to change in the coming 5 years. Supporting XHTML isn't worth it when there's barely any page out there that is actually served as XHTML (or even validates properly as such), even now, after all these years.
Consider also that XHTML 'solves' only the less important of the real problems, which are the lack of validity, semantics, and separation of content and style.
That "draconian" error handling is causing problems how?
No user should be faced with a cryptic XML error when they want to access a page.
I consider it to be a good thing. If I forgot a closing tag, or something like that, an XML parser will tell me, and I can fix it. Even if a "tag soup parser" attacks it later, it will be more likely to do the right thing.
That's why the W3 Validator exists. The web browser is a viewer, not a development tool.
Yes, having a browser be able to tolerate errors is a good thing, as long as people continue to build things that aren't XHTML. The problem is, exactly which algorithm should a browser use to parse sloppy HTML? Different browsers will parse it in different ways.
That was always a problem indeed. Which is why HTML5 will address this.
And XML parsers are consistent enough, at this point, that if it doesn't break for you, it's not broken for anyone else. The whole reason for being flexible about what you receive is gone -- it's a bit like trying to tolerate broken ASCII (or Unicode).
Rendering XHTML properly takes more than just an XML parser. XML has slightly different rules for the DOM, and this impacts JavaScript, for example. The point is that the XHTML mode is much less tested.
I didn't say that the web as a whole hasn't evolved. I said that the HTML and CSS specifications haven't, so the argument that we shouldn't use them because the web is still evolving is irrelevant.
The majority already supports web standards. It's just IE, as you said. You don't need to reduce standards compliance to make your page work in IE. Either use some CSS hacks, or, even better, use IE's conditional comments to serve a stylesheet to IE only to fix whatever's wrong.
Yes, I'm a web developer, and yes, I maintain such sites. They're standards compliant and render well in all web browsers.
Seriously, it's not an arcane art. It's perfectly possible. I wonder why people always claim the opposite when I know it's possible because I actually do this.
I already explained that it isn't hard. Or do you really think no one has to make even the slightest of efforts before they actually have a web page in front of them? If the bare minimum isn't met, there will be no page.
You're using circular logic. I think I'll abstain from further replies.
HTML4 and CSS2 are standards that were done about a decade ago. This whole "the web is still evolving" doesn't apply.
A comparison to building design is not appropriate, as we're dealing with computers here. It is perfectly possible to be 100% standards compliant, or at least very close to it, without too much effort.
Substitue Opera with Firefox, and you get the same picture. All the web browser developers are rallying behind the web standards. Yes, even IE, but they have a lot of catching up to do.
You don't get it. The mark-up has already been messed with, and consolidated with standards. But we still have most people writing crappy HTML.
You don't need to ignore all the standards to experiment with standards that you think still need messing with, like JavaScript. You take a solid base, and build on that.
The mess you create still has to show properly in my web browser in the end!
Slashdot Mirror
Don't give them any ideas!
Valid XHTML? Or broken XHTML that really is HTML4?
The problem is that those validation errors are likely to crop up later. Maybe in $FUTURE_BROWSER. It's not like fixing those errors is hard.
Simple. Don't use the Transitional DTD. Use the Strict DTD only. As for XHTML, it's a bad idea to use it as IE still doesn't support it.
But there is an object element to embed video!
This is the second time someone has replied this to me on Slashdot, and also the second time that the one who did had a higher UID than me. :P
I seem to remember a similar story more than a year ago. What the hell?
Don't forget to throw them afterwards!
There's XUL MSN Messenger, developed by yours truly. It doesn't support display pictures (yet), but otherwise it's pretty solid. I always use it.
Retro Studios is an American company owned by Nintendo that developed Metroid Prime and its sequels.
That's what most people say, and they don't know what they're talking about.
The processor is compatible with the GameCube's Gekko, but its lineage is the same as the Cell's and the Xenon's. It's a throw-away model which Nintendo picked up for cheap, then customised for GameCube compatibility.
As for the rest, the motherboard is completely new. The graphics chipset is much better.
Pixel perfect is not possible. There are many variables at play. But you can get a very consistent rendering.
No, I don't use any pre-written libraries.
Eh, my Windows 95 PC boots in just 15 seconds after POST, completely ready for use. The time from pressing the button to the end of POST is 20 seconds... As for shutdown, that's 2-3 seconds only.
My Windows XP laptop boots about as fast, though the POST there is quicker. Shutting it down can take a while depending on what you ran that session. It's always at least 5 seconds.
Then what's stopping you from using the W3 Validator or a browser extension that validates locally? As a bonus, it will check for more than just "are all the elements closed neatly"?
The difference matters because JavaScript has no set structure, while HTML does. You can make educated guesses on what is missing in many cases.
As for why HTML should be less strict... This way we have a low barrier for entry for newbies who want to make their own page. There's also user-generated and third-party content that you can't always control. Finally, there are legacy pages and legacy tools that don't always output good HTML, which can't always be fixed or replaced.
Because shit happens? I know I saw a pretty XML error a year back or so when I tried to visit the site that had the Home Button extension. It also happened for a long time with Microsoft's Live Spaces. There are other documented instances out there if you look them up.
A scripting language is a totally different beast than a mark-up language.
You can use XHTML with HTML5, but the focus is on HTML. The sole deciding factor will be the MIME type. We all know where this leads...
How about the study done by Ian Hixie, then? The result of that study was that 95% of the web is tag soup, malformed HTML.
Of course not, and I wasn't implying as such.
That's something you can't always avoid, and for which there is no fallback content or possible recovery, save for a custom 404 error page.
No. Users who had nothing to do with the development of the page do not deserve it.
Of course I have. It's not compatible with SeaMonkey, though. I use the DOM Inspector. I've done a fair share of web development, actually. In HTML4 Strict!
Firebug and DOM Inspector are web development tools that hook into the web browser. That doesn't make the web browser itself a development tool.
It wasn't going anywhere. Look at the XHTML2 drafts. It's out of touch with reality.
As Opera's study confirms, 95+% out there is tag soup, and this is not going to change in the coming 5 years. Supporting XHTML isn't worth it when there's barely any page out there that is actually served as XHTML (or even validates properly as such), even now, after all these years.
Consider also that XHTML 'solves' only the less important of the real problems, which are the lack of validity, semantics, and separation of content and style.
No user should be faced with a cryptic XML error when they want to access a page.
That's why the W3 Validator exists. The web browser is a viewer, not a development tool.
That was always a problem indeed. Which is why HTML5 will address this.
Rendering XHTML properly takes more than just an XML parser. XML has slightly different rules for the DOM, and this impacts JavaScript, for example. The point is that the XHTML mode is much less tested.
I didn't say that the web as a whole hasn't evolved. I said that the HTML and CSS specifications haven't, so the argument that we shouldn't use them because the web is still evolving is irrelevant.
The majority already supports web standards. It's just IE, as you said. You don't need to reduce standards compliance to make your page work in IE. Either use some CSS hacks, or, even better, use IE's conditional comments to serve a stylesheet to IE only to fix whatever's wrong.
Yes, I'm a web developer, and yes, I maintain such sites. They're standards compliant and render well in all web browsers.
Seriously, it's not an arcane art. It's perfectly possible. I wonder why people always claim the opposite when I know it's possible because I actually do this.
I already explained that it isn't hard. Or do you really think no one has to make even the slightest of efforts before they actually have a web page in front of them? If the bare minimum isn't met, there will be no page.
You're using circular logic. I think I'll abstain from further replies.
HTML4 and CSS2 are standards that were done about a decade ago. This whole "the web is still evolving" doesn't apply.
A comparison to building design is not appropriate, as we're dealing with computers here. It is perfectly possible to be 100% standards compliant, or at least very close to it, without too much effort.
Substitue Opera with Firefox, and you get the same picture. All the web browser developers are rallying behind the web standards. Yes, even IE, but they have a lot of catching up to do.
Except that is not what actually happens today. As I said, people still spit out invalid web pages, whether they want to experiment or not.
You don't get it. The mark-up has already been messed with, and consolidated with standards. But we still have most people writing crappy HTML.
You don't need to ignore all the standards to experiment with standards that you think still need messing with, like JavaScript. You take a solid base, and build on that.
The mess you create still has to show properly in my web browser in the end!