Coffeehouse Thread

28 posts

Discussion: Is CSS layout overrated?

Back to Forum: Coffeehouse
  • User profile image
    kenfine

    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

  • User profile image
    MasterPi

    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

  • User profile image
    W3bbo

    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

  • User profile image
    ZippyV

    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.

  • User profile image
    W3bbo

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

  • User profile image
    Cairo

    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.


  • User profile image
    W3bbo

    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.

  • User profile image
    Maurits

    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

  • User profile image
    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.

  • User profile image
    kenfine

    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

  • User profile image
    MasterPi

    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

  • User profile image
    W3bbo

    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

    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 Smiley

  • User profile image
    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/

  • User profile image
    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

  • User profile image
    W3bbo

    Bah... I forgot, okay? Tongue Out

  • User profile image
    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 )

  • User profile image
    kenfine

    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/">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/">http://www.alistapart.com/articles/pocket/
    CSS and pocket-sized devices.

    Print It Your Way
    http://www.alistapart.com/articles/printyourway/">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/">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/">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/">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/">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/">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/">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. 

  • User profile image
    MasterPi

    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

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.