Andy Budd - The Wonderful World of Bugs ======================================= Going to be talking today about bugs. How many people in the audience feel they use too many hacks? (Lots) How many people feel they use too few? Hacks mean an elegant and temporary solution. Know it's nasty, done it quickly, know there's a better way to do it, know you'll fix it in the end. Not the same as CSS hacks. Problems CSS hacks are fixing are usually bugs in the code. People think that hacks are a bad thing, just because of the connotations. The term patch is perhaps a better term to use. We're patching buggy browsers - "patch" puts the problem back at the browser. Another term is "filter" which also doesn't have negative connotations. Hacks have a bad rep - but web developers have a short memory, and see things in black and white. Something like Tantek's box model hack opened up the ability to build standards based web designs. We wouldn't be where we are without hacks. Hacks have become synonymous with CSS - people started asking for a hack instead of asking for general help, very hack focussed. It got to the stage where people measured their css knowledge based not on the specs but on the number of hacks they know. Ultimate accolade was creating a new hack. People going out of their way to find obscure bugs in obscure browsers. It doesn't have to be this way - keep our hacks a minimum and we keep the number of bugs to a minimum. Bug Fixing ---------- Browsers are buggy - some browsers don't support the whole spec, implement it differently. Tend to be the main sticking point. Often focus on internet explorer - gets focus because it has the biggest market share. Other browsers are very buggy but people don't worry about them so much. Shouldn't give IE such a bad time. Browsers are not as buggy as we might think - bugs come from: - syntactic errors - specificity clashes - sometimes a style doesn't take because you've defined it somewhere else more specific) - overly complicated code - sometimes people showing of - browser bugs - incomplete understanding of the CSS specification - most of us are self taught, learned by doing, easy to have a 95% correct mental model of how it works. For example, floating and clearing have weird quirks, like how margins are added. People often assume a bug is a browser bug. Andy's first rule of bugfixing - KEEP IT SIMPLE (stupid) -------------------------------------------------------- Visit lots of forums - people moaning about number of hacks in their code. I think "I don't" - maybe one or two hacks. People overcomplicate code, allow more possibility for something to go wrong. Once I was doing form layout - looked at it in netscape and it didn't work, so added code, that broke another browser, more code, and so on. After a day, went back to a simple form, label floated left and form element floated right. It just worked. Should also endeavor to keep our designs simple, know we want to show off, but we're working in the limitations of the browser and spec. Best way to do this is to have a designer who understand code, the limitations and possibilities. Skill of an artist or good designer is to know the limitations and your tools. Andy's second law of bugfixing - ALWAYS ASSUME IT'S YOUR FAULT -------------------------------------------------------------- Find a problem, check what you've done, check the spec, check in other browsers. By assuming you're wrong you avoid hacking at things that don't need to be hacked. Only you're 100% certain the error hasn't been introduced yourself should you look at hacks. Andy's third law of bugfixing - PREVENTION IS BETTER THAN CURE ------------------------------------------------------------ If you find you have a situation where a layout is buggy, instead of spending a day fixing the bug, try a different method. Classic problem is a box model problem - IE uses a different box model, there are loads of fancy box model hacks, 95% of the time you don't need to use a hack - only happens if you have a width and padding on an element. Just don't specify width and padding on the same element. Avoid the pattern and you don't need the hack. Andy's forth law of bugfixing - OFFENCE IS THE BEST FORM OF DEFENSE ----------------------------------------------------------------- Know the common bugs and the fixes. Really easy to fix - just add display:inline; to the floated element - whenever i add a margin to a floated element I add the fix, never a problem. Then you don't have to go back and find the problem later when you finally test it in IE. Another problem is the layout property of IE - a lot of the fixes are about adding layout to IE - give it a position, or a height. Rather than waiting for the bug to appear, fix it before it happens. Know your enemy. Andy's fifth law of bugfixing - ISOLATE THE PROBLEM ------------------------------------------------- If you have a complex page it can be hard to track down the problem. Create a minimal test case. Delete the HTML above the bug, test again, delete some more html, until left with the bare minimum, comment out typography css, color css, end up with 5-6 lines of html, some lines of css. that's where the bug is. Often the process of deleting code bubbles the bug up. Bug in IE with comments in HTML - more comments mean more duplicate characters. Andy's last law of bugfixing - USE HACKS ONLY AS A LAST RESORT -------------------------------------------------------------- Only once you run out of options should you use a hack. Using hacks sensibly -------------------- Several types of hack - hacks that rely on parsing bugs - unsupported or misinterpreted CSS these aren't hacks - just proper CSS, don't worry about using an attribute selector to send a transparent png to modern browsers. CSS was designed so if a browser doesn't understand a particular selector, it's ignored. Good hacks - are valid to CSS 2.1 - there are differences between 2 and 2.1 - only target older browsers - hacks that target IE are mad and wrong - are ugly? - tantek suggests this - when you're scanning through stylesheets, if you see something ugly it stands out. Either way, should comment hacks, and comment them well. Use hacks sparingly. Only add a small number of hacks to your main CSS. Better to filter them into separate stylesheets. IE team recommend conditional comments. I don't like this method, adding more bloat to your code, better to use Tantek's high pass filters. When you stop supporting IE5/Mac you can delete it, and when you get a problem can go straight to the hacks in your code. Always comment hacks - come back in 6 months and you won't remember why you did it. Or if you hand over to other developers - working on others CSS files can be very difficult. Could strip them out for live stylesheets. Questions --------- q: A point rather than a question - browser forgiveness - one issue that sometimes happens is that some browsers will forgive your error, may leave an end tag out and it works in some browsers. a: This is a feature of the web - really good thing for beginners, but has become a problem, send it as XHTML with xml mime type and you won't get a page. Can be over fussy. (rule 7 - don't bugfix on a friday evening) q: (something about source order) a: Floats were never meant for layout - dirty secret that almost all css layouts are hacks. Would be good if we could do positioning with self clearing elements etc. Shaun Inman is doing some interesting stuff here with javascript, maybe worth using on a personal site. There is always dependency - maybe 80-90% independent. You have to mark up your code with some sensitivity to the design. Source order will probably always be important.