Stories
Slash Boxes
Comments
Search

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

A New Era in CSS Centric Design?

Posted by Cliff on Sat Jun 10, 2006 10:45 PM
from the where-do-we-go-from-here dept.
Programming
byrnereese wonders: "The media never fails to point out how the age of Web Two-Point-Oh has helped to drive the adoption of Ajax into the Internet industry, but rarely does anyone point out that it has also help popularize CSS-centric design practices -- the Slashdot redesign being only one example. But now that we, as programmers, feel comfortable ditching the use of font tags, finally grok div's, understand absolute vs relative positioning, and can work around all of IE's CSS bugs, what is the next step for HTML and CSS? Several standards or conventions seem to be coming to forefront: one is building standards around the HTML structure itself so that wildly different designs can be achieved via style-sheets alone (e.g. CSS Zen Garden and The Style Contest), the other being the standardization of CSS classes (e.g. micro-formats) so that semantic meaning can be derived from the class name we use to label our content. Both show an interesting potential for how this technology is evolving. So here is the question for all the visionaries out there: where is this taking us? What's next for HTML? What's next for CSS?"
+ -
story

Related Stories

[+] News: Slashdot CSS Redesign Contest 587 comments
A few months back we went and redesigned Slashdot with fancy new CSS templates. The idea was that with a new clean CSS framework under the skin, we could more easily redesign the look & feel of the site. At that time I mentioned that we wanted to have a contest to redesign Slashdot. Well that time has come. Read on for the rules, instructions, and timeline. Oh, and did I mention that the top prize is a new laptop?
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

A New Era in CSS Centric Design? 50 Comments More /

 Full
 Abbreviated
 Hidden
