This week's Web Wednesday was kindly brought to you by your friendly neighborhood paragraph tag. Often overlooked and under appreciated, the <p> is your most commonly used element for managing white space around content.
We did have some discussion regarding closing </p> tags, but all you need to know is that you should use them.
Tips on Troubleshooting Just About Anything
Sandy was working on implementing a simple jQuery plugin, and the problem ended up being not with the plugin implementation, but with the HTML itself. Here's a quick tip:
The best troubleshooting methods involve breaking a larger, more complex problem into smaller, testable chunks. Better yet, do your implementation in smaller, testable chunks.
Suppose you want to implement a lightbox plugin. You have a smaller image linked to a larger image that should appear in a modal popup. You can mostly get this working with no JS at all; the difference is that clicking on the linked thumbnail will simply link to the image itself. Now you have your content in place, you can add a bit more pizazz to it by making it load into the lightbox with JS.
We touched a bit on what it takes to print a page that's styled, well, for printing. The best way to do this is utilize printer-specific CSS. You might have a base stylesheet that covers most of your needs, then override or add a few styles when printing.
Here's how you might do this:
- Code: Select all
<link rel="stylesheet" type="text/css" media="all" href="style.css">
<link rel="stylesheet" type="text/css" media="print" href="print.css">
The media="all" setting is default, but note that many browsers won't print background graphics by default anyway (usually you have an option to turn this on or off in the print dialog). So one thing to do is try printing the page and see what it looks like before you try to "fix" it for printing.
Now, if you think some browsers render pages differently, just you wait until you actually try printing them. It's even worse. Make sure to test your printing in all of the browsers you expect will be used to print. The best case is when this is an internal company project and you have control over which browser is in use. Unfortunately, this is not always the case and you'll have to spend some significant time testing. If you have the ability to print to PDF, that's a good way to make sure your print CSS is working without laying waste to whole swathes of forest.
Note that if you are printing images, web-quality graphics often look horrible printed. Printers have much higher resolution than (most) computer screens, running at something like 300 dpi. Traditional monitors have the equivalent of something like 72 dpi. So pictures that look just fine on the monitor will be pretty chunky on paper. This also is a problem on higher resolution screens like Apple's "retina" displays. But that's a topic for a future post. If you are interested in how to use MagicEdit to serve up high resolution images for print, let me know and I'll post up a HowTo.
That's All She Wrote
We touched on a few other things, some of which I'm intentionally ignoring. Things like migrating sites from one backend to another. Never a good time.
Until next time, happy coding. And don't forget: your text is happiest when wrapped in comfy tags designed just for the purpose. Say no to multiple s and <br>s and say yes to lovely, semantic markup, starting with your classic <p> tag.