Discussion: Is CSS layout overrated? | The Coffeehouse

kenfine
heaven and earth

The subject line is just a little bit inflammatory. The long version is, "What are the advantages and disadvantages of CSS-based layouts versus good implementations of other available technologies?

I'm not talking about CSS typography, here: I think all of us agree that CSS typographic styles solve a lot of problems.

Rather, I want to discuss all-CSS layouts that dispense of tabular elements for positioning and layout.

Meyer's The Definitive Guide and many websites are long on CSS evangelism, citing the need for "accessibility" and "standards."

I'm not sold. Someone sell me. My thinking circa May 28, 2005 is that CSS tricks pale in flexibility and capability to what's possible with a good database design and some web application programming.

People cite the importance of of seperating "content" from "presentation." In my experience, a database provides you with a structured and consistent way to pull clean data.

People suggest that CSS can unleash the lost paradise of the syntactic web. IMHO, it's a lot more likely to happen with a richly associative, consistent database schema that fully describes its content. People are typically using and naming CSS1 typographic elements with presentational, rather than syntactic naming schemes.

CSS adherents argue that CSS-based layouts are more easily and consistently read by the wide variety of devices out there. I'm honestly curious: is this true? What data standard will a BlackBerry consume and render well? How about a PalmPilot? PocketPC IE? Mobile telephones? Screenreaders for the blind? Would these technologies play nicer with CSS/CSS2, or a particularized text-only or HTML-only version based on server-side server-side detection of the client?

So long as there are inconsistencies in how CSS is rendered across browsers and devices, and those inconsistencies are a PITA relative to competing methods of content delivery, its use as a supposed "standard" is blunted.

People argue that CSS can easily be re-cast into myriad different presentational forms. It seems to me that once my data is in a well-structured database, I can render it however I want: as text, as table-based HTML, as a CSS layout. And it's also possible to render the page in ways that aren't so easy to translate with typical methods that have evolved around CSS: as a PDF file, as a multipart e-mail, as dynamically-loaded data in a Flash movie.

A DB and programming gives you the power to render your data in the present and into any future presentational form.

Classes and OOP techniques can manage the complexity of rendering to multiple clients and presentational types. I have some half-baked ideas for using declarative markup to easily redesign page templates, and ASP.NET/2.0 seems to have anticipated many of the intents of my design.

I guess what I'm really asking is: given a good database schema and an ability to write web applications, what additional things will I win by spending time making CSS layouts...and what are the liabilities?

Depending on the answers I get back, I may also be making an argument for the relative priorities of up-and-coming developers. Is CSS layout truly the killer app to learn first? Or would their attention be better turned to learning structured data concepts, DB stuff, and an application layer (ASP, PHP, ASP.NET?)

Interested in the range of opinions out there. Convince me.

Thanks,
-KF

mVPstar
I'm white because I smelt an onion.

I like CSS more for the ease of dynamically creating elements and div tags as opposed to messing around with tables.

With CSS, I can just say "Response.Write("<span class="sidelink"">My Link</span>")" CSS gives you the freedom to place whatever you want where you want it, regardless of the existing structure of the page.

In a tabled layout, however, some times you would need to predict what the current element nest looks like, and you would also have to know how many columns you've declared so far so you can incorporate blank cells in order to correctly position your data. Also, you'd sometimes end up having to cope with very long statements.

.NET does alleviate the pains of binding database data to tables, however, this applies to the "correct" usage of tables - tables as presenting raw data.

In the end, it really shouldn't matter what you use. As you have mentioned, a good database structure would be more worthwhile than worrying about processes that are very rarely beneficial.

Then again, it is always nice to prepare for the future, and that is why mostly all of the websites I create now a days uses CSS/DIV layouts.

Hope this helps
mVPstar

W3bbo
The Master of Baiters

mVPstar wrote:
all of the websites I create now a days uses CSS/DIV layouts.

You shouldn't be relying on the <div> element for hooking style rules.

The <div> element is just a (more or less) semantically netural box/container, you can also apply style rules to any other element.

I've moved on from the beginner's:

<div id="nav"><ul><li><a href="#"></a></li></div>

To:

<ul id="nav"><ul><li href="#"></li></ul>

