Labels. They're Not Just for Forms Anymore.

Posted on Tuesday, July 28th, 2009 at 2:20pm by Rob Wilkerson

Think semantically, not dogmatically. Labels can be used to describe data as well as form fields. I can’t tell you how often I’ve seen something like this:

<div id="image-info">
   <span class="label">Name:</span><span>myimage.jpg</span>
   <span class="label">Size:</span><span>5KB</span>
   <span class="label">MIME Type:</span><span>image/jpg</span>
</div>

The obvious red flag here is that the name of the class is also the name of a tag, but a lot of examples aren’t quite so obvious. Nonetheless, when labeling data, use the label tag to do it. I’ve never seen any indication that it’s incorrect in any way.

x/html, standards 0 Comments

Web Standards Losing Their Appeal

Posted on Wednesday, September 24th, 2008 at 12:15pm by Rob Wilkerson

Okay, so maybe the title was a little dramatic, but it’s not entirely inaccurate. I’ve had a draft of this post sitting in my queue for a long time now, but, while catching up on some feed reading, I ran into Molly Holzschlag’s similarly themed post on A List Apart and it prompted me to finish my own.

I’m a believer in standards. In my own code, within my team, in the greater office environment and on the web as a whole. I like being able to open another developer’s code and not feel like I’m lost for the first few minutes or hours. Standards facilitate that. So when the first real standards began gaining traction, I was all over it. Over the last year, though, my enthusiasm for what’s out there has faded.

I’m not talking about my enthusiasm for standards in general. I’m still a fan, in theory. I’m talking about my enthusiasm for the current markup standards. I’m not as close the inner-workings as Molly is. In fact, I’m not close to them at all. I’m a complete outside. From where I sit:

• Movement is so slow that it feels like it could be measured on a geologic timeline.
• The message is too fragmented.
• Probably owing to the first two, adoption is stagnating and interest in adoption is waning.

I read not too long ago that one of the web standards wasn’t expected to become a fully-realized, official spec until something like 2021. Don’t quote me on that because I can’t find the original article, but even if it was 2012…seriously? By that time we’ll all have flying cars, a tinfoil wardrobe and capsule meals. In the context of technology, that’s about 47 and a half lifetimes. A standard that takes that long to realize will be standardizing something no one’s used in 10 years. Talk about being marginalized.

More and more, it feels like picking a standard is a little like playing roulette. Red or black? Odd or even? XHTML or HTML5? Sure, at the end of the day the key is to pick one, but if everyone’s picking a different standard or even a different variation of the same standard is it really a standard. Technically, maybe. Practically, I’m not so sure.

Browser adoption and adherence seems lackluster at best. No matter what standard I say I’m using, what standard I apply, if any, or how consistently I apply that standard, most browsers seem to render my code pretty well. If it doesn’t matter to the end result then the degree to which it matters to the process is minimized.

Right now, at the moment of this writing, I guess I’d still consider myself pro-standards, but not anally so. I use XHTML Strict, having chosen it because of its structured XML backbone, but these days I find that I have no burning desire to escape the use of an ampersand in my links just to see that lovely green bar appear on the W3C’s validation results. I’m going to use and stick with my chosen standard, but primarily (if not exclusively) for the purpose of keeping my code clean and structured. I don’t suspect that I’ll spend much time sweating the details until the details have more practical meaning.

standards 0 Comments

Development Tip: Avoid Ambiguity

Posted on Friday, March 28th, 2008 at 3:20am by Rob Wilkerson

Yesterday morning I was reviewing a database design and found myself looking at a field named status. I didn’t think much of it when I was looking at the structure because, well, it’s a status field. The field existed in a table named contract and it’s perfectly logical that contracts would have statuses, right? That’s innocuous enough. As the old saying goes, “Nothing to see here. Move along.”

I few minutes later, though, I changed my mind. After reviewing the structure of the table (when I say “the structure” I mean the output of an EXPLAIN statement), I took a look at the data and noticed that the status field contained boolean data. Now it wasn’t so innocuous to me.

In its most rudimentary form, I tend to think of most applications as a series of whats and hows. The client tells me what they want to do and my job is to figure out how to make it happen. In this case, I don’t know the ins and outs of this particular application. Sure, I understand the high level functionality and the business problems it intends to solve, but I’m not familiar with all of the hows the application employs to solve the whats.

Looking at the data, that innocuous status field became ambiguous at best and meaningless at worst. What does status = (true|false) mean? Does status mean active in this context? Deleted? Approved? I had no idea.

When building an application, it’s important for developers to be clear. Entities – variables, methods, tables, fields, etc. – should be named in such a way that someone reading the code does not need a full understanding of the application’s context or functionality in order to understand what that entity is, does or means. Code is written for the application, but should not be written solely for the application. It should be written for the application and for the developer that needs to pick it up two years from now and for the developer who works on another project, but needs to jump in to make a quick fix. Those developers should not have to wade through business logic to understand what an entity does or how it’s used.

productivity, development philosophy, code, standards 0 Comments

Why Web Standards?

Posted on Wednesday, March 5th, 2008 at 9:02pm by Rob Wilkerson

I went to the inaugural meeting of the Refresh Baltimore group last night and, in the early minutes of the meeting, a short discussion broke out around the adoption web standards. I have to admit that I was a little surprised to hear more than one person express at least some level of apathy with respect to implementing standards in their own work. The primary reasons for this apathy seem to have something to do with the avoidance of blind adherence to arbitrary standards, a perceived limitation on design and/or the level of difficulty.

