html vs css pt1/an introduction
It's time to put all the color and css experimentation behind us for a while. This article will serve as a small introduction that will describe my reasons for writing the next batch of articles. Since they might be considered a little controversial, I thought it wise to spend a little time documenting the situation as I see it, before starting with the articles. The battle between html and css is now officially opened.
the theory
In the grand scheme of things, html is way more important than css. html is a way of marking up data on the web, as to make sure everything and everyone is able to use and understand it. It brings structure and meaning to data so not only humans, but also machines and programs are able to interpret the data online. In comparison, css is only a way to visualize that data, be it on screen somewhere else (ie. print). This visualization might be important to us humans, software doesn't really care about that.
It's also a lot easier to write good html than it is to write good css. Better browser support and less freedom are a few of the reasons why we can now write pretty good to excellent html documents. It's a bit more complicated when we are writing css. Lack of browser support, lack of much needed functionality and little theoretical reflection makes our css files into plain battlefields.
These are probably the most important reasons why html has won the battle over css. We see html as the core of publishing data on the web (which it is) and we adapt our css to that. Which is fair enough really, if we'd be living in a theoretical world.
the reality
But ... of course there is a big but. When I look at the problems I face every day at work, I can say that are mostly related to css. And part of those problems are caused by the drive to write perfect html code. So along the way I tried to restore the balance between html and css a little bit, as to make my work a little easier. Because no matter how you look at it, visual presentation of a site is for most people (project managers and users) still the main priority.
Of course, I'm not talking about adding 7 wrappers around every element to make sure I'm covered all the time, but I don't mind adding small things that add little complexity to the html and serve as a good simplification for my css code. In the following articles I will be describing some of these decisions to illustrate my point.
People who can't stand an extra <span> or extra css class should be warned to approach these articles with
caution, but even they should consider the trouble they're making for themselves by trying to fix everything in css.
Stay tuned.
You talking about smth like this for creating rounded corners?
Hmmm, not quite. Those are a lot of wrappers, while I will be talking about minor changes that allow you to write better css.
But it reminds me that I should still write an article on rounded corners, as there's a good way to cut on structural elements in some cases.
Ok, waiting for the second part and samlpes of this method.
I'm not really sure I understand the need to describe this as a battle or a contest; HTML & CSS have a symbiotic, not an adversarial relationship. It's not a case of one being better than the other. If HTML is to be better than CSS then why not compare it to javascript too? And while you could argue that HTML doesn't really need CSS, in a real, commercial world, it does.
You are 100% right, but I'm writing from a real-world perspective. And when you look at the work we do, you'll know that from time to time we have to decide whether we put an extra structural element (mostly useless from a structural/semantic point of view) in our html documents to ease our css work.
In certain crowds, this is considered "not done" and "bad practise". Certain people seem to value html perfection higher than css perfection. The purpose of these series of articles is to explore our reasons for choosing one above the other.
Hope this gives you a better idea, if not, I'll be adding my next article quite shortly, which I hope might further explain a couple of things.
Positing a "war" between html and css is a classic example of creating a straw man. The complimentary technologies of html/xhtml and css are both necessary to the creation of the translator/interface the semantic web intends. The goal of a semantic web is to make it possible to meaningfully exchange data between divergent and at times incompatible database systems. The December 2007 edition of Scientific American offers examples of how medical and other data are moved seemlessly between databases by the technologies involved in the semantic web.
The role of css in this process is not simply to separate appearance from content but to insure that the appearance does not compromise the content. That is, authors should not use css to undermine the semantic nature of an element i.e. not using headers for big text. A more semantically rich language like html 5 or any of the specific xhtml systems (MathXML) make it possible for machines to extract meaning about the information from the structure used to present the information. More complex exchanges of data await the further development and common usage of sparql, more extensive usage of rdf structures, foaf, owl, etc. to add more depth of meaning and translations between meanings systems.
The obligation of css in all this is to use elements as they are defined in the specs. With html4 this is an unsatisfactory experience since many elements have either minimal meaning or nebulous meaning. Discussions and even arguements over what element should do what have, one suspects, influenced the development of html5. It really is good that there will be a nav element in 5 along with all the other refinements resulting from spirited interchanges.
The intersection of presentation and content will always be a point of contention. It's the irritent that leads to the pearl. Wrapper divs cause no problems as long as they don't replace more apt elements. The occassional span isn't a problem. Both will simply be ignored by a semantically aware ua. The contention between css and html isn't a "war" its a process of evolution. Welcome it, join it, don't wage war.
Maybe the vs is a little bit charged, but I'm not aiming to start a war between html and css. I respect both, I understand the function of both and I also understand how important both are.
The vs is mainly aimed at the choice we make when we have a situation where a semantically useless (but not semantically incorrect) html element might ease our css worries. It's often considered good practice to give preference to slim html code, which is where I disagree from time to time.
I've just added an article which will hopefully illustrate the point I'm trying to make here.
No, it's actually a false dichotomy.
* required fields