Brack3t blog

Semantic Snakeoil

2011-10-03T21:31:43Z

For years now, we’ve been told that we should always use semantic class names and IDs in our HTML. And, in general, this is a good practice, I don’t want anyone to think it’s not. You should make your markup, all aspects of it, as accurate and related as possible. The problem, though, comes when people become fanatical about their classes and IDs to the point of swearing off grid systems and CSS frameworks in the name of “proper” web development practices.

So why isn’t it a big deal? Both the W3C and the WHATWG emphasize that the class attribute, and its values, if specified, should describe the nature of the content and not the presentation of it. And for the most part, I agree. This ideal has limits, though, that need to be addressed and understood. It’s currently impossible to be 100% semantic and still be useful.

Let’s start with the argument presented by the idealists: All class names and IDs should be semantic and address the nature of the element, not its display. This ends up with us needing to create new classes and ID for every project we do, tied directly to the use case of each bit of markup. Yes, some things could be repeated and copied from project to project, but a decent majority of the CSS would be unique. This is great if you’re the only person working on something, or working with a small group that works together on many projects. This is rarely the case with large or open-source projects, though.

Now, let’s look at the argument from the utilitarians: All class names should be generically semantic to the structure of the document and relate to the use case and nature of the element; IDs should be semantic to the project or page. This opens up the project to third-party grid systems and the like. So long as the class names have meaning to the document, even if it’s not semantic meaning to the content it’s wrapped around, it’s still valid and logical.

For a second argument against made-to-order frameworks for each project: using third-party libraries like the awesome Twitter Bootstrap, newcomers to the project will either have experience with the library, or can refer to its documentation to get up to speed; if you’re using a custom library of CSS for the project, a new developer needs to familiarize themselves with the whole thing with, lilkely, little to no documentation.

To my mind, and many other professionals, the point of the class attribute is to describe the element or its content. The element, though, is the more important bit to describe since using a semantic element already describes the content. If you put a list of links into a <nav> element, there’s no reason to give it a class of nav or menu or the like. There is, however, plenty of reason to give it a class that describes how it relates to other elements, such as span6.

Using these systems, as well, gives us the ability to reflow content in a way that remains semantic. To set the stage, we have a <section> of content that is the main content of the site, and an <aside> that is our sidebar. We want the page to reflow based on media queries. If we use an idealistic set of classes, such as sidebar, once the page reflows and the <aside> ends up below the main content, its class no longer has the same semantic meaning. Yes, we could have used a class like secondary-content or the like, but few people seem to use class names like this. If, though, we use something like span6, it loses no semantic meaning after the reflow as it is still spanning 6 of our columns. Yes, that’s describing the display but it’s describing it on relation to all the other elements, so it is semantic in context.

The other point I keep seeing being made is, that, to change the width of an element, the designer has to go and edit the HTML. If, though, you’re using HTML correctly, to where classes describe more than one object, if I want only one instance of an object to be wider, I have to either add, remove, or edit a class in the HTML anyway. If your knee-jerk reaction is that “my classes aren’t set up that way” and you’re using classes like they’re IDs, to where they’re unique, you aren’t using them correctly and should be using IDs on your elements. This also ties into more serious programming; if your model changes, you have to (usually) update your views/controllers and templates/views. This isn’t a unique concept and shouldn’t trip up any serious developer or designer.

Search engines don’t seem to care about class values, either, so using more of them won’t hurt your site’s SEO (if you care about that). Also, as far as content being available, if people are scraping your HTML, it would be better to offer it in a more consumable format like an JSON API or an RSS feed (aka XML). This way the content is separated from your presentation of it and can be used however the consumer needs it.

So, I put forth a new definition for classes:

There are no additional restrictions on the tokens authors can use in the class attribute, but authors are encouraged to use values that describe the nature of the content, rather than values that describe the desired presentation of the content. It is also valid to use values that describe the element.

Have comments? Continue the discussion on Hacker News.

Djangopeople.me

2011-06-13T18:50:00Z

What is it?

At it’s core, djangopeople.me is a place for Django developers to register and be found based on their geographic location, whether it’s by recruiters or a lonely Django developer like ourselves trying to find others close to him/her. That’s the general idea behind the site.

We wanted to make it clean, simple and fast. For the maps we ended up using Leaflet’s open-source Javascript library. We initially started with Google Maps, but the rate limiting was too restrictive on the geocoding API for our needs and frankly, loading maps seemed very slow. So, with the project being free-to-use (and us being cheap), we looked for something else.

Yahoo! Maps was the next step as they had a decent API and allowed more requests. Google currently allows 2,500 requests per day and Yahoo allows 5,000 requests (geocoding). Yahoo’s maps were faster to load but we seemed to have nothing but issues with Google Chome throwing a YMAP Javascript error we could never track down. We didn’t think it would be all that awesome telling Chrome users to clear their cache up to three times before the maps would load again (If you’ve had this issue and a have fix, for the love of all that is holy, let us know about it please).

After searching around for a day, we came across Leaflet. It was simple to implement and the maps were extremely fast to load compared to Google and Yahoo. You could also make the argument that they don’t have nearly the traffic that Google and Yahoo have but Leaftlet was simple and it worked. Also, our scientific method for testing the load times was simply us reloading pages over and over as we worked on functionality. So don’t expect any charts. Chris is an impatient guy, so if he gets annoyed by something he’s built, it’s not going live.

There is one issue we ran into with Leaflet and it has yet to be resolved. Their geocoding API, after about two weeks of use, started retuning funky results. By funky I mean, resolving Las Vegas, NV, to Livingston, Illinois. Dallas, TX would come back as being in Australia. Chris emailed their support team and they have confirmed it is a bug but they do not have an idea of when it will be resolved. Aside from that, their service has been fantastic.

It’s already been done.

This is true, djangopeople.net was the inspiration for building djangopeople.me. We realized that djangopeople.net had been down for some time, intermittently. It was useful and we had both been contacted by people looking for Django developers through that site. So the original idea was to bring that functionality back and hopefully make it better.

Kenneth came across a posting on Convore when we were almost ready to launch the site. It appeared that a group of developers were getting together to bring djangopeople.net back online. We almost stopped working on the site as dp.net came back online for a short time. It was really slow and then ended up going back down a day later. So we decided to finish the small bug fixes we were working on and launch it.

So, just to be clear, djangopeople.me was inspired by djangopeople.net. We just wanted to bring that back to the Python/Django community. We believe the interface is better and faster. Also, using Twitter as the main auth system made it dead simple to sign up. We’ve had a few people ask for other authentication methods but at the moment Twitter provided exactly what we wanted with no hassle.

We use your Twitter username so it’s very easy to find a profile of someone you already know and follow. This also makes it a little difficult to add other authentication methods as we’ll now have to deal with allowing people to choose usernames and possibly picking a Twitter username that a future developer would sign up with. We’re open to suggestions but we like the simplicity of using Twitter. Having recently wrapped up a project using the Facebook Python SDK, it was nice for Twitter’s auth system to just work and not get in the way.

What’s next?

We’ve had a good amount of people sign up and we’ve gotten some good feedback. We have a couple of ideas for tying into other Django services but we’re waiting for replies to our emails at the moment. We both contract/freelance full time, so we’ll probably spend the next week or two throwing ideas around before we know what the next step is. In the meantime, check out the site and let us know what you love and/or hate about it. We’ve got thick skins.