CSS SUCKS?

 

If you write that CSS sucks you'll get accused of being dumb, not a pro, not a frontender, not SEO aware, just a designer, and whatever, even if you work in this field from the eighties and have done a lot of CSS in your life.

So let's make others, the pros, speak..

 

When I see articles like this old one:

 

http://www.alistapart.com/articles/holygrail

 

I get the feeling something was, and still is, deeply wrong.

It proves it CAN BE DONE. It proves it is QUITE EASY. And yet?

Why on earth some CSS GURU has to write a Holy Grail page on an almost perfect solution he found, based on other CSS GURUs' almost good attempts to solve this problem?

THIS SHOULD NOT HAVE BEEN A PROBLEM. It should not have the need to be addressed.

 

Ok, this article is quite old, but there is plenty of recent solutions, and even evolving solutions, to non existent problems.

The internet is full of posts by people (who know CSS well) on how to accomplish stupid things with CSS.

Some are made by acclaimed CSS GURUs and most of them get edited, on and on, because other people find problems and propose fixes. And many of them revert using Javascript or very bad CSS or even bad markup.

And they are so happy to be gurus, and to have found solutions, that they forget to see the real question: "why do we have to do this?"

 

There were millions of websites with basic 3 or 2 column layouts BEFORE CSS was ever thought of. How could they be so STUPID to make a standard that required hacks, fixes and experimentation so people, ten years later, had to find a working solution for such a basic thing?

 

The real truth is that people at the W3C at that time were rather dumb (OMG the King is NAKED!), and the recent changes for the better HTML5 (against the very dumber XHTML) prove it.

 

Everyone is talking about keeping content separate from layout, but that is not what CSS does. It has never done that. It has separated style from content, adding some layout functions to the style. Style, content, scripting and layout should all be separated equally.

 

If you really want to separate content from layout, you have to extract content, and leave the layout on the page.

 

Just imagine this for a second..

 

        two documents:

                - the HTML for layout

                - the XML content document with all the textual data

 

This has been done for years, it looks familiar, it looks like *templating*. Content comes from a database, a file or some other source and is inserted into the HTML page in the right places.

 

One dumb sample,

 

file 1: page.html

 

<html>

        <content src="content.xml" />

        <title><content id="title" /></title>

        <body><h1><content id="title" /></h1>

                <h2><content id="body_text" part="line 1 of trim(paragraph 1)" /></h2>

                <div class="main_body"><content id="body_text" part="line 2 to end" /></h2>

        </body>

</html>

 

This is a simple layout file, it has NO content in it. It is exactly like a template. It can use CSS or TABLE or Javascript (Flash, Java, Unity..) or whatever you wish for positioning (although in my opinion STYLE is not LAYOUT, so I would keep them separate like content).

The good news is: whatever you use, it doesn't matter, because it does not alter content! No FLOATs against TABLEs wars, no Javascript and Ajax war versus SEO and usability.

 

It introduces just few items to the HTML standards:

 

<content src="content.xml" /> that tells the agent where to look for content

<content id="an_id" /> just places the content of tag <an_id> of the content, inside the HTML document

 

Now let's imagine a sample content file, content.xml

 

<content>

        <title>My Sample Page</title>

        <main_body>

                This line is used as a subtitle

                This is just body text

        </main_body>

</content>

 

No layout, no style, no scripting. This is how it should have been done. Just by adding *ONE* HTML tag.

Content tags would have a meaning, like <phone>12345</phone> so search engines can use them to find things smartly.

 

You could put content inline, exactly like style and script:

 

<html>

 

        <content>

                <title>My Sample Page</title>

                <main_body>

                        This line is used as a subtitle

                        This is just body text

                </main_body>

        </content>

       

        <style>

                h2 {font-weight:bold;}

        </style>

       

        <script>

                //

        </script>

       

        <title><content id="title" /></title>

        <body><h1><content id="title" /></h1>

               

                <h2><content id="body_text" part="line 1 of trim paragraph 1" /></h2>

                <div class="main_body"><content id="body_text" part="line 2 to all" /></h2>

        </body>

</html>

 

A search engine should verify how many times the contents are used in the layout to increase score values, to avoid spamming and fake contents (like with fake keywords)

Links could be part of content, and of layout (buttons in layout, text links in content). Content could contain other HTML tags like <table> for real tabular data and <ul><ol> and <li> for lists of items

 

This is how, in my very personal opinion, it should have been done in the first place, but any other smarter solution is just as good, if it splits content from layout and style.

 

So now can I say CSS sucks? Big way. That doesn't mean tables and styled HTML are better, they just equally don't fit the equation for different reasons.

 

Francesco Munafò

Milano, Italy