Writing HTML Right

One of the things that really bothers me in today’s web environment, is that it seems like everything has been made generic. I’ve been noticing an increasing number of websites that use class names like col-md-4 or some other meaningless class name like that one. There is nothing wrong with this, until you try to automate a task such as scrapping a website.

I’ve talked about web scrapping in the past, and I’ve also talked about how the semantic web is just a dream that we should be forgetting about. However, we shouldn’t go around giving only meaningless class names to our tags just because we don’t care much about a semantic web.

When I work on a website, I write the markup first not really caring how I’m going to display it. That is the beauty of CSS, and that is why a few years ago the CSS Zen Garden was such a big deal. When we write markup we shouldn’t care about what the element that we are describing will look like, but rather about what it is. This sounds a lot like I’m going back to web semantics, and maybe I am, but just a little bit, and not for the sake of semantics, but for the sake of separation of concerns.

The whole point of having CSS live in a different space from HTML was to keep them separate, but now we are tying them up together very tightly. This is not good.

The next time you create a website, try this:

  1. Get out your text editor, and write markup.
  2. For every tag you write, think about what it describes, and assign a class name to it that describes that. For example if the element you are writing markup for is a sidebar widget, then give it a class of widget.
  3. Do number 2 for each tag you write. If you cannot think about what a tag is doing there, it may not be needed.
  4. Use IDs. I know a lot of people nowadays say you should not use IDs in your CSS. Not using IDs in your CSS is probably a good advise, but you are writing HTML here.

You should also make sure you are using the correct tag. There are a lot of tags in HTML, and you should always make sure you are using the correct one that describes what is going on in your markup. A few years ago, a group of people decided that the web needed badly an article tag, so they added it. Personally, I think it is stupid, but I use it because it conveys more meaning that a generic div tag. The reasons why I think it is stupid that HTML 5 implements a bunch of new tags are outside the scope of this article, so I won’t go into that, but the point is that if there is something available for you to use, you should be using it.

Here is an exercise you can try:

Write a simple page using nothing but div tags. This page should be simple, but still have a variety of things like some title, a sidebar, maybe some quote from a famous person, or some contact information; just add anything you think of, but use only div tags. Once you are happy with your page, open it up in a browser and try to make sense of it. You can even take a screenshot of it.

After looking at your page for a little bit, go back, and start replacing the div tags for something more meaningful. For example, if you have a title, use and h1 tag, or if you have a a paragraph, use a p tag. Look at each div tag you wrote, and think about what it is doing, then, find the tag that better fits that description. For a list of html5 tags, you can go here: https://developer.mozilla.org/en-US/docs/Web/HTML/Element and for a list of tags organized semantically, you can go here: https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/HTML5/HTML5_element_list

Once you are done, look at your page in the browser again, and you will notice the huge difference that using the right tag does.

There is a lot more to writing HTML than this, but one thing is certain. When you write HTML you should think about content, not presentation. HTML describes what something is. After you are done, you may go back and add some classes that aid you in your CSS such as classes for columns, or font awesome classes, but do that only once you’ve made sure your HTML is marked up, properly.


Links of the day 12/11/2012

Yet another list of links. The last list is also marked as 12/11/2012. When I did it it was past 12, and I forgot to subtract 1 from the date. I hope it is not too confusing.

http://davidwalsh.name/pointer-media-query – Quick intro to the pointer media query.

http://arstechnica.com/security/2012/12/dexter-malware-steals-credit-card-data-from-point-of-sale-terminals/ – The alert word for a malware that steals credit card data from point of sale terminals.

http://codex.wordpress.org/Version_3.5 – Version 3.5 is out!

http://rmurphey.com/blog/2012/12/10/js-conditionals/ – Nothing new about if statements, but still worth reading for a good memory refresh.

https://github.com/blog/1302-goodbye-uploads – No more uploads on github.

http://arstechnica.com/business/2012/12/netflix-says-google-fiber-is-most-consistently-fast-isp-in-america/ – Netflix says google fiber is the fastest ISP in America. Lucky those who have it.
http://alt1040.com/2012/12/google-chromebooks-sector-educativo – New $99 google laptops. (Spanish)
http://alt1040.com/2012/12/darpa-espuma-hemorragias – New foam technology to stop internal bleeding on wounded soldiers. (Spanish)

Links of the day 12/11/2012

I have been just sharing links these last few posts, and sadly, today is not the exception. I am aware there are a few posts that need to be written, and I need to continue on that series that I started about building AIR Apps, but time has just not been too kind with me lately. Anyway, I hope this links can keep you busy.

