What do people argue about when explaining Tableless and CSS designs?
- Separation of presentation and content
- Ability to create semantic documents, with well-defined formats, where each element has an intended meaning
- It makes maintenance simpler than using tables
These seem to be the three main points about Tableless and CSS. What I'm going to try to explain is that all these points have noticeable flaws, and their imperfection divide people that argue dogmatically about them, without a clear understanding of the main issues.
The problem
When designing a tableless website, we often add <div> elements solely to define regions that aid in the manipulation of the layout. These elements are just workarounds to the CSS limitations, making it able to position the elements correctly.
The problem is that this practice conflicts with the separation of presentation and content idea, and has nothing to do with the content semantics.
For instance, let's pretend we are designing a new layout and we are having a hard time positioning both menus correctly with CSS. Then we add a new element, let's call it "block-1", that wraps both of them to accomplish this task:
<div id="block-1"> <div id="main-menu"> <ul><li>Main menu</li><li> ... </li></ul> </div> <div id="secondary-menu"> <ul><li> ... </li></ul> </div> </div>
The "block-1" element has no meaning in the content, the menus are still identifiable without it. Its purpose was solely to help the CSS styling due to its limitation in being able to position the elements as desired in the screen.
If you're paying attention, maybe you could ask, "well, what about renaming 'block-1' to 'head', wouldn't it add meaning to the content?". Yes, it would, I'm really not arguing against this simple case, but even thus the "head" element would be optional.
What I'm saying is that adding it to the document probably wouldn't be necessary, and that its intention was solely to create a workaround to the CSS layout. So a document structure that could be immutable and very well defined was unnecessarily changed just because of a layout issue.
That means the whole concept of content and layout separation is still broken, if you think that Tableless and CSS is just the right solution to it.
Currently, when we want to change the site layout we will probably have to deal with the content code, depending of its complexity. Think about it, we're changing a document we claim to be semantic (only content, no styling elements) and we are neither adding or removing content nor adding new semantics, we just want it to be able to fit in the new layout grid, how does that sound to you?
To me it sounds that everything people are talking about practices like Tableless, Semantic Web, Accessibility, SEO etc are just wrong. It sounds like they're being dogmatic regarding these arguments.
Don't get me wrong, I believe that adding semantic tags, like h1, lists etc to the elements in your document can really help the search engine classifying a document more precisely, increasing the odds of someone that wants it finding it.
What I do not believe is that just adding tables to create a grid to the website will magically decrease the document ranking or avoid it of being displayed in mobile devices, as if tables would just break there and fixed length divs wouldn't.
That is why I think this model is still broken and there is no practical advantage in avoiding tables completely.
If we are using or not using tables for layout really doesn't matter a lot. If you have a tableless document and you still need to fix it when you want to change the layout, it's still not too much different of using tables.
Of course, if you're positioning your content with CSS you're less likely to change the content page when you want to change the layout. But still there is a probability of changing the content page when we want to change the layout. We lack a better method of creating a well-defined grid for the content, be it in CSS or another tool.
About the maintenance point, it's still not so clear to me how much I'm saving from my time when I stick to a full CSS layout. I stick to it most of the time, it's true, but it's still not so clear. There are cases where we create complex tableless layouts, with clever CSS tricks and hacks, that I wonder if it would be so different or more complex if we were using tables instead.
To me, it's still not worth wasting your time doing a full Tableless Semantic CSS website if:
- you are still going to change the content when you want to change the layout, which shows that it might not be entirely semantic
- you are not going to be penalized by search engines just because you used some tables and the good and old Strict HTML 4.01. And I strongly believe none is penalized by any search engine just because there are tables defining the layout in your page
- you will need to eventually create a different layout for mobile devices because you've noticed the current page doesn't work so well there or it just needs to be different in that context.
A more well-defined case
OK, in my examples so far we were able to change the content page and create workaround in it so that we could make our CSS styles work fine. Now let's think in a more ideal case or how it might be in the future if we have very well-defined formats in order to make the Semantic Web work.
Let's pretend now that there is a XML format we use when we want to describe a website. In this XML format there would be elements for describing menus, logos, articles etc. Then we want to create a version of this data for human viewing, that would simply be the way we see most websites, a logo on the top left corner, a vertical menu left aligned, maybe an horizontal menu in the header, just below the logo, and in the center the article contents.
Since most of us are lazy, we don't want to recreate a version just for human viewing, we want to take advantage of that XML file and place its contents in the layout we have in mind. And in an easy way, I don't want to create a script to deal with this XML and generate my HTML, I, as a designer, want a language focused on creating the main style and grid of this website, like CSS.
However, a styling language like CSS is not perfect when we want to change the elements and place them in an area inside a grid, like we would do using tables.
Some people argue that Semantic Web search engine would work well only with well-defined file formats, describing all sort of documents, catalogs, image galleries etc. I don't have a opinion on this, I think that good search engines could extract meaning from lousy defined formats, by just analyzing its text, if it has a really good algorithm for that.
Anyway, let's think that the well-defined formats is the only way to the Semantic Web. So in my view it would be really nice if we could deal with those formats in a simple way, creating a completely independent presentation layer that is still not possible (or not feasible) using only what we have in CSS today.
This language must be simple, in the sense that it must be limited, being good in its main purpose, like CSS.
What I'm trying to describe is a tool that can easily do something like this:
Let me try to be clearer here, I'm not really talking about the problem of a full document transformation between 2 different formats of XML (like my previous example), that would be cool if it could be as simple as creating a CSS stylesheet yes, but I cannot think of anything better than XSLT for that.
Let's focus our attention to the problem of transforming HTML to HTML, that is, just positioning the elements in a layout grid without too much effort or clever tricks.
Yes, pure JavaScript might work, but I want something simpler, focused only in that task.
If I'm the developer and my work is just to bring you the content produced by a system (say, a simple HTML 4 file, but not intended to be modified just for design purposes, for whatever reason), the ideal solution for you, the designer, would do the presentation task completely separated form that HTML file.
That doesn't happen today, only when the layout is really simple in a way that you don't need to add <div>s which only purpose is to aid the CSS dealing with the elements correctly.
I want that the designer could easily create his own layout grid and style, and not touch any single bit of my content document.
A proposal
This proposal is just a thought experiment in how it would be possible to create a layout completely separated from the content and still being simple to deal with it.
The first point is that we lack some common method of creating the layout grid in CSS or in another HTML file and then applying it to the content in the browser (client-side).
Sticking to the HTML file idea, we could use an HTML template containing placeholder tags indicating were the elements from the content page content page will fit.
Example, this is a simple HTML page with the only-content, fully semantic and no layout helpers:
<div id="main-menu"> <ul><li>Main menu</li><li> ... </li></ul> </div> <div id="secondary-menu"> <ul><li> ... </li></ul> </div> <div id="news"> <div class="item"> <div class="title">First news title</div> <div class="description">First news description</div> </div> <div class="item"> <div class="title">Second news title</div> <div class="description">Second news description</div> </div> </div>
This would be the HTML template defining the layout grid:
<table> <tr> <td>{#main-menu}</td> <td width="30%">{#secondary-menu}</td> </tr> <tr> <td colspan="2">{#news}</td> </tr> </table>
Or, if you prefer, tableless (but that wouldn't really matter since it would be assembled in the browser):
<div id="header"> {#main-menu} {#secondary-menu} </div> {#news}
Then the CSS style would be applied to the generated page based on the layout grid.
The idea is that you can add the layout structure after the page contents, transforming the fully semantic content page into a layout-able page, pretty much like XSLT, but without its complexity, enough to be used by designers, still editable by famous HTML editors like Dreamweaver and somewhat similar to CSS in the way the elements are included in the template tags.
For example, you could include all elements with class="item" from the "news" block in the content page, avoiding other possible elements in there just using {#news .item}. It would work like a CSS selector.
The pros of this proposal is that it would work immediately through a clever implementation in JavaScript. I don't know how complex it would be, but still possible I guess.
Like the CSS style applying, it would be processed in the client-side and the content-only page would be fetched directly by search engines and be available through the browser's "view source" option, without the layout "garbage".
The HTML template that defines the layout grid could be cached by the browser, resulting in an even faster fetching of the content page.
And what about browsers with no JavaScript and CSS?
Do you mean Lynx and similar, right? Well it would work anyway, the document logic, links and forms would still be in the content page, in a way that it works independently of the layout being applied or not.
No comments:
Post a Comment