The first is a specious argument at best and can be dismissed as such. I’m not espousing blind adherence to anything. Additionally, I don’t believe that web standards are arbitrary in any way. The standards being discussed have been identified, considered, collaborated on and documented by other web professionals. These are (for the most part) very smart people who have put a lot of thought into such things and have provided a logical foundation on which the standards are built. If they were anything less, the adoption rate as it stands today would be far lower. We, as a community, are not lemmings. One statement I heard was that, “we should be creating the standards.” I would argue that we did. The collective we of web professionals, that is.

That discussion prompted me to more methodically consider my own reasons for adopting web standards and for driving that adoption in my own workplace.

What are Web Standards

To introduce this topic, I should define the key term. Here, I’ll be using the term “standards” in many ways to reflect the ways that I use it and hear it used depending on the context. Prefaced that way, the term “standards” will be employed to mean:

• The use of CSS layouts rather than table-based layouts
• The use of semantic markup
• Adherence to a defined language specification or doctype

Arguments For Employing Web Standards

I’ve heard a lot of reasons for adopting web standards over the last few years. Those reasons range from the simple, “everybody’s doin’ it, doin’ it, doin’ it” which can be construed (and occasionally misconstrued) as blind adherence, to the esoteric. The former is probably more accurately classified as an appeal to authority fallacy, but there is an argument to be made that this appeal is blind by its very nature. I’d like to believe that my own reasons sit somewhere firmly in the middle. Hardly blind, but I’m not smart enough to over-analyze things. I’m a simple guy.

Arguments Against Employing Web Standards

Similarly, I’ve heard a number of real reasons to ignore web standards. Although I disagree with them, the arguments are thoughtful and worth considering. As I mentioned above, in almost all cases, these boil down to one of the following:

• Standards have a negative impact on design
• Employing standards is difficult
• The “old way” works

No. And yes. And argh. Respectively, of course.

Negative Design Impact

Within the standards community, there seems to be a certain degree of preference for a simplified design aesthetic, but that’s nothing more than an aesthetic preference shared by a like-minded community. It’s hardly a limitation imposed by the use of standards. The fact is, standards don’t even come into play until a design is implemented. Bring it, designers. It can be built. It may be harder – complexity in design is harder to build than simplicity whether standards are employed or not – but it can be done.

Level of Difficulty

I have no means of negating or even mitigating this argument. It’s true, standards are hard. CSS is not easy. Sure the syntax is easy, but that’s where the simplicity ends. In addition to -browser implementation differences there are also limitations within the 2.1 specification.

The beauty of the first concern, browser implementation issues, is that standards, once widely adopted and employed, will all but negate the concern. In other words, the creation and adoption of standards will mitigate or even eliminate one of the primary reasons given for not adopting them. Efficient.

The limitations are a bit tougher. They exist and they’re real. Ever tried to create two columns of equal height regardless of content? Ever tried to create a page with a header, footer and body whose height should not extend beyond the height of the window area? Ever tried to vertically align one element in the middle of a parent element? These things are hard. In my opinion, much harder than they should be. They are, however, limitations of the language itself and the language can be “fixed” with each subsequent version of the specification.

It’s hard, but take heart. It gets easier. Trust me.

The “Old Way” Works

So did Internet Explorer 5. Times change.

With all of that said, I still choose to employ and evangelize standards.

Why I Prefer Standards

Finally, we come to the real question that kicked off this thought.

Separation of Concerns

In my mind, this is the most important reason for developing to standards. Standards – in this context meaning the use CSS layouts – allow for the separation of presentation from content. This is not a new concept. OOP developers have been practicing this separation of concerns very effectively for a very long time. CSS allow web designers and front-end developers to employ the same technique in a different setting.

Use markup to structure the information contained within a document and CSS to present that information. Done properly, this separation makes it remarkably easy to update a site’s “look & feel”. The efficiency of this kind of structural discipline is highlighted during later maintenance phases of the project. Any time cost created by the learning curve is quickly negated by the long term maintenance savings.

Simplicity

Another benefit of standards is streamlined markup. Fewer tags, fewer attributes of those tags. The document’s markup is no longer responsible for dictating its presentation once that burden has been delegated to its style sheets. Take it a step further by separating behavior for content and the markup gets even simpler.

Readability

When faced with the choice, I’ll (almost) always prefer readability to performance. Simplicity, as mentioned above, offers one measure of readability. Less is easier to read than more, right? Another measure is provided by the use of semantic markup. If every element within a document is properly identified, the structure of that document is easily discernible.

Better Code

As a developer, this is the end game. I am, of course, assuming the obvious – that the code does what it needs to do. If this is not the case, then the developer won’t be a developer – or at least an employed developer – for very long. When all is said and done, by whatever means I choose to employ, my goal is to produce better code.

My standard of choice, with respect to doctype, is XHTML 1.0 Strict. I made this choice not because the language spec is perfect (it isn’t) or because browsers handle it better (they don’t; IE, I’m looking in your direction). I made that choice because it forces a valid, well-formed XML document. The boundaries of XML offer a measure of clarity – no more questions of where an element ends – and dictate a certain measure of consistency across documents and projects. Consistency is good.

Efficiency

As an individual developer, all of the reasons listed above add up to increased efficiency. As the leader of a team, there’s an extra benefit. Code reviews are much more effective when rules are in place. When more of those rules are dictated and enforced by the tools and methods chosen, then reviews can be less subjective. The rules are documented and become inherent to the project itself. If the document validates then, at its most elemental level, the code is “good”. Reviews don’t end there, of course, but it’s a hell of a start.

standards 6 Comments