More
Loading... please wait.

  • Every time there is a story on CSS here, we always get a bunch of people who say CSS is useless and that table tags are the only way to design a site. I'm always amused by people who have been living under a rock (or haven't updated their skill sets) for the last couple of years. CSS Zen Garden [csszengarden.com] should stand as solid proof that CSS works, and can produce some gorgeous and highly usable results (and check out the Zen Garden's Zen of CSS Design [amazon.com] ) for a description of general aesthetic.

    CSS is broken in some obscure ways, I've encountered some limitations with styling elements with a certain xml:lang in documents whose body tag has a different xml:lang, but for 99% of sites, it's ready now.

    • Re:I'm sure the naysayers will be here shortly (Score:5, Informative)

      by RzUpAnmsCwrds (262647) on Saturday June 10 2006, @11:59PM (#15511671)
      . CSS Zen Garden [csszengarden.com] should stand as solid proof that CSS works

      No, it doesn't. Seeing as web programming is my job, I can tell yout that tables - horrible as they may be - make a better layout tool than CSS. I can't tell you how many times I have to tell graphic designers that one of the elements of their design (like equal length columns) is a major pain in the neck to implement in CSS. Of course, IE's horribly buggy CSS2 support doesn't help, but there are so many things in CSS that seem - well - stupid. CSS was designed around an idealistic view of the web - a web where pages were designed by web developers. In the real world, this is rarely the case - it is the graphic designers who lay out the page, and the web programmers get stuck trying to implement their design. CSS utterly fails in that regard.

      Sure, you can make a design that works well using CSS - zen garden and countless other sites prove this. But there are so many things that were simple with tables that become unnecessarily complex with CSS.

      Most developers simply give up and resort to absolute positioning or nesting
      tags. Neither is substantially better than the tables that they replaced - and in many cases, they are substantially worse.

      There are other elements of CSS that are utterly stupid. Why should padding be excluded from "width"? Or, for that matter, the border? Why is it so hard to make equal-height columns?

      Is CSS better than what it replaced? In terms of element style - borders, fonts, colors, etc. - it's substantially better. But CSS sucks at layout.
      • But there are so many things that were simple with tables that become unnecessarily complex with CSS.

        This is why tables were popularized in the first place. The lay-person who just wanted to throw up a personal web page had neither the time, nor the inclination to learn CSS, so they resorted to the easiest possible manner of positioning things the way they wanted: tables.

        Creating layouts with CSS was never easy, which has always been exactly the problem.

        But there are problems with table-based designs, first and foremost being user presentation, in the form of increased load times for the increased amount of text, AND because browsers can't render the table until the entire thing is downloaded. I have seen some website that don't come up for quite sometime because their entire 226kb layout is contained within a single outer table, so it doesn't show up on the screen until the whole page is downloaded.

        The second major problem with table-based designs is accessibility: screen readers for the blind don't like tables very much. I don't know about the newest versions of programs like JAWS, but the ones a few years ago would read every table element, including empty ones that only contained spacer images. Not a very user-friendly experience.

        Most developers simply give up and use tables because it's faster. This is ALWAYS the motivating factor in businesses where time is money - and consequently why so few commercial websites are built using CSS. It takes longer to learn. But once you learn it, things that are at first "unnecessarily complex" become easy, just as tables are easy now because everyone does it that way.

        "Easy" in the end has less to do with syntax and language, and more to do with how widely the technology is used, because the more people use CSS, the better the documentation for it will be, and the more websites will show you how to do simple things like a 3 column, full height layout (which I know how to do; I have a basic template I always use when starting a new page for this layout, so I don't have to redo it every time).
          • What sane developer relies on a parsing bug in a browser? How easy is that to maintain?

            Well, I can't disagree with you there. That part is insane and I hope in the next couple of years we see a proliferation of fully CSS compliant browsers. I mean, that's the whole point of standard in the first place. Even Firefox doesn't fully implement CSS correctly, and I'm not sure why.

            • That part is insane and I hope in the next couple of years we see a proliferation of fully CSS compliant browsers. I mean, that's the whole point of standard in the first place. Even Firefox doesn't fully implement CSS correctly, and I'm not sure why.

              Full support of CSS isn't necessary for the production of CSS designed websites. It just needs to be good enough - which is where we already are. Its the same as not needing to know every word in the English language in order to have a conversation.

          • Every browser implements tables properly.

            Try align="char". Or how about the whitespace-significant bug Internet Explorer has? Or how about THEAD/TFOOT? How many browsers do something with the axis attribute? How about the vertical-alignment "bug" that is actually correct behaviour but breaks up table layouts so that there's lots of little gaps? What about the abbr attribute? Do some browsers still treat optional closing tags as required (not sure about this one)?

            Table layouts are buggy too, i

      • Both parent and grandparent posts make good points. I used to do tables only, but finally got handed the Zen of CSS Design book by a designer and decided it was time to learn. I'm a programmer, not a design guy. I was really impressed with how much could be done with CSS, but like the parent says, CSS sucks at layout. I like the fact that it seperates the content from the style. However, after spending a couple days trying to get a couple pages laid out purely using div tags and CSS, I ended up using a

        • It kinda felt like I was cheating after looking at all the cool stuff people were able to do with Zen Garden, but is it really cheating to mix tables and CSS? No. Use the best tool(s) for the job and your life becomes much easier.

          But life doesn't become easier for those using screenreaders, nor for those developing processing tools that expect semantic markup.

            • they may not care if someone with a screenreader can properly read it.

              Many Western countries have laws now that require certain groups to make their web content accessible to people with disibilities. Sometimes it is a serious issue that designers make their sites readable with a screenreader.

        • The problem with using tables is that when you make dynamic web pages, using PHP/JSP/ASP/?, that your code has to figure out how to display the content. If you use CSS, you can write the code once, and just have it output the content in a bunch of div tags. Then when you want to change how your site looks, you don't have to go through all your code changing things around. Just change the CSS that says how the content is to be displayed. Tables save time if you are never going to change your design. How

            • But tables are way, way easier to learn than css layout is.

              I think I can speak for most people who have used CSS for a while by saying that once you actually know how to use CSS, table layouts are far harder, tedious, and time-consuming than semantic markup and some CSS. I'd recommend trying to redesign a table-based site (with no tabular content to boot; that's like using a spreadsheet program as an actual database). Oh wait, that might take a while as you have to change every fucking page and deprecate

      • Re:I'm sure the naysayers will be here shortly (Score:5, Insightful)

        by Dracos (107777) on Sunday June 11 2006, @02:54AM (#15512015)

        Whether or not tables are a better (I think you mean easier) layout tool, they are not meant to be used for anything other than (gasp) tabular data. Using a table for anything else is bad semantics, page bloat, and, let's face it, primitive.

        In the last three years, every site I've attempted to rebuild in CSS from tables I've been able to do with 90% accuracy. It's not only a different layout tool, it's a different layout model. You can't expect tables to CSS to be a 1:1 conversion, there will be compromises along the way.

        I've been in the same situation with graphic designers. The problem is that they think the web works like paper, where the design is a monolithic entity that simply exists. They have little to no understanding of what HTML and CSS is, does, or how it works. The concept that their full screen 50 layer photoshop file will be chopped up, gutted of text, and reassembled later is entirely beyond them. Long time print designers make the absolute worst web designers, I've found.

        Another part of the problem is browser support for CSS, especially the various values for the display property (especially table, table-row, table-cell, inline-block), and the position property. Position is mostly misunderstood, anyway: "relative" is not the default value, "static" is. See my sig for my thoughts on browser CSS support.

        Too many people try to wrestle with CSS to make it do what they want. This is most often the fault of a poorly thought out document structure combined with a poor understanding of CSS. Let the document work for you, I always say.

        CSS is vastly better than what was before: nested tables full of font tags. CSS is more flexible, concise, and clean. Is it perfect? Not in its current form, but maybe the next version.

        Equal height columns are easy: height: 100%;. Too bad IE can't get this right unless you declare the height of the parent element. Hate the implementation, not the specification.

      • No, it doesn't. Seeing as web programming is my job, I can tell yout that tables - horrible as they may be - make a better layout tool than CSS. I can't tell you how many times I have to tell graphic designers that one of the elements of their design (like equal length columns) is a major pain in the neck to implement in CSS. Of course, IE's horribly buggy CSS2 support doesn't help, but there are so many things in CSS that seem - well - stupid. CSS was designed around an idealistic view of the web - a web

    • CSS is broken in some obscure ways

      It's fundamentally broken in that it's incredibly arcane. A sane standard would have examined what people actually did in web pages and other layouts and designed constructs that would accomodate those.

      CSS gives you a bunch of tags and a "box model" that no one had ever heard of, that is incredibly hard to implement and that bears only a mathematical relationship to what the user wants to do.

      If CSS let the user break the page into actual elements that humans deal with, like

      • If CSS let the user break the page into actual elements that humans deal with, like columns, headers and footers

        The blind don't deal with "headers" and "footers". Tools for processing semantic markup don't either.

        • If CSS let the user break the page into actual elements that humans deal with, like columns, headers and footers

          The blind don't deal with "headers" and "footers". Tools for processing semantic markup don't either.

          Neither the blind nor tools for processing semantic markup deal with CSS (not @screen anyway) - they deal with the markup.

          CSS should have had operators to group marked up data and style things relative to their place in the group. And it should have had the ability to set constraints on sizes (eg

    • One more problem. I often encounter websites that use CSS where tables would produce about the same results, and with CSS the site runs like a snail. It downloads faster, less markup overhead etc, but if I open 5 pages at once (my habit, see a list of links, middle-click them all to load in tabs, continue reading), Firefox freezes for, like, 30 seconds to render them. MSIE does even worse.

      CSS is awfully computationally heavy. Full CSS support would be a hell for handhelds and such. It defines how things sho
      • Drat. Stiljstek.nl used have lots of great CSS templates, including a three-column one with headers and footers, but it appears to no longer exist. Back in 2003 I pared their three columns down to two to use on my own site. Their CSS worked fine without Javascript, and in Internet Explorer. So, it is possible.
        • http://www.alistapart.com/articles/holygrail [alistapart.com]
          Yes!! That's the article I used quite some time ago to learn to do this! I had long since lost the link, thank you!

              • If you can't do something you could do with tables in CSS without hacks, is CSS really a step forward?

                You're forgetting that abusing the <table> element type for non-tabular data is a hack in itself. The real choice is between hacks that appear in the HTML for every page (table layouts) and hacks that appear in a single stylesheet (CSS layouts). When you pollute your HTML, you make it harder to do things like screen-scraping, use user-stylesheets, use Greasemonkey scripts, cache effectively, a

                • The difference is that using the table "HTML hack" is syntactically correct and highly likely to show up properly on all modern (and even many archaic) user agents. Many of the CSS hacks rely on either improper syntax or improper parsing of correct syntax - which means you're disregarding standards on a much more fundamental level than if you had just used a table. You need to get syntax down before you can worry about semantics.

                  Hopefully CSS3 will make this discussion moot in the near future.

      • Show me an implementation of a three column layout, with header and footer, without using javascript. In a perfect world, you'd do it without browser dependent hacks too.

        The websites I did this for are no longer up, but it's not something I found terribly difficult. In fact, I learned to do almost everything better without Javascript, especially dynamic multi-level menus that are easy, semantically correct (e.g. using ul and li instead of tables and javascript), and stylishly appealing, using about 100

      • Re:I'm sure the naysayers will be here shortly (Score:4, Insightful)

        by Bogtha (906264) on Sunday June 11 2006, @03:39AM (#15512090)

        Three-column layouts are easy.

        body {
        display: table;
        width: 100%;
        }

        #header, #footer {
        display: table-row;
        }

        #foo, #bar, #baz {
        display: table-cell;
        width: 33.3%;
        }

        Tell me that CSS is broken and I know you'll be trolling. We all know it's not CSS that's broken, but browsers. Browsers have bugs. Web developers have to work around them. This is nothing new. Table layouts themselves are one big bug workaround hack. You say you don't want browser-specific hacks in the CSS, but the CSS only has to be written once. I want to avoid hacks in the HTML, which is one of the reasons why I choose CSS layouts.

  • Whatever is next ... (Score:4, Funny)

    by xmas2003 (739875) * on Saturday June 10 2006, @11:12PM (#15511563) Homepage
    Slashdot will adopt in 5 years ... ;-)

  • rounded corners (Score:3, Funny)

    by russellh (547685) on Saturday June 10 2006, @11:16PM (#15511574) Homepage
    and the long wait for CSS 3.0.

  • Simple answer (Score:4, Informative)

    by kennygraham (894697) on Saturday June 10 2006, @11:47PM (#15511639)

    What's next?

    XHTML2 [w3.org] and CSS3 [w3.org]

    But XHTML2 can't be a reality until IE can parse XHTML, or IE loses a lot more market share. (no, it can't, it can parse pretend XHTML that's served as text/html, and you can't serve XHTML 1.1 or XHTML2 as text)

  • if slashdot links itself in a story, then does it cause a /. effect on itself? seems like an endless loop of pain.
  • The main reason CSS has taken off is that one can feasibly write one sheet that mostly works in the mainstream browsers.

    Back when one had to code for multiple versions of IE with poor CSS support it was just easier to hack together a mix of HTML layout and some inline CSS embellishments.

    IE7 still has some significant CSS issues, but we're getting much closer.

    Imagine when IE8 and Firefox 2 both support CSS3 nearly identically!
  • CSS is more than just web. It's XUL, it's XAML, and it's Boxeley(For all those AOL nerds out there). It's also in several smaller toolkits, and it's starting to pop up kinda everywhere. It's a good thing.

  • First, let's get a couple things straight:

    • AJAX is the functional foundation of Web 2.0. Sprinkle in a design philosophy that actually embraces whitespace and non-miniscule fonts, and primitive machine to machine communication, and you get the rest of the "trend".
    • HTML has been deprecated for six years. XHTML finally got rid of HTML's quirky syntax and bad semantics.

    What's next won't even be achieveable for two to three years. The other browsers will continue to implement standards as they are drafte

    • XHTML finally got rid of HTML's quirky syntax and bad semantics.

      What semantic changes happend between HTML 4.01 and XHTML 1.0?

      I don't think there was one single such change.

    • HTML has been deprecated for six years.

      HTML 4.01 has not been deprecated in any way.

      XHTML finally got rid of HTML's quirky syntax and bad semantics.

      HTML 4.01 and XHTML 1.0 are virtually identical in terms of semantics. You do realise that things like <font> are present in XHTML 1.0, don't you?

      What's next won't even be achieveable for two to three years.

      CSS 2 won't be achievable for two to three years, let alone CSS 3. Internet Explorer 7.0 will still be missing key parts of CSS

    • Re:2 to 3 more years of the same, then a shift (Score:4, Informative)

      by suv4x4 (956391) on Sunday June 11 2006, @08:25AM (#15512595)
      HTML has been deprecated for six years. XHTML finally got rid of HTML's quirky syntax and bad semantics.

      That's funny. Because XHTML is a carbon copy of HTML 4.01 as a dialect of XML. All that got "cleaner" is that XHTML uses a subset of SGML (XML), where HTML is a SGML dialect.

      The semantics of both are totally the same. You've been brainwashed.

      XHTML2 has some competition, however, in the form of HTML5. While I can understand frustration at the glacial speed of the W3C at producing new documents, WHATWG seeks to damage most of the progress made since HTML 4.01.

      W3C says "do as I say". They can't even implement what they recommend properly. They tried, with Amaya, and the project is now dead (not to mention it was always one buggy and slow piece of software).

      WHATWG catters to the needs of the web developers and web users TODAY. They are formed by browser makers and web developers who have feet firmly planted on the ground as to what constitutes a semantic and functional web we can actually use.

      W3C unwillingness to cooperate brought us the table hacks, and now the CSS hacks. We, web devs, always have to use "hacks" of some sort, not just because of bad browser implementation, but because if plain defunctional standards..

      Then come zealots who claim W3C can't be wrong, refuse to join a discussion and declare WHATWG is a bunch of terrorists who want to blow up the internet.

      Good thing is, while zealots are pretty vocal, the rest of the practical folks are quietly working on making a better Internet with WHAWG.

      The canvas element and SVG bring new ways of displaying graphical stuff to be interacted with

      The canvas element was invented by Safari and incorporated in WHATWG's HTML5. I though they work hard on wrecking the Internet?

      the table layout trolls and Dreamweaver monkeys will be two tech generations behind

      The current generation of Dreamweaver produces strict XHTML with CSS based layouts. I bet ranting at fukll power didn't leave you time to see how the world around you adapts to changes.
  • I'm totally fed up with absolute positioning. That was a terrible idea. It was a bad idea in TeX, it was a bad idea in PostScript, and it is a bad idea in CSS. Now font width assumptions are built into the layout. We have text that runs off the page boundaries, buttons that move when clicked [tribe.net], and browser-specific dreck in the page markup. Giant step backwards. Tables were a good feature and they need to come back.
    • Like any tool, CSS can be abused. Absolute positioning is a powerful tool that is easy to misuse in WWW environments because it tends to be used with pixel units to create print-centric, rigid designs that can't be scaled/zoomed (e.g. in pre-IE7 browsers, Firefox). Pixels may be great for kiosks and other fixed width/height environments but there're not good for use with current mainstream browsers - but use 'em' and 'percentage' units and you can automatically create designs that resize to the viewport and the user's preferred font size without the problems you describe.

      Something I advise developers new to CSS is to avoid using absolute positioning until they clearly understand the side-effects of applying it and to generally treat it as a last resort in the CSS toolbox - kind of like 'if-all-else-fails try the sledgehammer'. With a well structured document as a foundation (headings, lists, et al) then a good understanding of floats, margins and clear can do most layout tricks for you, but if there's no other way but to use absolute positioning then use it with 'em' and 'percentage' units again to keep it scaling. Granted that this is difficult to do if developers use todays WYSIWYG authoring tools - almost by definition.

      Not a giant step backwards by any means, developers of problematic sites just need to think a bit more about the best use of the tools in the CSS toolbox and a bit more about designs that scale. After-all, it's possible to create rigid layout problems with table-based design too.
      • I think people see absolute positioning as the evil, when it's really not.
        It's mainly evil if you use it to place the main layout blocks, but once you enter into those blocks it's often very useful to place sub elements by using absolute inside the parent element positionning (i mean by using #layoutblock { position: relative } #layoutblock #logo {position: absolute; top: 0.5em (or maybe even px); left: 0} )
        What i mean is that maybe it should not only be seen as the last resort, but also as something
  • I've recently done a load of cross-browser Web 2.0 stuff. Working on a Mac my primary platform is Safari which, as many will know, is one of a very limited number of browsers to pass the ACID test. It took me quite a while to get to grips with the idiosyncrasies of CSS itself (the specificity rules about which style will be used can be confusing and slightly counter-intuitive sometimes) but generally working with Safari was fine.

    I checked and validated my HTML and CSS code against the W3C validation tools

  • Something which bugs me about the W3C (Score:3, Interesting)

    by HawkingMattress (588824) on Sunday June 11 2006, @03:42PM (#15513718)
    I don't understand why they don't procure reference implementations of their standards to go with them, like tomcat is for servlet containers. Oh I understand why they didn't chose to do that at the beginning, because the internet has been built on specifications like that. But it's not like implementing an FTP or SMTP server, it's way more complicated and it seems it's very hard to get right, and nearly impossible to get right for every browsers at a given time. History has proven that, so maybe it's time to try another method ?

    I think it would make things so much simpler for everybody, especially if they used firefox or another free (freedom) browser as a base. Maybe it would force others to fill the gaps.
    In fact in my perfect world they'd just code a friggin good xhtml/css engine, make binding for x languages, and provide it for free to every browser maker or whatever... Seriously, I know it won't happen, but it would be such a step forward for the web in general.
    Choice is good, competition is good, but not in this particular area. You'd still be able to chose between a lot a browser, but their rendering would be consistent.

    • Formatting could go in css, data in the html (or links to it anyway) and page layout in a third document (lss?). Are there good reasons why this is a bad idea?

      It's a bad idea because the "page layout" would only be useful for one audience, probably sighted users. The blind using screenreaders and those using semantic markup processing tools would not be able to use the page. The current situation is good: one file with semantically meaningful data, and a choice of different CSS stylesheets that could be

        • Not to be insensitive, as I'm all for making things available to all (don't use Flash, etc.), but how many of your visitors are actually blind?

          The ADA and similar laws in other countries require many groups by law to make their content accessible to people with disabilities regardless of how many blind users visit in practise.

    • I can set my page layout using css and html divs but this results in the styling being in the css sheet, the data in the html and the layout sort of strewn between the two with the result that there is no one document I can look at which would give me a good idea whatthe page will actually look like.

      I use 4 different web browsers depending on where I am and what I am doing. Very few sites render on all 4 of them, mainly because people assume the client is running on a graphical desktop with a large dis

    • If you're using Firefox look at this very page and you'll see why HTML/CSS is divided the way it is. Start by turning off the CSS and you'll see that all the links and text show up neatly and cleanyly formated. It's not PRETTY, but all of the information on the page is there and fairly readable too. What you're looking at is the RAW HTML. The Div tags keep groups of meaningful items together rather than just using P tags as fillers.

      The other effect of proper Divs are AJAX related. That's what allows

    • Troll??

      Stick the CSS in a file and use it as your browser's custom CSS file. (hint: ad-free slashdot..) And actually, while we're here, let's refactor a bit:

      div#advertisement-title, div#advertisement-content {
      display: none;
      }

      div.ad1, div.ad2, div.ad3, div.ad4, div.ad5, div.ad6, div.ad7 {
      display: none;
      }

All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2009 Geeknet, Inc.