Ph33r XHTML2.0 Smiley

ZippyV
Fired Up

kenfine wrote:
People argue that CSS can easily be re-cast into myriad different presentational forms. It seems to me that once my data is in a well-structured database, I can render it however I want: as text, as table-based HTML, as a CSS layout. And it's also possible to render the page in ways that aren't so easy to translate with typical methods that have evolved around CSS: as a PDF file, as a multipart e-mail, as dynamically-loaded data in a Flash movie.

You don't get it (in this part). All the things you describe can only be done at the server side while css does style/markup at the client side. What do they mean with "different presentational forms"? Simple, you can have 1 webpage with multiple stylesheets where each of those stylesheets are used for those different presentational forms: paper, television, projection or a monitor.

W3bbo
The Master of Baiters

Oh and please, lets not forget the Holy Grail of CSS, mm'key? Smiley

Cairo
I want my waffle sundae, give me my carbs!

Honestly, I'm using a mix of table-based plus CSS styling these days. Straight CSS ends up being more work, for a less reliable result.

Having said that, I recently leaned on the power of CSS to reduce a webpage from 50k to 5k by removing most of the style to an external CSS file (that's loaded once for the entire site). So, it's cool for that.

My favorite is XSL + CSS, though. Post-processing the HTML/XHTML/XML and adding CSS makes giving a site a facelift really easy.

W3bbo
The Master of Baiters

Cairo wrote:
Honestly, I'm using a mix of table-based plus CSS styling these days. Straight CSS ends up being more work, for a less reliable result.

So what you want, but I prefer semantic XHTML1.1 w/ CSS2.1 over tables any day.

I'm actually slower with tables than I am with CSS now.

Maurits
AKA Matthew van Eerde

If you're into a data-oriented paradigm, you might consider skipping HTML and CSS altogether. Dump your queries direct to the browser as XML, and link an XSLT stylesheet to handle formatting.

Warning: this is a rather avant-garde approach and I've only seen one site actually use it.

EDIT: And my take on the question is yes... CSS is overrated, but also underused. Smiley

Shining Arcanine

kenfine wrote:
People cite the importance of of seperating "content" from "presentation." In my experience, a database provides you with a structured and consistent way to pull clean data.

People suggest that CSS can unleash the lost paradise of the syntactic web. IMHO, it's a lot more likely to happen with a richly associative, consistent database schema that fully describes its content. People are typically using and naming CSS1 typographic elements with presentational, rather than syntactic naming schemes.

The idea isn't so you have two separate data sources but so that making changes is easier. Creating an entirely new layout of HTML soup isn't exactly easy and done properly a pure CSS design can expedite this process by leaps and bounds. A good example of this would be:

http://www.csszengarden.com/

Also, a richly associative, consistent database-schema is fine and dandy but exactly how do you take that and present it to your visitors?

kenfine wrote:
CSS adherents argue that CSS-based layouts are more easily and consistently read by the wide variety of devices out there. I'm honestly curious: is this true? What data standard will a BlackBerry consume and render well? A PalmPilot? PocketPC IE? Mobile telephones? Screenreaders for the blind? Would these technologies play nicer with CSS/CSS2, or a particularized text-only or HTML/only version based on server-side server-side detection of the client?

Standards compliance means that there is a specification that all of these devices are designed for and therefore it will work. HTML soup on the other hand isn't so clearcut.

kenfine wrote:
So long as there are inconsistencies in how CSS is rendered across browsers and devices, and those inconsistencies are a PITA relative to competing methods of content delivery, it's use as a supposed "standard" is blunted.

http://www.w3.org/Style/CSS/#specs

There are the specifications. If everyone made things according to them there wouldn't be a problem. Unfortunately there are a few people who don't so you'll have to take that up with them. Until then, there are other people you can turn to.

kenfine wrote:
People argue that CSS can easily be re-cast into myriad different presentational forms. It seems to me that once my data is in a well-structured database, I can render it however I want: as text, as table-based HTML, as a CSS layout. And it's also possible to render the page in ways that aren't so easy to translate with typical methods that have evolved around CSS: as a PDF file, as a multipart e-mail, as dynamically-loaded data in a Flash movie.

That doesn't change the fact that the data needs to be delivered some way, and delievering HTML soup makes your life a living heck. Not to mention it renders slowly, it takes longer to transfer, and it raises server loads as a consequence of the longer page transfers.

kenfine wrote:
A DB and programming gives you the power to render your data in the present and into any future presentational form.

You're not the one who is rendering it, the client is. You're putting it into a format, yes but you're not rendering it.

kenfine wrote:
Classes and OOP techniques can manage the complexity of rendering to multiple clients and presentational types. I have some half-baked ideas for using declaritive markup to easily redesign pages, and ASP.NET/2.0 seems to have anticipated many of the intents of my design.

Then go knock yourself out, no one is forcing you to write web pages properly.

kenfine wrote:
I guess what I'm really asking is: given a good database schema and an ability to write web applications, what additional things will I win by spending time making CSS layouts...and what are the liabilities?

Hmm... Not much I suppose; unless you considering the following to be useful:

Faster Development
Smaller Pages (think bandwidth)
Faster Page Rendering
Lower Server Loads as a consquence of connections closing faster
Ease of Use

kenfine wrote:
Depending on the answers I get back, I may also be making an argument for the relative priorities of up-and-coming developers. Is CSS layout truly the killer app to learn first? Or would their attention be better turned to learning structured data concepts, DB stuff, and an application layer (ASP, PHP, ASP.NET?)

If you're going to be writing websites, it is generally a good idea to know how to write them before you do anything else.

kenfine
heaven and earth

Thanks for the replies, everyone.

Part of what I'm exploring is how "web standards" translate to real world implementations. Ideally every client would adhere to W3C. If that's not happening, then developers have two choices:

a) develop to a spec that they believe the world "should" follow; or