http://davidwalsh.name/documentfragment – Just a quick intro to document fragment.
http://davidwalsh.name/deferred – Javascript defer for a cleaner code.
http://www.sitepoint.com/get-started-with-three-js/ – Getting started with three.js
http://blog.millermedeiros.com/stop-writing-plugins-start-writing-components/ – Plugins VS Components. Interesting.
http://blog.millermedeiros.com/namespaces-are-old-school/ – Namespaces are old school, use modules.
http://blog.millermedeiros.com/amd-is-better-for-the-web-than-commonjs-modules/ – A look into why AMD is better than commonjs modules. Is it?

blog.millermedeiros.com/tag/vim/ – Improved VIM status bar. Nice!

http://davidwalsh.name/phone-link-protocol – The phone link protocol.
http://davidwalsh.name/vibration-api – The vibrating API. Lets hope it does not get abused.

http://davidwalsh.name/ssl-wordpress – Quick and easy way to force SSL on wordpress sites.
http://dzineblog.com/2012/12/best-practices-for-keeping-wordpress-clean-secure.html – WordPress security best practices.

Interior Design:

http://www.atareao.es/ubuntu/conociendo-ubuntu/quieres-aprender-a-crear-paquetes-para-ubuntu/ – How to create Ubuntu packages. (Spanish)

http://dzineblog.com/2012/11/33-new-freebie-buttons-and-icon-sets-released-in-autumn-2012.html – Free icon sets.

http://ruby-python.com.ar/ruby/ – A ruby tutorial that I have not yet followed, but I share in case you are interested. (Spanish)

http://davidwalsh.name/twitter-cards – Nice explanation on how to create twitter cards.
http://creativefan.com/black-and-white-backgrounds/ – Black and white backgrounds. Mostly pictures, and some of them are not really B&W, but still interesting.
http://alt1040.com/2012/12/twitter-rastrea-webs – Twitter keeps track of the sites you visit. And how to stop it. (Spanish)
http://build-podcast.com/ – A postcast about development tools.
http://www.mightydeals.com/ – A website that seems to offer good deals on resources for web professionals.

Enjoy the readings, and don’t hate me for posting nothing but links these last few rounds.

I Love My Work, but I Hate Web Development

The more I work on web development, the more I realise how much I hate it. This is a very strange situation, especially because I do really love my work; I just hate the way I have to do it.

Let me explain what I mean. I hope that by the end of this long read you get the idea that I’m setting to communicate here, and that you join me on my rebellion against web development as it is today.

I will start with an example. Imagine a world where there are no computers, or typewriters, or even paper. All you have is rock and hard tools to scribe your thoughts. In this world there is a very high demand for books, which are made out of stone and cannot be mass-produced easily. You are a fiction writer. People love your books, and you love writing them. Except, that you hate having to write them.

It is not the idea of creating content that you hate, or the motion of writing itself, but rather the fact that it takes you a very long time to put those books on stone because of the rudimentary tools that you have. This is precisely what I mean in the title.

It is not the idea of creating an awesome website or webapp that I hate, but rather the nuisance that it represents actually creating them with the set of rudimentary technology that we have available. Even more annoying is the fact that not only do we have to use a very basic set of tools, but we also need to support even more archaic tools. And to add insult to injury, we are supposed to obey by a set of rules that have been laid out by people who mostly do not understand the web of today. Let along that one of tomorrow, which we should have gotten yesterday.

The more I work on web, the more I realise how wrong it feels to do it. It really feels wrong to have to create my content using a limited set of tags that were thought of by people who knew nothing about what I’m trying to create, and who would probably never care. It feels wrong to have to use an API that is mostly redundant (DOM), and designed by people whose work is not to create with this API. It feels wrong to have to do the same thing more than once to make sure that it works across browsers and platforms. I’m sure that by now you are getting the idea.

This is why Ajax libraries have succeeded. Ajax libraries are created, maintained, pushed, shaped, and refined by content creators, not by specification-and-standards writers. The people behind jQuery, Dojo, MooTools, YUI, and many others, are people who have created these tools to solve problems they have encountered in their journey as web and application developers. We need more of this, and less of W3C nonsense.

I used to be standards oriented until I discovered that the people behind the standards have no idea of what they are doing. Don’t get me wrong here. I have a lot of respect for the people who set out to standardise a huge mess such as the web. It is just that they have spent too much time trying that they haven’t realised the web changed.

The best time machine mankind has invented is called webstandards. While reading some of them, and not only web standards, one can feel like it’s re-living 2000 all over again. And it’s scary because sometimes you are actually reading a year-2000 document. This is insane. You cannot standardise the web of today when your base for standards is the web of 2000.

There are many examples of things that should have been done differently. One of the most common case-scenarios that frustrates me is CSS. In my opinion, and I express it because this is a very subjective essay, CSS is wrong. It starts with classes, then it degrades with some aspects of selectors, especially how they are interpreted, and it hits the bottom with the syntax passing for some other stages in the process.

