Designing For Code: Copy & Paste

As a developer, I’m constantly on the web. Learning, reading, finding solutions to problems or looking up odd bugs. There is a great community of developers that are constantly publishing solutions / fixes / workarounds / techniques for the benefit of their fellow developers. Being developers, you would expect to find that the sites they run are easy to use across the board! For the most part they are but every now and again though I run across a site that makes me want to bash my head against the monitor. Why? Because it breaks the simplest feature:

Copy. Paste.

If you EVER post code on the web on a site you control, or if you are in charge of a site where you or others post code. Make. Sure. Copy. Paste. Works. Period. I’m not just talking about ‘I can select it and paste it’ functionality, I’m referring to those ‘code highlighting’ plug ins that add line numbers to EVERY SINGLE LINE of a code snippet when you paste.

Don’t Do It.

There are lots of good highlighting plug ins out there, sites that will format your code for you, and so on. Whatever method you chose, test it and make sure you can use the code from your site without having to modify or do anything to it. If you can’t, abandon it. Find something else. Use raw text. Whatever it takes to get the basics working well.

In addition, make sure your code works well when the site is scaled up or down. If you have a site that doesn’t change width as the browser size changes, ignore this, and read this post on fluid layouts: http://blogs.interknowlogy.com/2011/10/25/on-modern-layo…mi-fluid-grids/. Now IF your site changes width, your code should ALWAYS work on whatever size the visitor is looking at the site on. Check it on a smart phone. Check it on a tablet. Stretch your site across two wide screen monitors. If it ‘breaks’ (as in becomes unreadable or inaccessible) fix it. Go back to the basics. Remove / alter / don’t use a plugin. Again, do whatever it takes to make the basics work.

Don’t underestimate the importance of the small supposedly insignificant details. In all honesty, users aren’t going to come to your site and praise you for what an elegant job you did on making your code easy to copy and paste, or how nice the content looks, or how readable the article is. Its similar to the way people will notice spelling and grammar. If your sentences are well formed and correct and the article is well structured the person reading should never have to mentally think about it. On the other hand, if an article is not well crafted, that person will have to wade through the mistakes and mentally jump between what was actually written and what the author intended. In same way, whatever type of content you present to a visitor, it should always be presented it in such a way that the person consuming it can do so without ANYTHING getting in the way of them doing so effectively.

Think about it. Go check your site. Make the net a better place.

Invisible extra line height

I came across this annoying off by one pixel layout issue several days ago when dealing with <code> tags. You may not even guess that its caused by it at first, but if you ever try to test your layout with a baseline script, you may notice this.

Take a good look at the following screenshot and tell me, are these two paragraphs the same height?

The correct answer is No. They’re not. If you look at the line height, the font size, almost everything you’ll find that these two paragraphs are exactly the same with the exception of the <code> tags in the second paragraph. Digging in deeper you’ll see the following problems with the paragraph height:


Four. Pixels. Taller. *explicitive*. Most people wouldn’t care, or even notice unless you were using a baselineing tool like Typesetter. The solution, after much digging around, is to set the line height of <code> tags to zero.

code {
     line-height: 0;
}

And like magic, all of a sudden your paragraphs now behave correctly. This may be classified as a bug, at the very least, its an annoyance, but if you find yourself having problems with your paragraph line heights not behaving quite right, take a look and give this a shot.

Back to HTML – Tricky margins

HTML layout is weird. Half the time it makes sense, and the other half it makes half as much sense as it should. To that end, here’s a quick refresher on margins and padding and layout that I’m writing as much for myself as for you.
Lets start with a box. In this imaginary real box wold, you are either putting blocks next to each other, or inside other boxes, to get elements to line up and appear in some fashion or another. These virtual boxes have two properties, margin and padding. In our box world analogy, the padding would represent the thickness of the walls of the box. If you add something thats bigger than the inside of the box, the actual outside edge of the box will have too expand to contain whatever is inside. When you set a margin however, its simply stating a rule that you would like this box to be at least x number of units away from any other sibling box.

For instance, I have Box A and I want anything around Box A to be at least 2 feet away on the top or bottom of the box. Now, I have Box B that also has margin, but for Box B I only need everything to be 1 foot away along the top or bottom of the box. If I placed these two boxes next to each other (as siblings), the boxes would be 2 feet apart. Box A overrules Box B since A requests any other box to be further away from B, and thus B is also satisfied since the margin for B is less than A. If I also specified padding for box B of 6 inches, the contents of B would be at least 2 feet 6 inches from A since margin is measured from the outside edge of the box.

Here is a real example. In this case, I have 2 paragraphs. The orange space represents margins, and the green represents padding as shown by the debugging tools in chrome.

The code looks something like this:

<article>
     <p>This is some paragraph text 1</p>
     <p>more paragraph text</p>
</article>

Example 1 Margining:


Notice how the margins collapse when they touch each other. Remember that margin represents ‘minimum spacing’.

Example 2 Padding:


Notice how not only are the paragraphs further apart with similar spacing, but they padding doesn’t overlap at all. This distinction is important when you lay out content, and especially when you start floating things. Eventually the imaginary real box model starts to break down as we approach real world HTML. Another really important tidbit to understand is that margining can extend OUTSIDE of the container. For instance, in the previous code snippet, we only have one article and two

tags. If we put two articles side by side, we can see how the paragraph margining will extend out of the article block:

HTML:

<article>
     <p>This is some paragraph text 1</p>
     <p>more paragraph text</p>
</article>
<article>
     <p>This is some paragraph text 1</p>
     <p>more paragraph text</p>
</article>

Note how the article is only the size of the paragraphs inner dimensions:

However, when we look at the paragraph margining, we see:

The paragraph spacing extends beyond the bounds of the article and pushes the paragraphs and the article down. I know. The box model doesn’t work any more. Remember the differences and play around with it yourself.

Some Practical Advice

  • When you first start laying elements out on a page, only specify bottom margining and keep the space consistent. It will help debug initial issues since there will be less overlapping margins.
  • Use a sylesheet language like less or sass so you can keep the numbers more consistent and easier to change.
  • Use good debugging tools. Chrome Developer tools, or Firebug are both good. They’ll keep you from going insane immediately.
  • If all else fails, simplify the problem. Make a small, quick html page to try to replicate your scenario.
  • Tinker. You only learn something by doing it. Do it.