View Full Version : what's wrong with loose coding

11-26-2002, 06:00 PM
This isn't really a question, and it certainly isn't an invitation for another IE/Mozilla argument.

But it is those arguments which have prompted this thread. What I'm interested in is an academic discussion, on the following broad lines:

I consider that a language which can be loosely coded, and still work, is a good thing. Others feel that markup languages should be bad-*** strict to the extent that incorrect coding should not work at all.

(polite) views?

11-26-2002, 06:08 PM
Stricter coding makes it easier for others to read what you have coded and allows the browser to render the page faster if it doesn't have to correct for sloppy coding.

11-26-2002, 06:26 PM
i'm one of those who believe that incorrect code shouldn't run at all. you wouldn't expect C or Java to tolerate some of the things that pass in HTML. why should html or javascript be expected to be more lenient? by making them stricter, mistakes become easier to find. that is, if there's only one way that works, and you know what that is, then you can tell, when that's not what you've got.

11-26-2002, 06:44 PM
strict coding is better.
i agree with joh6nn completely.
it only promotes proper webpages, theres no reason to argue.
there should be 1 standard

11-26-2002, 07:12 PM
surely this wouldnt be correct:

<font style="font:8pt arial"><center>

but if you asked IE, it would say otherwise.

to enforce a single "correct" standard now would be to rearange New York City to be more traffic efficient, theres just already to much out there, if a correct single standard was enforced, it would be gradual and take time.....

11-26-2002, 08:15 PM
Isn't that what the World Wide Web Consordium is trying to do with XHTML? Move people over slowly. Yeah I agree with joh6nn too.

11-26-2002, 09:21 PM
Just to play devil's advocate (and also because I've argued the side that it is bad to death recently in other threads), by allowing "loose" coding practices it lowers the difficulty for brand new web designers. Without fresh minds and creativity, the web would stagnate. However, if no one could enter the field because they forgot to close a <p> or accidentally forgot to close an attribute value in a page consisting of hundreds of lines of markup, where would we be?

Of course, there are validators that can point out the line and character where the problem is, but:
"SGML error detected at line 123: Element cannot contain type PCDATA"

or something may only scare away new people.

In my own opinion though, there are enough resources to overcome that obstacle, and it really isn't an issue. Web accessibility depends upon correct markup. Not only that, but by writing bad markup that only renders in IE, you are tying the future of the web into one vendor, Microsoft.