b) develop something that works for the clients that are out there.

Shining, I think you missed some of the nuance of what I'm saying. No need to cite csszengarden; look again and you'll notice that site linked in my original message. Nor am I asking if CSS layout is worthwhile or not; one scenario I mentioned was rendering CSS1/2 out of dynamic database content.

It's reasonable to ask whether the gains one gets out of a theoretically purer and more elegant implementation are worth the costs in time and compatability. "Proper" "usable" and "HTML soup" are loaded terms with inbuilt biases.

Guiding the discussion a bit: given the following clients:

BlackBerry
PocketPC
Safari
Windows Smartphone
Other Phone types
Accessible screenreaders

...how do they render "web standards"? (anyone know? Bueller?) Do they do better with plain text, tableless HTML, or CSS? If they don't directly support CSS, what are typical strategies for tranforming data from CSS'ed markup to a form that works well for them? This isn't a set-up job... I'm honestly interested in how other people get the work done, and how those methods compare to server-side methods that I understand well.

What are the limits of translations from CSS to other presentational forms, and how do people get around these limits? It's clear to me how to make differently styled pages, or printer-ready versions of pages, or pages that are optimized for a particular display format. It's less obvious how you can use CSS to do things that typically involve server-side code: a rendering as PDF, or a rendering as a multipart mail, or a translation to an XML feed.

-KF

mVPstar
I'm white because I smelt an onion.

The beauty of a CSS layout is the fact that in can degrade nicely on clients that don't support CSS.

Most likely, the page would render as regular text. On a PDA/Smartphone, text is usually the best format for actually getting the content to the user as opposed to trying to render 500px table layouts to such a small screen and creating page overflows.

For instance, if you take W3bbo's webpage: http://www.bannedhosting.com/ and save it to your desktop (just the page, not the stylesheet), and then open it up in your browser, this simulates what happens when a client doesn't support CSS.

Of course the hidden humour in my prior statement could also be "just open it up in IE and you'll see what happens when a client doesn't truly support CSS". Smiley

Anyways...as you can see, his page looks wonderful and entirely useful, even without the styles.

kenfine wrote:
It's less obvious how you can use CSS to do things that typically involve server-side code: a rendering as PDF, or a rendering as a multipart mail, or a translation to an XML feed.

You can't. At least, I'm sure that's not possible. CSS is meant to style documents. CSS doesn't position the actual elements in a document nor does it write/append/or delete any. CSS only styles the representations of those elements that get delivered to the client, and as was said before, CSS is on the client side, not the server side.

