dbrimlow Posted December 16, 2007 Share Posted December 16, 2007 I found the perfect link today that describes most of the posts from beginners to css that come here for help ... this is a paraphrased version of it. If you are a beginner ... read it to expedite your being helped here much faster - because it will be one of the first things we will tell you to do. Those of you who actually take the patience to read this now, will save potentially hours of time later because one of us will help you, and solve your problem much faster than those who didn't read it: Why we won’t help you There is one scenario I see play out again and again in this forum and the HTML help forum as well as countless other forums all over the web. Newbie Designer posts a link to a test page, asking for help because it doesn’t behave as expected in this or that browser. Guru Designer replies, telling Newbie Designer that their page "doesn’t validate", and that they should go validate their page before asking such questions (with link to w3c validation tool) . There is no further discussion; no further replies are posted; no one else is willing to help. Why does this happen? Why won’t we help you? The short, smart-alec, Zen-like answer is that we are helping you, you just don’t realize it yet. The full answer goes like this: Validation may reveal your problem. Many cases of it works in one browser but not another are caused by silly author errors. Typos like missing attribute values can cause browsers to crash; validation catches these typos. Simple errors like missing end tags (such as </table> or </div>) or missing elements (such as <tr>) can cause different problems in different browsers. Small mistakes like this are difficult for you to spot in your own code, but the validator pinpoints them immediately. I am not claiming that your page, once validated, will automatically render flawlessly in every browser; it may not. I am also not claiming that there aren’t talented designers who can create old-style Tag Soup pages that do work flawlessly in every browser; there certainly are. But the validator is an automated tool that can highlight small but important errors that are difficult to track down by hand. If you create valid markup most of the time, you can take advantage of this automation to catch your occasional mistakes. But if your markup is nowhere near valid, you’ll be flying blind when something goes wrong. The validator will spit out dozens or even hundreds of errors on your page, and finding the one that is actually causing your problem will be like finding a needle in a haystack. [*] Validation may solve your problem. HTML is not anything goes; it has rules of how elements can be used and combined. Browsers are written to understand these rules and render your page accordingly. Browsers also have special-case logic to deal with various types of invalid markup, including vendor-specific tags and attributes, illegal combinations of block-level and inline elements, and overlapping elements. Different browsers create different internal representations of this so-called Tag Soup markup, which can lead to unexpectedly varying results when they go to apply styles or execute script on your page. I am not claiming that validation is a magic bullet that will automatically solve all your web design problems; it is not. Designers still cope with lots of cross-browser and cross-platform compatibility problems with valid markup. But validating your pages eliminates a vast array of potential incompatibilities, leaving a manageable subset of actual incompatibilities to work with. Which leads me to my next point… [*] Valid markup is hard enough to debug already. Debugging Tag Soup is an order of magnitude harder. It’s also not terribly rewarding. Some of us are good at it; many of us have been around long enough to have dealt with it at one point or another. But it’s not where we like to focus our energies. There’s nothing aesthetically pleasing or intellectually satisfying about helping a hack-and-slash coder tweak their shitty markup and bludgeon a few browsers into submission. We know it’ll only break again next week; we’ve been there, we know what happens next week. We know you’re just coding on borrowed time. And did I mention that debugging this stuff is hard? There’s a lot to keep track of, even when you do everything right. There are bugs in Windows browsers, bugs in Mac browsers, bugs in browsers old and new, bugs in Opera, bugs in Netscape and most of all bugs in IE. Dr. Seuss could make great poetry out of all the bugs we cope with in our valid, standards-compliant pages. And on top of that, you want us to keep track of the near-infinite variety of bugs that could be triggered by your Tag Soup? We don’t have that kind of time, and the time we do have is better spent elsewhere. Which leads me to my final point… [*] Validation is an indicator of cluefulness. There are a lot of people who need our help, and there are relatively few of us who have the combination of time, expertise, and inclination to debug the work of strangers for free. Like a Human Resources department that gets 500 resumes for every open position, we have to filter on something, and validation has proven to be a good filter. Why is validation a good filter? Because nobody makes valid pages by accident. If you come to us and say, Hey, I have this page, it’s valid (X)HTML and CSS, and I’m having this specific problem, well OK, you’ve obviously put some work into it, you’ve met us more than halfway, let’s see what we can do. But if you come to us and say, Hey, I slapped together this page and it works in X browser but now my client says it doesn’t work in W, Y, and Z, they must be buggy pieces of shit, well… you catch more flies with honey, and you get more help with valid markup. Okay. IF you actually read all of that, and paid attention, validate your page now (you know where the link is because you read the above, right?) and fix all of your html errors before asking for help here. Here is a link to the original "rant" from which I paraphrased the above: http://diveintomark.org/archives/2003/05/05/why_we_wont_help_you Ian Hickson illustrates these differences in how browsers react to tag soup Tag Soup: How UAs handle <x> <y> </x> </y>. Dave Hyatt, one of the developers of Apple’s Safari browser, talks about the residual style problem caused by improperly nested elements. As Dave’s example shows, this doesn’t just affect CSS-based pages; it affects pure-HTML pages too. Dave (dbrimlow) Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.