The idea of classes is a language that has no way of extending this classes is wrong. One can argue that you can extend a class by adding the class name that you want to extend to the CSS declaration of the object from which you want to extend, like this:

color: blue;
width: 200px;
height: 50px;

If we want to create a new element that has the class name of truck, and we want it to extend the CSS of car, we can do it like this:

.car, .truck{
color: blue;
width: 200px;
height: 50px;
width: 300px;

This is fairly simple, but not quite usable when working on real projects because most of the time, by the moment you reach truck, you already added a hundred lines under the .car declaration. You have two options. One is to move your .truck declaration 100 lines up and mess up your CSS file organisation. The other is to leave them both 100 lines apart from each other which is also not good because the it becomes a maintenance problem, which by the way the first option does too.

Moreover, this is not extending, it is merely subscribing two classes to the same set of rules. Subscriptions are good, but not as the base for extending classes.

How I think it should be done:

color: blue;
width: 200px;
height: 50px;
/*100 lines of code go here.*/
.truck extends .car{
width: 300px;

What is the big difference? you might ask. This option also has the problem of having both declarations 100 lines apart from each other. However, in this version, there is a clear way to know that the styles that you see for .truck are not the only ones affecting .truck, where as in the current way of doing so, there in no such visual cue.

The whole idea of classes is wrong in most programming languages, but that is material for a whole other essay.

There are many ideas that have been laid out to solve the many issues of CSS, two that come to mind are OOCSS, and Stylus. Both are worth a look.

CSS is not a programming language. Rather, it is a styling language, which was good enough for when the web was a bunch of static documents. It even made sense when the webapps where things like forums, blogs, and e-papers. Today we need a styling language that borrows ideas from programming languages. One feature that would be a first good step in the right direction is adding variables to the language, and arithmetic capabilities. Stylus implements these ideas.

CSS is a styling language, but we need it to become a state representation language. The web of today is state based, and CSS doesn’t do well in this area. Moreover, we need it to be an animation language. So far Javascript has done that job, but CSS has demonstrated that it has potential to do it to.

Another reason why I hate web development is HTML. There is a lot of excitement about HTML5, which is good, but there are fundamental flaws in the design of HTML that just make the language not suitable for the web. There are, for example, security issues with window. This could be thought of as a problem with javascript, but it is not. Javascript has no window, that is an HTML global variable. Javascript has a global object, and window refers back to that global object, but window is not part of Javascript, it is the global object implementation in HTML. HTML5 does nothing to solve this issue. Instead, it adds more complexity to a system that is in itself complex, and complexity is the first enemy of security. But there are more fundamental problems with HTML.

HTML is a very closed language. HTML has a defined set of tags. This tags have a define behaviour, and you cannot expand this tags. Technically you can, but at some point you will run into trouble. There is no way to create semantically meaningful markup with the language that we have today. This can be argued, of course, but the truth is that HTML is too small to cover the needs of developers today. In order to create meaningful markup you need to use classes, and IDs, and this becomes a problem when you are creating webapps.

Once I said that HTML5 was built for blogs. The new additions to HTML that conform the HTML5 specification has a clear influence from the blogging community. They wanted an article tag, an aside tag, a section tag, a header tag, a footer tag and all of the rest because that is what they need. If you get together with blog designers, all they talk about is content, footer, sidebars and sections. We cannot build the web on top of blogging engines.

We need a language that allows us to specify more than just content sections; we need to be able to specify UI elements other than input boxes and buttons. There are some new elements that allows us to do this, like some new form elements that promise a brighter future, but it is not enough. We should have gotten those back when the talks about web 2.0 were all over the web.

HTML is just not suited for web development today.

It seems that from the stack (HTML, CSS, and Javascript), the only language being pushed in the right direction is Javascript (actually Ecmascript). This is a good thing.

Finally, the DOM is a mess. When people say the hate Javascript, the usually mean this:

var a = document.getElementById(‘myID’);
var b = document.createElement(‘span’);
b.appendChild(document.createTextNode(‘My text’);

I look at them and say, please step back from the computer and read a book. That is not Javascript. What you are seeing right there, that mess is the DOM’s API.

The DOM has many design issues that are beyond my willingness to explain them. The one thing you should know about it is that it was poorly design and it’s an awful thing with which to work. It is ridiculously repetitive and has horrible method names. Don’t let people fool you into thinking that is the way to write methods, because it is not.

There are many other reasons to hate web development, like the one we call IE*, but I think you get the idea.

There are two things that need to happen for web development to really advance. The first is we need to rethink HTML and CSS, and the second is getting rid of browsers that are holding back web development. Until this happens, we will be living in a world with a wasted web.

*IE is getting better, but that is of no use when the older version stick around for too long like they do.