Forum Moderators: open

Message Too Old, No Replies

Troubleshooting HTML and CSS Rendering Problems

         

ergophobe

4:17 pm on Aug 28, 2014 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



This is a long-belated followup to my thread on Troubleshooting 101 for PHP - [webmasterworld.com...]

Sometimes you scratch your head and you cannot for the life of you figure out why your HTML is "broken" which can take many forms: things show or don't show, they are the wrong size, float behave differently than you expect and so forth.

In all of these cases, the method is always the same and it is the same as troubleshooting with PHP: boil your problem down to the simplest case where the problem still appears. Then fix it and apply the fix to your real-world case.

Simplify your code

The first rule is to not attempt to debug an entire page. Instead, save a copy of the page and start cutting out anything extraneous.

First cut out all content that is irrelevant to the problem and then reload. Oops! Did that fix the problem? Well, I guess that code is not irrelevant and you have some problem further upstream that you're not seeing.

Then cut out all irrelevant Javascript and CSS. Then irrelevant markup.

Tips for dynamic pages

If the page is being generated dynamically by a CMS or a e-comm suite or something, the best thing to do is open the page in your browser and use the Save As option. I find that different browsers save different amounts and I have often found that Chrome and Firefox do not save absolutely everything locally. Opera does a better job. So though I do my actual debugging and testing in Firefox and Chrome, I use Opera to save dynamic pages.

Use your tools

The reason I use Firefox for debugging, is because I find Firebug and the Inspect Element tool in Firefox to be superior to Opera's Dragonfly. If you don't understand how to use Firebug and Inspect Element, learn how to use them and the strengths and weaknesses of each.

If you have to debug a problem that only shows up on another browser or on mobile, all browsers now have decent tools and you can pair a mobile device with a computer and use the dev tools on your computer while browsing on the phone if you have to.

Asking for help

You've got your code. You've got your tools. Now you just need a bit of persistence. If the code doesn't work in the simplest possible case, then your code is simply wrong.

If you are working on your navigation, you should work on just that. Then slowly wrap it in more and more code until you see how it works with the page.

If you have the simplest possible case that illustrates the problem with the least amount of extraneous information, that would be the code you would then present here when asking for help. This will result in faster and higher-quality answers.

mw11

7:21 pm on Oct 19, 2014 (gmt 0)



Pretty good advice because, generally speaking, debugging can be (and usually is) time-consuming, perplexing as well as frustrating.

buckworks

6:08 am on Oct 20, 2014 (gmt 0)

WebmasterWorld Administrator 10+ Year Member Top Contributors Of The Month



The first rule is to not attempt to debug an entire page.


I'd agree with that except for validation checks, which would normally look at the whole page.

Many validation errors can be safely ignored but sometimes a single error can cause serious weirdness. Conversely, sometimes fixing one error can resolve a whole chain of problems. It only takes a few seconds to run a validation check, so make it one of the earliest steps in your trouble-shooting. Don't feel obliged to fix every last thing the validator does't like, but do look for errors that might be significant.

Note that code can be valid but still not do what you want because of conflicts, things missing, etc. But ruling out validation errors as the cause of of problems will make the rest of your trouble-shooting easier.

I like W3's Unicorn validator [validator.w3.org...] .

lucy24

7:27 am on Oct 20, 2014 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



More is less. Twelve reported errors means you've made twelve mistakes. 1200 reported errors means you made one mistake, and once you fix it, all the others will magically disappear.

ergophobe

11:00 pm on Oct 22, 2014 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



Hi bucky... I don't think of validation checks as "debugging" - it's more of a QA process.

Fixing a validation error might involve debugging, but typically you know what line the error is on and you fix it and your debugging is done.

But when you're dealing with strange layout issues, it helps to boil things down to the simplest case and then build back up to your target use case.

buckworks

12:16 am on Oct 23, 2014 (gmt 0)

WebmasterWorld Administrator 10+ Year Member Top Contributors Of The Month



it helps to boil things down to the simplest case


Yes.

After you've run a validation check. ;)