If you're expecting me to say "Made ya look," I'm not. Believe it or not, I'm actually quite serious. And I'll give a quick explanation why.
Since HTML can be coded wrongly, it allows more people to put up websites, especially if their strong suit isn't website building. I suppose there are some purists who think that such people shouldn't build websites at all, but then what would we look at?
I know of some websites that have HORRIBLE coding... and great content. The webmaster might have his strong suit in art, or in writing, but not HTML. So do we say that he should take his website off the net, simply because he doesn't quite know how to code it right?
On the other hand, there are sites that check out 110% in every validator under the sun, and are a snore with a capital ZZZZZZZZZ.
Secondly, the ability to have "bad HTML" gives webmasters a starting point. The fact that they can PUT a site up gives them a sense of triumph. The problem starts only when they decide to rest on their laurels, and don't think they need to improve. (Come to think of it, I think that was Microsoft's mistake, too.)
Anyways, there's my position, I will head off and start coding in HTML 2.0, while you proceed to scream your <font> tags off.
Actually it's bad code that makes it harder for people that don't have html as their "strong suit". The whole point of html is that it is very simple and very basic, with the intention of making it usable by all. HTML was put into wide use for that reason, because SGML was way to much for Joe Regular to cope with just to put up a simple page for his holiday diary.
Proper, clean mark up is VASTLY more simple and clean than the monsterous messes that most people think is "how you code". If they saw proper semantic code I'd bet masses of people would have no qualms about taking a stab at learning html at all.
Mr Herer is right. Look at the source of these too websites, and tell me which is easier to read, and to design (ignore the actual designs. Given that markup, which would be easier to create a design with?)
You see the sheer complexity bad coding can give the page? The sheer size a page can take on because of it? The amount of time that would be spent debugging it? You can't honestly that clean, valid, semantic coding is harder that the presentational crap on many websites today. I think it has more to do with a lack of knowledge on this topic, and a lack of teachers and website tutorials about it. If I had been taught the proper way to begin with, I know I would have done much better. But so much of it became way more complicated than need be. The point of semantics and validity is to make (x)HTML simpler, smaller, and easier to write/interpret.
Microsoft has no problem, Apple has the problem. Microsoft knows it must improve, but it has to wait until Apple come sout with it, steal it, and claim it be theirs and make millions off it, that's all. As for IE, its a sense of superiority, despite them all knowing it should be changed.
And as for the topic, Mr. Herer is right (for once, j/k).
I fail to see why poorly formed HTML is any strength, much less HTML's greatest. Sure, it may allow any Tom, Dick, or Jane to build a "website" (if you want to all it that), but unfortunately poor Tommy probably doesn't know the first thing about design or usability. We've all seen company (yes, company!) websites that look like the guys 12 year old son built it. Tell me how much money that website is making for the owner. My point is, the people who don't know how to write proper HTML (or my personal choice, XHTML - more on that later) probably don't know what it takes to build a successful website. "But wait," I hear you say, "there are many web development companies who don't use standards compliant code." True, I can't argue with that. However, if invalid code simply wouldn't work, they'd learn in a quick hurry.
Now on to the XHTML. When XHTML is passed as an application of XML (as it should be), in a decent browser (not IE) the page will simply not display. Instead you will get an XML parsing error. Now tell me it isn't important to have well-formed HTML!
It all boils down to the fact that anyone who calls themself a web developer should invest the time it takes to learn how to program correctly. If that's too much to ask, maybe that person needs to find a different occupation. Try doing some "real" programming for a while, and then tell me that syntax doesn't matter.
Okay, I think what I've been saying has kinda gotten lost in the shuffle. If you'll take a look at HTML from the page I posted ( http://www.liondogworks.com/fp-01.HTML )
It wouldn't take much to validate it. It's not a horrific slop-job of massive amounts of cobbled-together coding. It's just missing a bit of data.
Then again, would you consider that /bad/ HTML, or incomplete? Or does it matter?
Last edited by Mr Initial Man; 09-30-2004 at 03:42 PM.
Originally posted by steelersfan88
And as for the topic, Mr. Herer is right (for once, j/k).
Anyway. In my view incomplete mark up is preferable to malformed and outright incorrect code, but still only by a very narrow margin. The page you offered as an example works without a DTD for two reasons:
1) Most popular browsers are created to guess and place a DTD in the document in the hope that a page may still be displayed in some kind of ordered structure of rules, just in case it comes across a page someone made and couldn't be arsed to stick a DTD in like a bell-end.
2) There is no mark up there to screw up. Using that page as an example of how a page can "work" even without a DTD is no different from having one ball and one cup and saying you can guess wich cup the ball is under every time. Of course you're gonna get it right. There's nothing to get wrong. Put a real-world, mid-scale page up without a DTD and then you get to see what a mess can be made when no DTD is offered.
What you have been saying has not been lost in the "shuffle" either (not on me anyway). I aswered your question in my first post. Proper semantic markup is vastly cleaner and far easier to read and write than the abhorrant monstrosoties that most people make through thinking that's "just how to do it". Or to simplify:
Bad mark up is the reason people think using html is hard.
If you can use a highlighter pen, you can do html.
Don't apologise. If we didn't discuss these things, then nobody would learn.
In my view there are two things that are holding back the development of sites on the internet:
1) The attitude discussed here of: "If it works in IE/If it puts most of the stuff on the page on whatever I'm viewing it in, then it'll do because I can't be arsed finishing it/doing it right". If the modern standards of code are not used, then not only do we have all the problems of inaccessibility and incompatability etc, but we are also presented with the huge problem of people not seeing what modern standards compliant mark up (along with css) can acomplish. If nobody sees it, then fewer people know of it and fewer people starting out will use it. Thus perpetuating the cycle of bad, limited and limiting code being used and the great advancements made in the past 6 or so years going to waste.
Originally posted by Mr Herer 1) Most popular browsers are created to guess and place a DTD in the document in the hope that a page may still be displayed in some kind of ordered structure of rules, just in case it comes across a page someone made and couldn't be arsed to stick a DTD in like a bell-end.
Perhaps I just miss-understood what you were getting at, but browsers don't guess at the DTD the developer was trying to use if one is absent. If a document doesn't have a DOCTYPE (or has an imcomplete/incorrect DOCTYPE) the browser will go into quirks mode. Read up on DOCTYPE switching for more info.
Most Web Dev companies dont write in strictly valid markup because its not productive. The big guys dont care whether the Web is full of invalid code, they just want the clients money.
If they can produce a DreamWeaver Web Site in 3 days and have it fully operational within the week, who cares if its valid? The client certainly doesnt (he/she doesnt even know what valid code is!).
Infact, only the web-savvy people have even heard of the W3C. Its far from law to have your Markup validated, so why bother doing it if its ultimately going to cost you money?
I dont think having Valid code is that important anyway. Provided your site looks fine in the top 3 or 4 browsers. Noone, especially regular web surfers (just about everyone) is going to know or care about xHTML or whether your site will look perfect in every browser known to man and every handheld device.
I have no problem with people spending extra time perfecting their code, not at all. But in the big world of business, its simply not necessary -- even counterproductive.
Most Web Dev companies dont write in strictly valid markup because its not productive.
That depends on how you define productive.
Its far from law to have your Markup validated, so why bother doing it if its ultimately going to cost you money?
You need to look at the big picture. Sure, it may be a bit cheaper to originally deliver a non-standards compliant, table-based design, but what happens when the client needs things updated? You need to think longer term.
...whether your site will look perfect in every browser known to man and every handheld device.
That shouldn't be the goal. Ensuring that the content is deliverable regardless of the device accessing it should be.
But in the big world of business, its simply not necessary -- even counterproductive.
Again, you're not looking at the big picture. The long-term portability of a well-formed, intelligent site is very likely to save a company money, if they are in it for the long haul.