Photographer, Developer, Designer

I’m a programmer. I’ll admit it. I’m a professional nerd who, for some reason, thinks the web is awesome. I’ll be honest. I hate how difficult layout is in HTML sometimes. Seriously. How many times have YOU tried to get your margins to play nice with floated, bordered elements, and had to change the border width by 3 pixels in a floated column layout? You probably just about shot yourself. Why? Because the default box model when laying things out since forever and a half ago (e.g. 3 internet years) is box-sizing: content-box;.

What does it mean? content-boxmeans that the box layout is measured from the outer edge of the content. So if I set width: 50px the box that represents that html element is going to be 50px wide. What sucks, and is really weird about this at times, is when we add a margin to our box like this margin: 5px. All of a sudden the ‘actual size’ of the box now increased by 10px! (5px on each side). In addition, margins aren’t “distance away from the edge of another box” like you’d expect, it’s “distance away from the edge of another content box”. That’s why when you have paragraphs next to each other and one has 5px margin and the next one has 10px margin, the paragraphs are 10px apart, not 15px like you might expect.

Uh. Ok. What does that do? THAT will change every element to measure everything from the outside of your box. So now, when you have two paragraphs, and you give one 5px margin and the other 10px margin, they are going to be 15px apart. If your a developer / programmer who works with programmatic layouts on a day to day basis and gets frustrated by HTML and CSS, try this out. It’ll probably save you LOADS of headaches.

I’ve got a bone to pick, and maybe it’s not even worth picking but here it is: Most of the responsive grids on the web today suck. Responsive grids are hard to do right. A responsive site has to be well planned out, is difficult to implement, and are usually prone to an overabundance of excess styling to get it to work right and a lack of re-usability. That’s where a framework comes in, and although most of them help a little in some form or another, they don’t meet the overly high expectations I have for them. Of the better ones I’ve seen over the last several months, the best one I’ve looked at so far is the one in the twitter bootstrap framework:

As much as these frameworks are getting closer to what I want, most of them still suffer from one big problem: They only have two modes. If you look closely as you size down your browser on the bootstrap site, the sites snaps, then snaps again, and finally the content re-arranges down to a single column. What I really dislike about this, is that there are no intermediate steps between desktop and mobile. Yes, the size is different, and it helps a LOT, but the layout doesn’t change.

One of the more obvious, and disturbingly annoying, examples of this two mode thinking is Zurb Foundation, because not only do they lack the intermediary step sizing, but the way it’s done causes some pieces of content to MASSIVLY increase in size in mobile layout. You’ll probably notice it most when it causes images to get resized into pixelated, oversampled, Web 1.0 stock image nastiness that makes graphic designers cry. Seriously. In mobile layout, your content should never be larger than it is in a wide, full width desktop environment:

*sob*

So. Do I have a solution? Not completely. But I do have a demo of something cool I’ve been working on as I’ve been refining my ideas on how a responsive grid I would want to work with would behave. Take a look at it here:

It includes nesting grids and has a fully fluid layout. I’m still working on how I can make the grid more robust and get it to work in situations where the container itself is centered or fixed. I also want to include and make more complicated layout re-arrangement behaviors (like inlining a sidebar below your main content, or expanding a menu, and so on like you might have seen with the theme on my site) easier to do.

(Obligatory Screenshot)

Finally, I can’t rightly write a post like this without pointing out some great sources of inspiration: First, the Golden Grid System by Joni Korpi, which is a great example of a responsive site, even though I always feel like it’s overdone on a big monitor. Another really good article that I feel really marked the start of people thinking about a responsive web is an article on A List Apart on responsive web design by Ethan Marcotte. Finally, this post by Paul Irish on why you should only build and serve one layout of your site, and why you should be designing towards the modern web.

Cascading Style Sheets (CSS) is a style sheet language used to describe the presentation semantics (the look and formatting) of a document written in a markup language.

Furthermore:

CSS specifies a priority scheme to determine which style rules apply if more than one rule matches against a particular element. In this so-called cascade, priorities or weights are calculated and assigned to rules, so that the results are predictable.

From my informal office survey, the general consensus is that the most important thing™ in CSS is that everything ‘cascades’ correctly. That is, that rules and styles defined further down in a CSS document override styles specified further up in the document (excluding the !important operator of course, which you should not be using anyways). It makes sense if you think about it, after all it’s not called a Cascading Style Sheet for nothing.

Now, the test. Given the following HTML and CSS snippet, what color will the two paragraphs be?

HTML

<p id="myid" class="myclass">
Hello World.
</p>
<p class="myclass">
This is another line of text
</p>

After a decent amount of Googling and reading blogs and the W3C Spec on CSS Selectors, I realize now how styles are calculated and applied, but seems to go completely against the ‘cascading’ nature of style sheets since the cascading nature of style sheets only applies when the ‘specificity’ values are the same.

As you might expect the paragraph will be green, and have a font size of 20px. The rule that is more specific selectors takes precedence over rules that are less specific regardless of where that rule is declared in the markup. You can mentally calculate how specific a rule by the ‘level’ and number of the selectors used. From low to high, you have

Element and pseudo elements such as p, a, span, div, :first-line

Class, attributes, pseudo-classes .myclass

Id attributes #myelement#theonething

From inline style attributes

!important

If there’s anything of a higher level, the higher level overrides the lower level style, and if they’re the same level, the higher count wins, and if they’re at the same level with the same count (.myclass, and .myotherclass) then the one further down takes precedence, this is the “only” time cascading actually happens.

Its something that is unfortunately very subtle because of the way we write CSS, your taught from the begin to start with the most basic generic styles and work your way through the more specific styles. While this is correct, it’s very easy to go for a long time without running into a situation where a more specific styles.

I had no idea up until about a week ago that CSS worked like this. I always assumed that specificity was only used to select the subset of elements the rule applied to, and that if you applied a more general rule after a more specific rule that the more general rule would overwrite anything earlier. This is obviously not the case. If you want to read more, here’s some links to a few more comprehensive articles on the subject:

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://www.paulrohde.com/on-modern-layouts-and-semi-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.

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.