Since there's no reference implementation, that's *always* true, though. Maybe not for that little particular scenario, but since the standards aren't (and probably will never be) 100% complete, there will always be things like that that browsers do differently.
And then the malware would just programmatically click the "Yes" button. You've solved nothing, unless you can work it into one of Microsoft's "Alternate Desktop"-type environments (like the control-alt-delete desktop, or the UAC desktop in Vista.)
Well creating a web page is different from creating content. If you want to voice your opinion but be bothered properly format the code then use facebook or some other blog software.
Weasel, weasel, weasel. And yet when you create a new Facebook account and start blogging with it, you're creating new pages. Stop trying to weasel out of what you said.
HTML hasn't gone away yet but it will. Who's using HTML 2.0?
How will it? There are thousands of completely unmaintained sites in HTML. Some of them are forgotten, some of them have authors who are dead. And, most importantly, all of them contain critical content that shouldn't disappear simply because of the file format they're in.
The great delusion of XHTML advocates is that HTML would somehow disappear. I don't see how they expected that to happen, it makes absolutely no sense to me.
If you shop at JC Penny,that's not going to help people's image of you.;)
Wow, you're an elitist asshole no matter what the topic. You also completely missed my point.
Millions of people shop at JC Penney. Millions. If you release a browser that won't render bad HTML, you've just released a browser that's absolutely useless for the millions of people who shop at JC Penney. Your marketshare will plummet.
Just because some people do things wrong doesn't mean they should be allowed to. HTML/XHTML are still languages. We wouldn't accept any old English gibberish within a professional environment so why should we accept gibberish HTML?
People accept English gibberish all the freakin' time. What planet do you live on? Pick any random page on IBM.com, or Oracle.com, or read any Microsoft press release. Here's an example from Oracle.com:
"Multi-Dimensional Business Process Management--Provides unified support for human-centric, system-centric, and document-centric processes, and dynamic process adaptation with integrated process intelligence"
JC Penny has no reason to be writing such bad code. Even if they are using a CMS there is no excuse. They have a broken form tag, two opening and closing body tags and that's just two big ones I've noticed a very quick glance. Those aren't mistakes from automation, they're just bad mistakes that should not be made and developers shouldn't have to waste their time accounting for web developer incompetence. The only correct outcome that people should get from viewing that page is that it breaks and doesn't display. Then the web developers fix it. If they can't fix those problems they don't deserve their jobs.
And yet! Despite all your vitriol, that site exists here in the real, non-theoretical, world and therefore real, non-theoretical, browsers need to accept it. Whether or not they "deserve their jobs" is not your call to make-- it's JC Penney's, and they obviously are happy with whatever service they're getting.
Hell, you have no reason to spell "JC Penney" consistently wrong, and yet you're doing it. Human beings make mistakes, eh?
I-Frames work in XHTML transitional. No one said you must use XHTML strict at all times nor did anyone say they would never be replaced.
The fact that XHTML Strict doesn't allow iframes is just evidence that the people who created it from their ivory tower have *no fucking clue* how actual websites in the actual real world work. Like it or not, iframes are as critical a feature to the web as XMLHttpRequest at this point, and any standard that doesn't include them is worthless.
Marquee is an awful tag as is blink. They shouldn't be used because the only reason for making proprietary tags is to lock someone into using your browser and neither side did just to make the web a better place. They did it for the reason to lock people into their browser. Just as MS making their own Java VM was done purely to ruin Java.
Active X isn't a necessary or required extension, it is again something that was meant to lock people in one browser. In an ideal world people would o
Take your example of the strong and em tags, but lets extend it a bit further and say you've defined (for some unknown reason) to define in CSS that 'strong' displays in Arial and 'em' in Times. You write hi , simple enough right? yeah, except that which font should it use? assume the standard specifies that inner tags overwrite the style of outer ones. IE decides that, since you wrote first, thats the outer one and so uses Times. But Firefox sees that was *closed* first and so is the inner one, therefore it should go with Arial.
For the record, the answer is: "I write that code, then I test it and see which font shows up. If it's not the font I want, I re-write the code so the font I want shows up."
I'm actually after reading this thread and some linked articles changing my mind about the problem. But, on the other hand, I also live in the real world where browsers don't have the option of dropping HTML4 support. (Or indeed support of bad HTML of any kind.)
So we end up with this situation: 1) Browsers support bad HTML for legacy/compatibility reasons 2) Bad web developer sees that his bad HTML still works 3) Bad web developer continues to write bad HTML, since that's all he knows 4) Browsers continue to render the new bad HTML, due to point 1
Standards can't re-write the past. I don't know what the solution is, but I know that XHTML certainly wasn't it, and I'm happy to see it dropped for something more promising.
No, no, no, those are only features to web developers. What about *users*? Those pink squishy things that actually use the browser? Debugging stylesheets? Christ.
And seriously, how many people use any of those things you listed? I'm pretty sure I've never in my life come across a RDF or MathML or XUL file, and the only thing I know about SVG is that it's a graphics format nobody supports. Isn't Xul the bad-guy from the first Ghostbusters movie?
You're conflating 'putting content on the web' with 'writing HTML'. They don't mean the same thing.
Except that's not what the parent I was replying to said. He said this:
"Anyone too lazy to code nice neat xhtml shouldn't be allowed to create web pages."
Notice how it's not qualified in any way. "Thetoadwarrior" literally thinks that you should be forced to entirely understand XHTML before you should be "allowed" (by whom?) to create a webpage. He's being a total asshat, so please don't attempt to defend him.
XHTML would have forced makers of stupid (i.e. non-XML-compliant) software applications to fix their engines. That would have required lots of effort, but the value of such an effort is philosophically similar to enforcing health and safety standards on manufacturing processes. Yes, it's cheaper to create quick and dirty implementations, but the public good is better served by enforcing minimal levels of quality. It increases the cost of production, but increases the value of the product, too.
Except that's wrong, because XHTML existing doesn't make HTML4 go away. Browsers will have to render HTML4 until the end of time, if only for backwards compatibility purposes-- given that, bad web developers used to HTML4's quirks and idiocies will simply continue to code in HTML4 and ignore XHTML altogether.
And... gasp... after years of XHTML, that's exactly what's happened. The existence of HTML4 hasn't helped this site improve any, and it's one of the most popular e-commerce sites on the web.
What I don't get is why so many people who were behind XHTML believed that it would make HTML4 go away. Either they didn't bother thinking about the situation for more than 10 seconds, or they are entirely clueless about human psychology.
HTML5 tries for a middle road wherein the parser tries to be more forgiving while at the same codifying the ways in which it should fail. It tries to make the failure modes as graceful and predictable as possible. It's sold as a more pragmatic approach to Tag Soup, a problem that's bedeviled us since FrontPage first reared its zombie head.
And exactly what W3C should have done instead of wasting everybody's time on XHTML in the first fucking place.
For my part, I think it's the wrong approach. I don't think it's as wrong as some of the sins committed by Netscape (, frames, etc.) and Microsoft (iframe, marquee) in the early days, when they treated the W3C as their bitch, foisting all kinds of stupidity into their browsers, never making more than a token effort at interoperability and openness.
IFRAMEs make entire industries that could not have existed before possible. One of the huge errors of XHTML Strict was not including IFRAMEs, which breaks an enormous range of analytics and ad-serving tag packages. IMO, the W3C is entirely run by people who have absolutely *no* idea how to actually write or maintain a website. (At least commercially.)
I mean, it took CSS until version 3 to get columns. Version 3?! COLUMNS?! Christ.
I'd also like to point out that:
1) HTML was designed to be extensible. In a sane world, people wouldn't care if IE added a MARQUEE tag because browsers that didn't support it would simply ignore it. Even ActiveX was an extension allowed by the very design of HTML. (Now, it turns out that in retrospect, that making HTML extensible was a bad idea, but you can't fault browser makers for using the capabilities given to them.) In short, Netscape and Microsoft aren't satan because someone told them HTML was extensible and they extended it.
2) The reason those extensions became critical parts of the web infrastructure is because the W3C moves fucking slow.
I need only point to the mountain of good content lost in a morass of excreta passing for markup for evidence.
Wait, slow down a second-- "lost?" Can you explain how content can be "lost" simply because it contains bad markup? Am I missing something? JC Penney's product pages are fucking horrible, but none of the content in them is "lost."
As long as HTML is liberal, and we expect people to write it, then browsers all have to have their own intuition at this level. That means anybody writing something that will end up on the web has to know about the whole stack down to the level of the HTML rendering. That seems horribly low-level.
[snip]
Another big problem is that with all the intuition required in a browser, it makes it virtually impossible for new rendering engines to appear. The web would never get off the ground with the crap we've got out there today. I there to be more than 3 rendering engines in the world, and I want the specs to be simple enough that that's possible to achieve. If you want to talk about "important rules in software" and "the basic power of the web", then we should make implementing a rendering engine that meets the specs *possible*. Right now, no browser will ever come close, and the specs are already 10x more complex than will ever get implemented, but adding "guess what the user meant!" crap just sucks the life out of any progress that these rendering engines have to do. IE8 punted and included IE7-mode -- that's how bad it's getting.
Possibly, and in fact I agree with many of your points. But since there are millions of pages in HTML4 that aren't going away, browsers are *already* stuck having to do that. That's the point that a lot of XHTML advocates don't seem to get-- XHTML doesn't make HTML go away. Nor does any new standard you create, no matter how awesomely great it is.
In a world where you *must* render HTML4, adding XHTML to the mix actually *increases* the complexity of browsers, not reduces it.
KOMO is one of the largest TV broadcasters in Seattle. Possibly the largest, although KING might have them beat. Yah, they also own a AM station.
I mean, your point still kind of applies, but you might want to look up with KOMO actually is before you chime in with the podunk AM radio comments... http://en.wikipedia.org/wiki/KOMO-TV
I'll really be concerned about that in 2087 when Verizon finally starts rolling FIOS out in Snohomish. Christ, we had DSL in 1997, what the hell do you have to do to get FIOS? Sacrifice a virgin? Then to pour lemon juice on the wound, they SATURATE the airspace, billboards, advertising on mass transit (especially buses that go to Snohomish!) telling people to order FIOS. Meanwhile I know hicks in Louisiana who can't even spell the word "fiber" who have it in their dirt-floored one-room shacks.
What really killed XHTML is that it became a buzzword used by people who had absolutely no idea what the hell they were doing. A bunch of idiots jumped on the XHTML bandwagon, added lots of slashes to their broken HTML code, and called it XHTML. Browsers ignored the extra slashes and rendered the broken HTML the same way they always had, and the idiots thought XHTML was the greatest thing since sliced bread. Half the Web looks like that now, and there's nothing the W3C can do to make everybody start writing valid XHTML, so why even bother?
Write this down:
Any solution that doesn't take into consideration human psychology is a flawed solution.
It also deprecated a lot of the older tags that were made obsolete by CSS hence encouraging better separation of document structure and presentation. Unfortunately HTML5 undoes this particular good work because it caters to the lowest common denominator (i.e. bad developers who don't "get" separation of concerns and trivially parsable markup).
Content and presentation are already separated at a higher level: the Content Management System does it.
I'll be 100% frank with you: I don't really "get" it either. The content is the article. The presentation is the templates managed by the CMS that displays the article. Tags inside the article (like EM or STRONG) are part of the content, not part of the presentation-- those sections would still need to be italicized and bolded even if the content was being viewed in an entirely different manner like, for example, in a newspaper.
Oh, it's been explained to me, dozens of times. But I've just never been convinced of the value.
And you know what? Be prepared to hate me: I *like* the CENTER tag. You wrap *anything* in your document with a CENTER tag, and it's centered. It just fucking works, all the time, no matter the element, with no fuss. I'm sure Microsoft, Mozilla, and Apple have written thousands of lines dedicated purely to getting the CENTER tag working, and I really appreciate that work.
Now try to imagine Microsoft, Opera, Mozilla, and Google implementing that compatibly.
Well, considering they're already parsing HTML 1-4, they *already have it implemented*. Their logic might not be exactly the same as the HTML5 logic, but it's not like Firefox/IE/Safari have zero code now to handle that situation. HTML5 just means auditing that behavior to ensure its compatible.
The main key is, that, while HTML5 is based on the superior SGML (because of more freedom), XHTML had started to enforce strictness and cleanness. This meant the browser did not have to support a ton of typos, just because the editor was a freakin' lazy ass. Imagine a compiler that would eat any typo. Missing brackets, braces, semicolons, object-function separators, completely meaningless semantic messes. HTML4 browsers eat it all.
Totally wrong. One of the most important rules in software is: "be liberal in what you accept, and strict in what you output." XHTML does that first part COMPLETELY WRONG.
Here's the thing: while you're going on about dumbing-down, you're completely ignoring the basic power of the web-- the fact that everybody can (and should) participate in it.
You long for a world where, if I put my STRONG tag and my EM tag in the wrong order, a completely trivial error, the browser should show absolutely nothing. Even though it's obvious to everybody what I *meant*, since a computer thinks like a computer and rejects it like a retard.
You know what? I already have enough computer programs that act like retards. I want my software to be smart, so that humans don't have to worry about that trivial shit you seem to relish so much. In the ideal world, software would *do what I mean*, not *do what I say*. Your world sucks.
It doesn't help, BTW, that "dumbing down" is always one of those grouchy "get off my lawn" arguments people make when they don't really have any actual arguments.
And how do we move into your world? Well, first of all we completely and utterly delude ourselves into thinking that HTML4 will disappear overnights and XHTML can make browser simpler to implement. Thus deluded, we then create a new standard which offers absolutely *nothing* new over the old standard, then tell all the browser makers to add that into the already-too-long list of standards they need to support. Oh, and just to cement W3C's isolation from the *actual* work of creating and maintaining webpages, let's make this new standard incompatible with some of the most popular web analytics tags out there.
XHTML was retardation from day 1.
Now the flamebait part: of course what you're probably really after is some kind of elitist high-priesthood-of-technology bullshit for your own selfish reasons.
The real problem is that everybody dropped HTML to work on XHTML in the first place:
"Hey, I know! Let's make a new standard called XHTML Strict which adds *no* new features to the old standard, which doesn't work with the majority of web analytics packages out there, and which adds more complication for browser makers!" "Good idea!"
What a gigantic waste of time and effort-- and now poor browser makers have to support a standard that's completely pointless, and (even worse) was completely pointless even when it was current. Not that the W3C wasting time and effort on pointless things is anything new, but eh.
And now my obligatory "I told you so": I told you so.
He wants to be a designer, not a developer. He wants to be the Producer or Director, not the Set Carpenter. Totally different role. (And much, much harder to break in to. Heck, it's probably easier to produce a movie, frankly.)
Get into a community, would be my recommendation. There's XNA for Xbox games (and that uses C#, which'll be easier to learn than C++ if you're starting from scratch.) There's Torque. There's modding communities for every game engine you've seen.
The language question is kind of misleading, for a few reasons:
1) You don't need to be a programmer to be a great game designer. Writing a design document doesn't require writing code; only a basic knowledge of what is possible with code. Now, that said, you have little chance of "breaking in" until you've actually made a couple of games, and you can't actually make games without knowing some type of coding.
2) The environment you write your first game in determines what language to learn. If you want to write a Playstation game, you'll need C++. If you want to write a Xbox game, you'll need either C++ or C#. If you want to write a Flash game, that's ActionScript. If you want to run your own MUD, that's probably C but possibly C++. In all those cases, you'll also need some database experience, likely. If you want to mod an existing game, that's generally Lua. In short, you need to decide what you're making before you make it.
discovering that a giant termite colony was being controlled by an alien machine in the core of the Earth dedicated to safeguarding humanity
Uh-huh...
and in the end, single handedly repels the invasion.
Wha...?
The hostile alien single-handedly repels his own invasion? Or the termites were invading? Or the termites single-handedly repel the hostile alien's invasion, even though they don't have hands? I've never been more confused.
Anyway, as a dutch person who has biked in the states (Knoxville, TN area) I was absolutely appaled by the risks bikers have to take on americans roads. I was trying to make my way from my parents house to knoxville, a minor 10 mile ride, and at one point found myself forced to take an interstate... holding to the shoulder of course but it was rocky and all... worthless and dangerous.
An Interstate? Or just a highway?
It's illegal to bring a bike (or really anything that can't do at least 45-50 MPH) onto an freeway. And all Interstates are freeways. Given that, of course they don't bother to make them safe for bikes. You're lucky you didn't get an expensive ticket for that.
If you're talking about just a highway, then, yeah, those are pretty bad in some states... Highway 2 and Highway 9 in Washington State are almost suicide with a bike, and in a lot of places don't have reasonable alternate routes.
Damn them and their "freedom!" Can you believe the gall of wanting to make use of roads their (substantially-more-than-yours) fuel taxes paid for? Those assholes.
A more relevant movie reference would be Capricorn One, which featured a fake trip to Mars. (And I think must have been the inspiration for many/most of the moon hoaxers.) Plus it starred OJ Simpson.
Slashdot Mirror
Where in the midwest is 12 hours away from NYC? Maybe my sense of geography is all out-of-whack being from Washington State...
Since there's no reference implementation, that's *always* true, though. Maybe not for that little particular scenario, but since the standards aren't (and probably will never be) 100% complete, there will always be things like that that browsers do differently.
And then the malware would just programmatically click the "Yes" button. You've solved nothing, unless you can work it into one of Microsoft's "Alternate Desktop"-type environments (like the control-alt-delete desktop, or the UAC desktop in Vista.)
Well creating a web page is different from creating content. If you want to voice your opinion but be bothered properly format the code then use facebook or some other blog software.
Weasel, weasel, weasel. And yet when you create a new Facebook account and start blogging with it, you're creating new pages. Stop trying to weasel out of what you said.
HTML hasn't gone away yet but it will. Who's using HTML 2.0?
How will it? There are thousands of completely unmaintained sites in HTML. Some of them are forgotten, some of them have authors who are dead. And, most importantly, all of them contain critical content that shouldn't disappear simply because of the file format they're in.
The great delusion of XHTML advocates is that HTML would somehow disappear. I don't see how they expected that to happen, it makes absolutely no sense to me.
If you shop at JC Penny,that's not going to help people's image of you. ;)
Wow, you're an elitist asshole no matter what the topic. You also completely missed my point.
Millions of people shop at JC Penney. Millions. If you release a browser that won't render bad HTML, you've just released a browser that's absolutely useless for the millions of people who shop at JC Penney. Your marketshare will plummet.
Just because some people do things wrong doesn't mean they should be allowed to. HTML/XHTML are still languages. We wouldn't accept any old English gibberish within a professional environment so why should we accept gibberish HTML?
People accept English gibberish all the freakin' time. What planet do you live on? Pick any random page on IBM.com, or Oracle.com, or read any Microsoft press release. Here's an example from Oracle.com:
"Multi-Dimensional Business Process Management--Provides unified support for human-centric, system-centric, and document-centric processes, and dynamic process adaptation with integrated process intelligence"
JC Penny has no reason to be writing such bad code. Even if they are using a CMS there is no excuse. They have a broken form tag, two opening and closing body tags and that's just two big ones I've noticed a very quick glance. Those aren't mistakes from automation, they're just bad mistakes that should not be made and developers shouldn't have to waste their time accounting for web developer incompetence. The only correct outcome that people should get from viewing that page is that it breaks and doesn't display. Then the web developers fix it. If they can't fix those problems they don't deserve their jobs.
And yet! Despite all your vitriol, that site exists here in the real, non-theoretical, world and therefore real, non-theoretical, browsers need to accept it. Whether or not they "deserve their jobs" is not your call to make-- it's JC Penney's, and they obviously are happy with whatever service they're getting.
Hell, you have no reason to spell "JC Penney" consistently wrong, and yet you're doing it. Human beings make mistakes, eh?
I-Frames work in XHTML transitional. No one said you must use XHTML strict at all times nor did anyone say they would never be replaced.
The fact that XHTML Strict doesn't allow iframes is just evidence that the people who created it from their ivory tower have *no fucking clue* how actual websites in the actual real world work. Like it or not, iframes are as critical a feature to the web as XMLHttpRequest at this point, and any standard that doesn't include them is worthless.
Marquee is an awful tag as is blink. They shouldn't be used because the only reason for making proprietary tags is to lock someone into using your browser and neither side did just to make the web a better place. They did it for the reason to lock people into their browser. Just as MS making their own Java VM was done purely to ruin Java.
Active X isn't a necessary or required extension, it is again something that was meant to lock people in one browser. In an ideal world people would o
Take your example of the strong and em tags, but lets extend it a bit further and say you've defined (for some unknown reason) to define in CSS that 'strong' displays in Arial and 'em' in Times. You write hi , simple enough right? yeah, except that which font should it use? assume the standard specifies that inner tags overwrite the style of outer ones. IE decides that, since you wrote first, thats the outer one and so uses Times. But Firefox sees that was *closed* first and so is the inner one, therefore it should go with Arial.
For the record, the answer is: "I write that code, then I test it and see which font shows up. If it's not the font I want, I re-write the code so the font I want shows up."
I'm actually after reading this thread and some linked articles changing my mind about the problem. But, on the other hand, I also live in the real world where browsers don't have the option of dropping HTML4 support. (Or indeed support of bad HTML of any kind.)
So we end up with this situation:
1) Browsers support bad HTML for legacy/compatibility reasons
2) Bad web developer sees that his bad HTML still works
3) Bad web developer continues to write bad HTML, since that's all he knows
4) Browsers continue to render the new bad HTML, due to point 1
Standards can't re-write the past. I don't know what the solution is, but I know that XHTML certainly wasn't it, and I'm happy to see it dropped for something more promising.
No, no, no, those are only features to web developers. What about *users*? Those pink squishy things that actually use the browser? Debugging stylesheets? Christ.
And seriously, how many people use any of those things you listed? I'm pretty sure I've never in my life come across a RDF or MathML or XUL file, and the only thing I know about SVG is that it's a graphics format nobody supports. Isn't Xul the bad-guy from the first Ghostbusters movie?
You're conflating 'putting content on the web' with 'writing HTML'. They don't mean the same thing.
Except that's not what the parent I was replying to said. He said this:
"Anyone too lazy to code nice neat xhtml shouldn't be allowed to create web pages."
Notice how it's not qualified in any way. "Thetoadwarrior" literally thinks that you should be forced to entirely understand XHTML before you should be "allowed" (by whom?) to create a webpage. He's being a total asshat, so please don't attempt to defend him.
XHTML would have forced makers of stupid (i.e. non-XML-compliant) software applications to fix their engines. That would have required lots of effort, but the value of such an effort is philosophically similar to enforcing health and safety standards on manufacturing processes. Yes, it's cheaper to create quick and dirty implementations, but the public good is better served by enforcing minimal levels of quality. It increases the cost of production, but increases the value of the product, too.
Except that's wrong, because XHTML existing doesn't make HTML4 go away. Browsers will have to render HTML4 until the end of time, if only for backwards compatibility purposes-- given that, bad web developers used to HTML4's quirks and idiocies will simply continue to code in HTML4 and ignore XHTML altogether.
And... gasp... after years of XHTML, that's exactly what's happened. The existence of HTML4 hasn't helped this site improve any, and it's one of the most popular e-commerce sites on the web.
What I don't get is why so many people who were behind XHTML believed that it would make HTML4 go away. Either they didn't bother thinking about the situation for more than 10 seconds, or they are entirely clueless about human psychology.
HTML5 tries for a middle road wherein the parser tries to be more forgiving while at the same codifying the ways in which it should fail. It tries to make the failure modes as graceful and predictable as possible. It's sold as a more pragmatic approach to Tag Soup, a problem that's bedeviled us since FrontPage first reared its zombie head.
And exactly what W3C should have done instead of wasting everybody's time on XHTML in the first fucking place.
For my part, I think it's the wrong approach. I don't think it's as wrong as some of the sins committed by Netscape (, frames, etc.) and Microsoft (iframe, marquee) in the early days, when they treated the W3C as their bitch, foisting all kinds of stupidity into their browsers, never making more than a token effort at interoperability and openness.
IFRAMEs make entire industries that could not have existed before possible. One of the huge errors of XHTML Strict was not including IFRAMEs, which breaks an enormous range of analytics and ad-serving tag packages. IMO, the W3C is entirely run by people who have absolutely *no* idea how to actually write or maintain a website. (At least commercially.)
I mean, it took CSS until version 3 to get columns. Version 3?! COLUMNS?! Christ.
I'd also like to point out that:
1) HTML was designed to be extensible. In a sane world, people wouldn't care if IE added a MARQUEE tag because browsers that didn't support it would simply ignore it. Even ActiveX was an extension allowed by the very design of HTML. (Now, it turns out that in retrospect, that making HTML extensible was a bad idea, but you can't fault browser makers for using the capabilities given to them.) In short, Netscape and Microsoft aren't satan because someone told them HTML was extensible and they extended it.
2) The reason those extensions became critical parts of the web infrastructure is because the W3C moves fucking slow.
I need only point to the mountain of good content lost in a morass of excreta passing for markup for evidence.
Wait, slow down a second-- "lost?" Can you explain how content can be "lost" simply because it contains bad markup? Am I missing something? JC Penney's product pages are fucking horrible, but none of the content in them is "lost."
As long as HTML is liberal, and we expect people to write it, then browsers all have to have their own intuition at this level. That means anybody writing something that will end up on the web has to know about the whole stack down to the level of the HTML rendering. That seems horribly low-level.
[snip]
Another big problem is that with all the intuition required in a browser, it makes it virtually impossible for new rendering engines to appear. The web would never get off the ground with the crap we've got out there today. I there to be more than 3 rendering engines in the world, and I want the specs to be simple enough that that's possible to achieve. If you want to talk about "important rules in software" and "the basic power of the web", then we should make implementing a rendering engine that meets the specs *possible*. Right now, no browser will ever come close, and the specs are already 10x more complex than will ever get implemented, but adding "guess what the user meant!" crap just sucks the life out of any progress that these rendering engines have to do. IE8 punted and included IE7-mode -- that's how bad it's getting.
Possibly, and in fact I agree with many of your points. But since there are millions of pages in HTML4 that aren't going away, browsers are *already* stuck having to do that. That's the point that a lot of XHTML advocates don't seem to get-- XHTML doesn't make HTML go away. Nor does any new standard you create, no matter how awesomely great it is.
In a world where you *must* render HTML4, adding XHTML to the mix actually *increases* the complexity of browsers, not reduces it.
KOMO is one of the largest TV broadcasters in Seattle. Possibly the largest, although KING might have them beat. Yah, they also own a AM station.
I mean, your point still kind of applies, but you might want to look up with KOMO actually is before you chime in with the podunk AM radio comments... http://en.wikipedia.org/wiki/KOMO-TV
Also, having a Slashdot account.
I'll really be concerned about that in 2087 when Verizon finally starts rolling FIOS out in Snohomish. Christ, we had DSL in 1997, what the hell do you have to do to get FIOS? Sacrifice a virgin? Then to pour lemon juice on the wound, they SATURATE the airspace, billboards, advertising on mass transit (especially buses that go to Snohomish!) telling people to order FIOS. Meanwhile I know hicks in Louisiana who can't even spell the word "fiber" who have it in their dirt-floored one-room shacks.
Fucking Verizon.
What really killed XHTML is that it became a buzzword used by people who had absolutely no idea what the hell they were doing. A bunch of idiots jumped on the XHTML bandwagon, added lots of slashes to their broken HTML code, and called it XHTML. Browsers ignored the extra slashes and rendered the broken HTML the same way they always had, and the idiots thought XHTML was the greatest thing since sliced bread. Half the Web looks like that now, and there's nothing the W3C can do to make everybody start writing valid XHTML, so why even bother?
Write this down:
Any solution that doesn't take into consideration human psychology is a flawed solution.
It also deprecated a lot of the older tags that were made obsolete by CSS hence encouraging better separation of document structure and presentation. Unfortunately HTML5 undoes this particular good work because it caters to the lowest common denominator (i.e. bad developers who don't "get" separation of concerns and trivially parsable markup).
Content and presentation are already separated at a higher level: the Content Management System does it.
I'll be 100% frank with you: I don't really "get" it either. The content is the article. The presentation is the templates managed by the CMS that displays the article. Tags inside the article (like EM or STRONG) are part of the content, not part of the presentation-- those sections would still need to be italicized and bolded even if the content was being viewed in an entirely different manner like, for example, in a newspaper.
Oh, it's been explained to me, dozens of times. But I've just never been convinced of the value.
And you know what? Be prepared to hate me: I *like* the CENTER tag. You wrap *anything* in your document with a CENTER tag, and it's centered. It just fucking works, all the time, no matter the element, with no fuss. I'm sure Microsoft, Mozilla, and Apple have written thousands of lines dedicated purely to getting the CENTER tag working, and I really appreciate that work.
Now try to imagine Microsoft, Opera, Mozilla, and Google implementing that compatibly.
Well, considering they're already parsing HTML 1-4, they *already have it implemented*. Their logic might not be exactly the same as the HTML5 logic, but it's not like Firefox/IE/Safari have zero code now to handle that situation. HTML5 just means auditing that behavior to ensure its compatible.
Bullshit. Every person on Earth should be allowed, and encouraged, to create web pages. I hate this elitist crap.
The main key is, that, while HTML5 is based on the superior SGML (because of more freedom), XHTML had started to enforce strictness and cleanness. This meant the browser did not have to support a ton of typos, just because the editor was a freakin' lazy ass. Imagine a compiler that would eat any typo. Missing brackets, braces, semicolons, object-function separators, completely meaningless semantic messes. HTML4 browsers eat it all.
Totally wrong. One of the most important rules in software is: "be liberal in what you accept, and strict in what you output." XHTML does that first part COMPLETELY WRONG.
Here's the thing: while you're going on about dumbing-down, you're completely ignoring the basic power of the web-- the fact that everybody can (and should) participate in it.
You long for a world where, if I put my STRONG tag and my EM tag in the wrong order, a completely trivial error, the browser should show absolutely nothing. Even though it's obvious to everybody what I *meant*, since a computer thinks like a computer and rejects it like a retard.
You know what? I already have enough computer programs that act like retards. I want my software to be smart, so that humans don't have to worry about that trivial shit you seem to relish so much. In the ideal world, software would *do what I mean*, not *do what I say*. Your world sucks.
It doesn't help, BTW, that "dumbing down" is always one of those grouchy "get off my lawn" arguments people make when they don't really have any actual arguments.
And how do we move into your world? Well, first of all we completely and utterly delude ourselves into thinking that HTML4 will disappear overnights and XHTML can make browser simpler to implement. Thus deluded, we then create a new standard which offers absolutely *nothing* new over the old standard, then tell all the browser makers to add that into the already-too-long list of standards they need to support. Oh, and just to cement W3C's isolation from the *actual* work of creating and maintaining webpages, let's make this new standard incompatible with some of the most popular web analytics tags out there.
XHTML was retardation from day 1.
Now the flamebait part: of course what you're probably really after is some kind of elitist high-priesthood-of-technology bullshit for your own selfish reasons.
The real problem is that everybody dropped HTML to work on XHTML in the first place:
"Hey, I know! Let's make a new standard called XHTML Strict which adds *no* new features to the old standard, which doesn't work with the majority of web analytics packages out there, and which adds more complication for browser makers!" "Good idea!"
What a gigantic waste of time and effort-- and now poor browser makers have to support a standard that's completely pointless, and (even worse) was completely pointless even when it was current. Not that the W3C wasting time and effort on pointless things is anything new, but eh.
And now my obligatory "I told you so": I told you so.
He wants to be a designer, not a developer. He wants to be the Producer or Director, not the Set Carpenter. Totally different role. (And much, much harder to break in to. Heck, it's probably easier to produce a movie, frankly.)
Get into a community, would be my recommendation. There's XNA for Xbox games (and that uses C#, which'll be easier to learn than C++ if you're starting from scratch.) There's Torque. There's modding communities for every game engine you've seen.
The language question is kind of misleading, for a few reasons:
1) You don't need to be a programmer to be a great game designer. Writing a design document doesn't require writing code; only a basic knowledge of what is possible with code. Now, that said, you have little chance of "breaking in" until you've actually made a couple of games, and you can't actually make games without knowing some type of coding.
2) The environment you write your first game in determines what language to learn. If you want to write a Playstation game, you'll need C++. If you want to write a Xbox game, you'll need either C++ or C#. If you want to write a Flash game, that's ActionScript. If you want to run your own MUD, that's probably C but possibly C++. In all those cases, you'll also need some database experience, likely. If you want to mod an existing game, that's generally Lua. In short, you need to decide what you're making before you make it.
which involved a hostile Alien being
Ok...
discovering that a giant termite colony was being controlled by an alien machine in the core of the Earth dedicated to safeguarding humanity
Uh-huh...
and in the end, single handedly repels the invasion.
Wha...?
The hostile alien single-handedly repels his own invasion? Or the termites were invading? Or the termites single-handedly repel the hostile alien's invasion, even though they don't have hands? I've never been more confused.
The law in Washington State is that you must pull over if you're obstructing 5 vehicles or more. Of course driving laws vary by state.
Where I live (Costa Rica) it is a tidbit better than where I used to live before (Hungary)
You must have an AWESOME accent.
Anyway, as a dutch person who has biked in the states (Knoxville, TN area) I was absolutely appaled by the risks bikers have to take on americans roads. I was trying to make my way from my parents house to knoxville, a minor 10 mile ride, and at one point found myself forced to take an interstate ... holding to the shoulder of course but it was rocky and all ... worthless and dangerous.
An Interstate? Or just a highway?
It's illegal to bring a bike (or really anything that can't do at least 45-50 MPH) onto an freeway. And all Interstates are freeways. Given that, of course they don't bother to make them safe for bikes. You're lucky you didn't get an expensive ticket for that.
If you're talking about just a highway, then, yeah, those are pretty bad in some states... Highway 2 and Highway 9 in Washington State are almost suicide with a bike, and in a lot of places don't have reasonable alternate routes.
Damn them and their "freedom!" Can you believe the gall of wanting to make use of roads their (substantially-more-than-yours) fuel taxes paid for? Those assholes.
A more relevant movie reference would be Capricorn One, which featured a fake trip to Mars. (And I think must have been the inspiration for many/most of the moon hoaxers.) Plus it starred OJ Simpson.
http://us.imdb.com/title/tt0077294/