As most people know, both WordPress and Drupal belong to the class of software known as content management systems (CMS). The benefit of these systems is that they allow users to create content easily, often by typing in content via a dashboard or some other simple form of entry. The actual HTML generation is taken care of by the CMS, allowing the user to focus on creating content without worrying about the details of the HTML.
I’ve had my personal blog for nearly ten years now, and have been on WordPress for nearly three. As I write content, there’s always the implicit expectation that my content will come with me wherever I go in the future, no matter which CMS platform I end up choosing. With that in mind, it’s important for that content to translate properly as technology and our use of that technology changes (for example, screen resolutions increase, or the world shifts slowly towards mobile blogging).
When an image is inserted in a post, many people still hardcore the width and height parameters of the image. The problem with that approach is that it generally ties the content to a particular presentation, and makes it difficult to transition in the future. For example, let’s say you manually specify a width of 400px for an image. If one day you decide to change your theme post area to display 500px worth of content, suddenly all your images are too small. To fix the problem, you most likely have to go through and manually edit every IMG HTML tags to change the width. On a blog with 1000 entries, that doesn’t sound particularly exciting, does it?
A far better approach is to use CSS to specify the desired width and height. Most modern browsers support the “max-width” parameter, and those that don’t typically have workarounds. With that approach, you can simply change the layout via CSS whenever you want to overhaul the look and feel of all your images.
For some people, that probably sounds really straightforward. And yet, many third party plugins (and in fact, some popular CMS systems), add hardcoded width and height parameters to content. Every use video from YouTube or other services? If so, you’ll also probably notice that the EMBED code contains specific width and height parameters, which for most people don’t work well with their blog’s theme. What happens when you view a 500px video on a 320px screen? You could be in trouble if the width is hardcoded. In addition, if you’re a web designer who tries to make your sites validate against W3C, you should know that embedded width/height attributes most likely will not validate against strict XHTML doctypes.
We fixed some of these problems with Blip.it, and made the plugin automatically generate it’s own width and height. We’ve also been testing out a new BraveNewCode video plugin on my personal blog that addresses this problem in a more generic way. Using WordPress 2.5 and above, you can simply use a shortcode to access any video on the web, and have it automatically size to the proper dimensions on your blog. Should you adjust your theme presentation sometime in the future, you can simply adjust the width and height for all videos in the dashboard, and have all your previous content automatically change as well. In addition, the code generated by the plugin validates against W3C in all cases, unlike the EMBED tag (that YouTube and others still provide) which was deprecated.
Anytime you generate content that has an explicit width or height tied to it, you really need to stop and think if there’s an alternative. You may very well be affecting the future look and feel of your website by doing so.