W3bbo can back this up. Smiley

mVPstar

W3bbo
The Master of Baiters

mVPstar wrote:

You can't. At least, I'm sure that's not possible. CSS is meant to style documents. CSS doesn't position the actual elements in a document nor does it write/append/or delete any. CSS only styles the representations of those elements that get delivered to the client, and as was said before, CSS is on the client side, not the server side.

W3bbo can back this up.

Sorry Vivek, but I'm going to have to backstab you there Smiley

Shining Arcanine

kenfine wrote:
Thanks for the replies, everyone.

Part of what I'm exploring is how "web standards" translate to real world implementations. Ideally every client would adhere to W3C. If that's not happening, then developers have two choices:

a) develop to a spec that they believe the world "should" follow; or

b) develop something that works for the clients that are out there.

Shining, I think you missed some of the nuance of what I'm saying. No need to cite csszengarden; look again and you'll notice that site linked in my original message. Nor am I asking if CSS layout is worthwhile or not; one scenario I mentioned was rendering CSS1/2 out of dynamic database content.

It's reasonable to ask whether the gains one gets out of a theoretically purer and more elegant implementation are worth the costs in time and compatability. "Proper" "usable" and "HTML soup" are loaded terms with inbuilt biases.

Guiding the discussion a bit: given the following clients:

BlackBerry
PocketPC
Safari
Windows Smartphone
Other Phone types
Accessible screenreaders

...how do they render "web standards"? (anyone know? Bueller?) Do they do better with plain text, tableless HTML, or CSS? If they don't directly support CSS, what are typical strategies for tranforming data from CSS'ed markup to a form that works well for them? This isn't a set-up job... I'm honestly interested in how other people get the work done, and how those methods compare to server-side methods that I understand well.

What are the limits of translations from CSS to other presentational forms, and how do people get around these limits? It's clear to me how to make differently styled pages, or printer-ready versions of pages, or pages that are optimized for a particular display format. It's less obvious how you can use CSS to do things that typically involve server-side code: a rendering as PDF, or a rendering as a multipart mail, or a translation to an XML feed.

-KF

This is what media types are for. You can have a different stylesheet for those devices. If I recall there are some nice articles on this at alistapart:

http://www.alistapart.com/

XiXora

W3bbo wrote:

mVPstar wrote:all of the websites I create now a days uses CSS/DIV layouts.

You shouldn't be relying on the <div> element for hooking style rules.

The <div> element is just a (more or less) semantically netural box/container, you can also apply style rules to any other element.

I've moved on from the beginner's:

<div id="nav"><ul><li><a href="#"></a></li></div>

To:

<ul id="nav"><ul><li href="#"></li></ul>

Ph33r XHTML2.0

that would be unstructured xhtml 2.0 Wink

there is a nav list for xhtml ( like there was for html 4.0 i think ( deprecated in xhtml1.x ) )

See this ref: http://www.w3.org/TR/2005/WD-xhtml2-20050527/mod-list.html#s_listmodule

W3bbo
The Master of Baiters

Bah... I forgot, okay? Tongue Out

XiXora

i dont mind Tongue Out

i just wish it was supported better Smiley

as well as css3 Big Smile

ie7 has support for some css3 selectors ( not the official ie7, the js hack for ie )

kenfine
heaven and earth

Shining said: You can have a different stylesheet for those devices. If I recall there are some nice articles on this at alistapart: http://www.alistapart.com/

Good lead, Shining, thanks. I spent the morning reading through many of these articles, and have created a short list of the ones that speak to the issues we've discussed in this thread. I've copied the list and links below.

The first article in particular is relevant to some of the issues we've raised here. CSS is part of the solution but it cannot do everything. I started this thread because I was interested in the chief virtues as well as the limits of CSS layout in 2005. I'm interested in where it works best, where it breaks down in practice, and where it is usefully supplemented or replaced by other technologies. It still seems like we're fighting nonstandard renderings of our supposed web standards, and that's somewhat painful to develop for.

If people have additional links or perspectives from their own work about where CSS layout works well and where it doesn't, I'd love to hear your thoughts.

Thanks for all the good discussion, everyone, very helpful.

-KF

