Images are sort of a special beast in the HTML animal kingdom. They’re technically inline elements, but they don’t really behave like them. For example, inline elements can’t have widths and heights applied. And yet, you and I both know that images have widths and heights.
This can cause trouble in responsive web designs. While inline elements automatically play nicely in RWD, resizing to fill their container, images do not. They’ll bust right out of that shiz and wreak all sorts of havoc, turning your nice narrow sidebar into something like this:
See the Pen Sizing Images Responsively 1 by Rob Glazebrook (@rglazebrook) on CodePen.
That is likely not what you intended. Happily, the fix is simple, safe, and effective. Read On…
When I figured out the workaround for line-heights in form buttons last week, I also discovered an interesting discrepancy (feature?) across all major browsers in terms of buttons and the box model. Check out this article for a more in-depth refresher on the CSS Box Model, but here’s a brief summary:
Let’s say I have a div styled like so:
padding: 10px 0;
The box model states that the resulting box will take up 30px of vertical space for the div’s contents, plus an additional 10px on the top and bottom for the padding, for a total of 50px vertical space taken up by our div. Read On…
I recently ran into a bug in Firefox and Opera when I tried to set the line height of text inside a button (which affects input “submit” buttons as well as the HTML button tag). The bug? The line height can’t be changed!
For example, take the following code:
border: 2px solid #06f;
font: bold 12px Arial, Helvetica, sans-serif;
In a perfect world, this code would be a quick and easy way to vertically center text inside a button and set the button’s height, since text is always centered inside of the space created by its line-height.
But the results are inconsistent. Chrome, Safari, and (I can’t believe this either) Internet Explorer 8 all center the text and resize the button just like I’d expect. But the results are less than perfect in Firefox and Opera (see the image above). Read On…
I ran into (yet another) Feed Count + Feedburner problem recently, shortly after writing my last article on accounting for Feedburner’s subscriber count mistakes. And since I heard from a few people who are also using the Feed Count plugin, I thought I should share this info.
As I’m sure all you Feedburner users out there are well aware, Google purchased Feedburner quite some time ago. But until recently, that didn’t mean much: the same people were working on the code, your information was stored in the same place and was represented the same way, and so on.
But recently Google has begun bringing Feedburner more fully into the fold. As a result, all Feedburner users are being required to convert their Feedburner accounts into Google accounts. That created quite a few headaches for lots of people (including myself) right off the bat, as it took a good week for Google to nail down my subscriber numbers with any accuracy – one day I would have thousands of subscribers, the next I might have zero, and the day following only a few hundred. Read On…
A while back when I was working on developing the jQuery popout tutorials, I ran across a significant and annoying bug in Internet Explorer 6 and 7. Specifically, Internet Explorer does not respect the height and width properties of block-level, absolutely positioned anchor tags if they contain no content (or if that content has been moved or removed).
Instead of your anchors being the size you’ve specified, the size of the clickable area is limited to the size of the content inside the anchor. And therefore, if your anchor is “empty” (either because it’s an empty anchor tag, or you’ve used “display: none” or a negative margin to hide the content), your anchor tag’s clickable area is zero!
Let me explain a bit of what I mean. Let’s say I have a website with a very stylized banner at the top of the page, and I’ve decided to load the banner as a background image. However, in order to play nice with search engines and keep my SEO high, I’m still going to use an <h1> tag for my banner text, and then just hide its content. I also want a portion of my banner to be clickable, so I can let users get back to my homepage that way. Read On…