It is impossible for any rendering engine to fully emulate Trident (IE's rendering engine) too without seeing its source code. This means any alternative web browsers won't be able to succeed, and since IE is only for Windows and Mac, all *nix users will be out of luck too.

And the concept of bad code working just doesn't cut it when comparing to any other field.

If I forget a semi-colon in my C++ program, tough luck, it isn't going to compile. Any SGML or XML application should be the same.

11-27-2002, 06:24 AM
I personally like strict code and try to follow it best I can, but if someone wants to spend more time finding their errors because of their sloppy coding thatís their problem. Making everyone follow a rigid guideline is no different than censorship. Maybe this is a loose comparison, but why should one group determine what everyone else has to follow? Why are so many people threatened by bad coding? If their code is so bad their shrinking clientele list will represent that and you will get their customers anyway.

11-27-2002, 09:33 AM
If browsers acted like C compilers then network problems, missing/corrupt packets etc would stop many pages displaying on a random basis , browsers have to allow for loose coding to a point I assume for this reason,
On ocaision this forum for instance outputs some strange characters at the head of the page , if the browser was too fussy you would see nothing.

Even Mozilla will display loose code the best it can, I dont see that as an issue, and agree totally with Webmarkart's point.

Motif Webs
11-27-2002, 11:34 AM
As shocking as it may seem, I also support the code-it-right-the-first-time brigade. Then again I'm an old f@rt who's verging on the "standards are slipping, they wouldn't have got away with that in my day" phase.

However, there is something to be said for a browser that will interpret loosely written code. We all seem to be jumping on a browser that is actually clever enough to figure out what is meant even though something is coded incorrectly.

People have used the comparison of how things won't compile or run in other languages when there's even the smallest mistake. Yet here we have a program that will render even very poorly written code. I can't quite put my finger on it, but to me it's almost a wonderous thing, a sort of fuzzy logic at work if you like.

If anything maybe other programs should be able to figure out what is meant without having every single bit perfectly in place. Certainly, most have said this is a bad thing, without saying why having to be precise to the last semi-colon is a good thing. Maybe the programs, and possibly us as well, need to be less machine-like.

Like brothercake, I'm not trying to ignite a IE v Mozilla argument, because there are plenty of things wrong with IE that should be fixed. All I'm suggesting is that there is at least another, albeit philosophical, way of looking at things.

And in the spirit of being a completely contrairy barstaff, I can't end without saying that one problem with a browser rendering poorly written code is that you can't always be sure it's going to render things consistently the same way. Nor can you be sure just how loose your code can get before rendering ceases to be.

So in the end, standards and compliance to them are a good thing. Mind you, what those standards are and how they're decided is a completely different topic. (<minirant>I don't like the w3c's borg like approach - font and center were perfectly good, useful and adequate tags :) </minirant>)


11-27-2002, 03:54 PM
We are talking about markup languages not programming languages so I wouldnt compare this to C or java. You can not get away with this in xml, but I would think that most people that have a use for xml have knowledge of well formed documents. With CSS, XHTML, and XML there really is no room for loose coding and these kind of force you to be aware of your tags. I honeslty think that people who are writing loose code probaly are either a)Lazy b)using a WYSIWYG c)Just typing in a quick fix and not paying attention to tags. Is it necessary for html to be well formed? I think not. Is it neccessary for XHTML,XML to be well formed ...well yes. Although I would not reccomend it, but I think loose html is ok and markups that require to be well formed of course, will not work...in most cases should not allow loose coding. I think nowadays most html is spit out server side and as much as we would like to think that our client side html is always 100% I am sure there are times that there is some loose code.

11-27-2002, 05:06 PM
I did have programming and markup, in general, in mind for this - but it's interesting the difference between programming and markup approaches.

Now I think; Conceptually it still seems like a good thing that HTML can be so loose, and maybe when coding for an unpredictable environment (like web browsers) it's little short of essential that it should be like this.

But having said that, I'm very glad that XML is so strict; it would clearly defy the point of XML to allow it to be loose.

But things like C I'm not so sure; I can't see why it shouldn't be allowed to work if you miss EOL delimiters.

11-27-2002, 10:49 PM
i think that it's obviously best to do your best for standard perfect coding and i try to stick to it as best i can. one problem ive been faced with is wysiwyg... which are virtually never valid.

To prove this, myself and another website designer both set to work on exactly the same page. i was using notepad, he was using a new wysiwyg editor that i will allow to remain anonymous.. and although he was finished a few minutes earlier, his wouldnt validate.... as well as being packed full of unnecerssay formatting which i had eliminated with a few lines of css...

my point is... perhaps the makers of all the big editors should make their machines make valid coding... unlikely but it would be a huge help...

just my 2... um... pence... ;)

11-28-2002, 12:26 AM
The biggest problem with permitting loose markup is that there are no rules for it. Any browser that encounters, say, a missing closing tag is going to have to make an assumption as to where the tag should end. Otherwise it can't attempt to create a display. Since there is no standard rule for that situation, the result is bound to vary from browser to browser.

For simple mistakes, there may be no noticable difference, but for more complicated situations, the difference could be more dramatic. The problem then is that the designer has no way of knowing if it's the code or an inherit difference between the browsers.

I have to admit that in working with XML and XSLT to generate web pages, it can be really annoying to see an error message instead of the nicely formatted page I expected. But both IE and Mozilla do a nice job of pointing out the exact cause of the error. That makes it much easier to fix compared to staring at the page, looking for a mistake and then trying to trace it back to a line in the code.

11-28-2002, 01:49 PM
I vote for strict, personally.

I'm pretty sure had I run into "strict" syntax problems with HTML when I was a n00bie, it wouldn't have scared me off (it didn't/doesn't with javascript or ASP (disregarding the fact that VBScript allows somewhat "loose" coding ;)) and I'm sure it won't with .NET either!)... I would have just tried harder.