Separation: The Web Designer’s Dilemma
http://www.alistapart.com/articles/separationdilemma/
An article that tries to nail down what exactly we mean by "presentation" "content" and "structure" in practice. At the end of the article, the author posits a penultimate (and as-yet unbuilt) CMS for web content seperation. This article speaks most closely to some of the issues I've raised in this thread.

RENDERING FOR DEVICES

Pocket-Sized Design: Taking Your Website to the Small Screen
http://www.alistapart.com/articles/pocket/
CSS and pocket-sized devices.

Print It Your Way
http://www.alistapart.com/articles/printyourway/
Using CSS to style printable versions of pages.

CSS Design: Going to Print
http://www.alistapart.com/articles/goingtoprint/
Very good walkthrough of how to use CSS to make media-specific renderings -- in this case, printable pages.

Big, Stark & Chunky
http://www.alistapart.com/articles/lowvision/
Using CSS to restyle sites to accomodate low-vision users.

STYLE SWITCHING

A Backward Compatible Style Switcher
http://www.alistapart.com/articles/n4switch/
Javascript Stylesheet switcher that degrades well all the way to poor NN4

CSS Design: Size Matters
http://www.alistapart.com/articles/sizematters/
Old (and probably obsolete) discussion of how to manage different variations of CSS1 text presentation in all the browser types.

Build a PHP Switcher
http://www.alistapart.com/articles/phpswitch/
Building a stylesheet switcher in PHP. Techniques are readily translatable to other scripting platforms.

IMAGE REPLACEMENT

Facts and Opinion About Fahrner Image Replacement
http://www.alistapart.com/articles/fir/
Good discussion of the available screenreaders, their manufacturers, and how they fail with the Fahrner Image Replacement technique.

In Defense of Fahrner Image Replacement
http://www.digital-web.com/articles/in_defense_of_fahrner_image_replacement/
A very well written and thoughtful article that rebuts some of the common complaints about FIR.

Using Background-Image to Replace Text
http://www.stopdesign.com/articles/replace_text/
Extended discussion of FIR implementation.

mVPstar
I'm white because I smelt an onion.

W3bbo wrote:

mVPstar wrote:
You can't. At least, I'm sure that's not possible. CSS is meant to style documents. CSS doesn't position the actual elements in a document nor does it write/append/or delete any. CSS only styles the representations of those elements that get delivered to the client, and as was said before, CSS is on the client side, not the server side.

W3bbo can back this up.

Sorry Vivek, but I'm going to have to backstab you there

CSS positioning:

position: absolute | relative | static | fixed;
float: left | right | none;
clear: both | right | left | none;
top/left/bottom/right: ;

CSS element removal:

display: none | block | inline | table-cell | etc...;
visibility: hidden | normal;

CSS element "adding"/appending

content: ;
counter: ;

So nerrr

No, that wasn't what I meant. I meant that you can't actually write and remove elements. Sure you can hide them with CSS but that's not the same as deleting an element.

Say if you have "<span class="test">hello</span>", I doubt you can use CSS to change that to "<div id="pdf-test">hello</span>".

I was talking about physically changing the elements, not using styles to effect their representation to the client.

Sorry, I wasn't clear enough. Tongue Out

mVPstar

SvendTofte

mVPstar wrote:
The beauty of a CSS layout is the fact that in can degrade nicely on clients that don't support CSS.

This is one fallacy I'm pretty tired of seeing. While it's literally true, A website written using pure CSS and HTML will usually degrade well to a totally CSS-oblivious client.

The problem is that there are SO FEW totally CSS-oblivious clients. We don't care about bots and stuff, so that leaves us with small devices pretty much, and perhaps some specialty browsing device for handicapped (though most visually impaired use IE for browsing).

The problem is that by far the largest number of clients (like in the 99% range) have varied and mixed support for various parts of the CSS standard.Imagine a browser supporting background-image, but not background-repeat (NS4!). It could potentially render the page unreadable. This whole issue is even why we spend so long fighting IE, FF, or Opera, or whatever browser is having a problem, because CSS in effect does no degrade gracefully. And if we don't check it in said browser, the page can literally become unreadable.

That said, CSS is a heck of alot better then the alternative choice. Years back, I've nested tables (on commercial sites) up to nine levels, and then it was all framed even! And the cascade is simply a beautiful thing.

But people also should see that CSS is only meant to go so far. CSS in my opinion scales like (I need to watch my language), and should not be used, at all, for say behaviour, apart from the most simplistic :hover effect. Building entire menus out of CSS rubs me the wrong way...

jamie

I like css - but do not like "floating" attributes when using it for layout

for example: what is the css code for the following ( if anyones bored)

<-- 100% table width-->

100 pixels

centered

160 pixels

non- specified width

100 pixels

centered

160 pixels

i cannot make the above in css - perhaps i could if there was a wysiwyg editor. Ive tried coffeecup stylemaker and a few other tiny css apps. All are like notepad - with lists of commands.

I so hope the next frontpage will let you draw layout with css like you can with tables - and that you can choose properties of cell or table (just like now) to get to padding and borders - only it will render to css code wise

code for above:

<TABLE height=340 width="100%" border=1>
<TBODY>
<TR>
<TD vAlign=top width=160 height=334> 
<DIV align=center>
<TABLE id=table1 height=86 width=100 border=1>
<TBODY>
<TR>
<TD width=100 height=86>
<P align=center>100 pixels</P>
<P align=center>centered</P></TD></TR></TBODY></TABLE></DIV>
<P> </P>
<P align=center>160 pixels</P></TD>
<TD vAlign=top height=334>
<P align=center> </P>
<P align=center>non- specified width</P></TD>
<TD vAlign=top width=160 height=334> 
<DIV align=center>
<TABLE id=table2 height=86 width=100 border=1>
<TBODY>
<TR>
<TD width=100 height=86>
<P align=center>100 pixels</P>
<P align=center>centered</P></TD></TR></TBODY></TABLE></DIV>
<P> </P>
<P align=center>160 pixels</P>
<P> </P></TD></TR></TBODY></TABLE>

Sven Groot
My name has 9 letters. Coincidence? I think not...

There you go. Tested in IE6 and Firefox 1.04.

Notice how much cleaner the HTML itself is compared to the mess jamie put above.

jamie

what did you use to make that?

or did you code it by hand?

Sven Groot
My name has 9 letters. Coincidence? I think not...

jamie wrote:
what did you use to make that?

or did you code it by hand?

I coded it by hand using VS2005. I hate WYSIWYG html designers, they never do what I want.

Maurits
AKA Matthew van Eerde

Sven Groot wrote:
I coded it by hand using VS2005. I hate WYSIWYG html designers, they never do what I want.

+1 on that sentiment.
I had problems with early VS.NET HTML designers throwing in spurious ID= attributes... so I switched to Notepad. Wink

EDIT: hmmm Sven you used
position: absolute;
which imposes some limitations on this design... I wonder if there's a way to do it without position: absolute;
Never mind you don't use top: left: right: or bottom: so it's a non-issue

kenfine
heaven and earth

SvendTofte wrote:
mVPstar wrote:The beauty of a CSS layout is the fact that in can degrade nicely on clients that don't support CSS.

This is one fallacy I'm pretty tired of seeing ... The problem is that by far the largest number of clients (like in the 99% range) have varied and mixed support for various parts of the CSS standard.Imagine a browser supporting background-image, but not background-repeat (NS4!). It could potentially render the page unreadable. This whole issue is even why we spend so long fighting IE, FF, or Opera, or whatever browser is having a problem, because CSS in effect does no degrade gracefully. And if we don't check it in said browser, the page can literally become unreadable.

...

But people also should see that CSS is only meant to go so far. CSS in my opinion scales like (I need to watch my language), and should not be used, at all, for say behaviour, apart from the most simplistic :hover effect. Building entire menus out of CSS rubs me the wrong way...

I appreciate your comments, SvendTofte. One of the reasons I started this message thread because I'm in the process of evaluating how a very large archive of institutional web pages should be rendered now and in the future.

People are excited about the promise of CSS presentation and its many advantages, but at times that excitement keeps people from taking a cleareyed look at how the tech works in practice. You can call something a "web standard", but if the majority of your users do not get a readable page, your standard is "broken", however conceptually elegant it may be.

Developers can blame browsers... but users will invariably blame the devs if the page does not work.