Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×

A New Era in CSS Centric Design? 233

Posted by Cliff from the where-do-we-go-from-here dept.
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?"
This discussion has been archived. No new comments can be posted.

A New Era in CSS Centric Design? More

A New Era in CSS Centric Design?

Comments Filter:

  • Comment removed (Score:5, Insightful)

    by account_deleted ( 4530225 ) on Saturday June 10, 2006 @11:51PM (#15511535)
    Comment removed based on user account deletion

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

      by RzUpAnmsCwrds ( 262647 ) on Sunday June 11, 2006 @12:59AM (#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.

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

        by BalanceOfJudgement ( 962905 ) on Sunday June 11, 2006 @01:14AM (#15511705) Homepage
        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).

        • 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.

          Actually, table layouts were popularised because most web browsers didn't implement a style language at the time and table layo

        • because browsers can't render the table until the entire thing is downloaded

          What browsers have you been using? Every browser i've used renders tables before completing the page download.

          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.

          Sorry dude, but if you're viewing html websites that are that fat, it's not because of html (unless the web designer

          • Every browser i've used renders tables before completing the page download.

            How in the world does the browser know what to draw until the [/table] tag has been reached? The reason you see some of the page render as it is downloading is because it's drawing intermediate tables that are already completed. I'm talking about a very few poorly designed websites (and yes, I agree that's because of the developer, not the HTML), because over the years people have learned NOT to jam 200kb of content into one table

        • 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.

          No, it's because back then (when Netscape 3 came out), tables were the only way to do it. CSS wasn't implemented in any browsers for a while after that, and the early CSS implementations were pretty buggy.

      • Why CSS xor Tables? (Score:3, Interesting)

        by G27 Radio ( 78394 )
        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
        • Comment removed based on user account deletion
          • Doesn't anyone question the twisted logic of the accessibility fascists? Isn't it the responsibility of the screen-reader manufacturers and text browsers to come up with something that can handle table-based layouts rather than insisit the vast majority of websites be re-engineered to cater for a tiny minority with inadequate browsesrs? Note, I'm not aiming here at genuine accessibility issues like colour contrasts etc., just the tired CSS layout crap. CSS layout is and always was ****ed. That's why tables
            • What've heard is the most popular screenreaders hook into Internet Explorer, understand the page DOM, and don't have too much trouble with table-based layouts (which are all over the Internet). I think the whole lynx thing is largely a slashdot myth put forward by Unix caveman types that hate all technology invented after 1994.

        • 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 couple tables to get things the way I wanted them. 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 how long have you been doing table layouts? And you expect to catch up to that level of experi

          • But how long have you been doing table layouts? And you expect to catch up to that level of experience with CSS in a couple of days?

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

            Where would you be if you had stuck with the first programming language you ever learnt instead of facing the learning curve and accepting that in the beginning, some things are going to be more difficult until you get a bit of experience in the new language?

            It's called priorities. There are a whole bunch of more intere

            • Re:Why CSS xor Tables? (Score:3, Insightful)

              by jZnat ( 793348 ) *

              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

        • 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
          • Ever heard of templates? They make a lot of the CSS redesign issues redundant.
            • Templates may be part of MVC, but if you ignore the fact that the model is the XHTML and the view is the CSS, you're already defeating the purpose of using MVC in a web application by not even using it.

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

        by Dracos ( 107777 ) on Sunday June 11, 2006 @03: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.

        • 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.

          Out of curiosity: what browser does that work on? I fooled with it, and I couldn't get it to work without declaring the height of the body explicitly on either konqueror or firefox. I may not be doing it correctly either, I suppose. Do you have an example, perchance?

          • Dracos is (sort-of) wrong. From the specification [w3.org]:

            If the height of the containing block is not specified explicitly (i.e., it depends on content height), and this element is not absolutely positioned, the value computes to 'auto'. A percentage height on the root element is relative to the initial containing block

            The special case for the root element was undefined in previous specifications [w3.org], which is why Internet Explorer doesn't get it right.

            So basically, Dracos' technique should work, but only i

        • iirc, its possible to have equal length columns using a parent div:

          <div style='height:auto;'>
              <div style='margin-bottom:0px;'>
                $text1
              </div>
              <div style='margin-bottom:0px;'>
                $text2
              </div>
              <div style='margin-bottom:0px;'>
                $text3
              </div>
          </div>

        • 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.

          Explain to me how

          <table><tr><td></td></tr></table>

          is "bloat", trying to get CSS to do the same thing ends up with 4x the code.. THAT's bloat.

          what's the actual advantage to the CSS layout? not enough gain to justify it's bloat/comp

          • Long before there were web designers churning out pages of advertising, there were content providers whose needs are significantly different. My experience as a web developer consists of over a decade of devising ways of presenting procedure manuals, FAQs, help pages, reports, and similar information on the web. My goal is to do this in a way that makes revisions and additions simple. Ideally, so simple that the content developers can do the maintenance and extensions on their own, without needing to study

            • Surgeons and CEOs can and will understand the use of <H1-6>, <strong> <div class="sidebar">, and so on.

              Really? So you let them edit raw html? I once had to setup a website of a university department, where each researcher had to write a page about ongoing research. No way I could get them to do that, so I ended up letting them use frontpage (at least it's better than Word for this purpose), and then hand-editing it myself after filtering out the crap that Frontpage produces.

          • You write a single CSS file (which will get cached on the user agent's end). You have multiple pages on your site. You've just saved an asswad of bandwidth if you get a bunch of users.

            Using CSS, you can cut down the size of the markup pages to negligible, and a one-time download of a CSS file isn't bad either. Downloading a crapload of useless tables that don't even show tabular content (y'know, more than one column and one row, each column and row is related to each other somehow, a "table" of "data" if
            • CSS-P only has a significant filesize savings over tables if you were using FONT tags, which most people stopped using 8 years ago with "version 4" browsers. Given comparable layouts, you will have nearly as many DIV tags as TABLE TR TD tags -- if not more. It's a wash, there won't be any big difference.
        • You are the face of CSS zealots in this thread, my man.

          I use CSS for layouts on a daily basis, but just about anything you said here is wrong.

          Tables are not bloat, a three cell table is not larger as HTML code than the outer set of 4-5 divs required to fake it qith faux columns, not to say the added weight of the extra images required for faux columns which is not the case with tables (especially if you want simply solid color columns).

          About tables being "primitive", I guess you're too sophisticated to expa

      • 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

        • What you need, then are web designers, not graphics designers. As a programmer, you should not be stuck with the task of implementing a design. That is not your job. It should be implemented, CSS and all, for you. And you just plug it into your application/site. Yes, that is ideal. But I can assure you it is attainable. I currently work in such an environment.

          You are being completely unrealistic. If he can mog together a layout with a few tables, I'm sure management would prefer that to hiring additional p

          • You are being completely unrealistic. If he can mog together a layout with a few tables, I'm sure management would prefer that to hiring additional people or contractors.

            Or just fire the graphics designer and hire a web designer. Who you fire/hire certinainly depends on the situation, of course, but a good web designer will ultimately come up with a better design than either a graphics designer or a programmer. Not only that, a good CSS based layout is MUCH more flexible than the table design. When manage

      • 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'm a web developer too, and I think the exact opposite. Take a look in any bookshop lately. How many books are teaching table layouts these days? How many books are teaching CSS layouts these days? I think it's clear which layout method is preferred on an industry-wide basis these days, regardless of what individual developers like you or I think.

        The main reason table

        • I'm a web developer too, and I think the exact opposite. Take a look in any bookshop lately. How many books are teaching table layouts these days? How many books are teaching CSS layouts these days?

          But that's the great thing: you don't need a damn book to learn how to use tables.

          You'll get no arguments from me about the merits of CSS, but one thing I don't like about it is that it's a lot harder to pick up, especially for layout. Now sure, if you do web stuff for a living - big deal. You learn what you gott

          • you don't need a damn book to learn how to use tables.

            That's funny, because if I remember correctly, a watershed moment for the uptake of table layouts was when the technique was included in one particular book. So yes, when the industry wasn't swamped with loads of developers who knew table layouts, you did indeed "need a damn book to learn how to use tables". There's nothing that makes CSS layouts intrinsically more difficult than table layouts, it's the fact that table layouts came first that mak

        • About six months ago, when I decided I really needed to change my layouts to a more modern CSS design, I bought and read a book about CSS design.

          It told me there were three choices:

          * A table-only based layout;
          * A CSS+Table-based layout; and
          * Pure CSS

          It also said that pure CSS was more complex and handling browser varations were more difficult. It looked to me that if I wanted a table with three columns, all of them with background colors filled to the bottom, I would have to create a fixed-size layout, kno
      • I haven't used tables for something that wasn't a table of information at all for about 5 years now and haven't had any problems translating anything the designers throw at me perfectly into css'd xhtml. "Only a bad workman blames his tools."
      • Web Designing is my job, and every web site I create, I do in a pure CSS layout.

        Doing your first site in 100% css is HARD. There is just no other way around it. You are going to spend days trying to figure even the most simple things out, and there are going to be temptations to revert back to the easy (not better) table layout. Some will succumb, and some will soldier on and succeed.

        Table-based layouts are wrong. Tables were designed to show tabular data. By using them for layout, you are perverting t

        • Doing your first site in 100% css is HARD. There is just no other way around it. You are going to spend days trying to figure even the most simple things out, and there are going to be temptations to revert back to the easy (not better) table layout. Some will succumb, and some will soldier on and succeed.

          Ohhh yeah. It took me two months to figure out my first 100% CSS website [charleshagenah.com] (it's kinda wonky in anything other than IE... bare with me, it's one of my first). I had so many restrictions: must fit verti

    • 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
      • Comment removed based on user account deletion

        • 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

          • For the shell scripts thing, use "white-space: pre-wrap;". Most of your other problems have already been solved or probably will be in CSS 2.1 and CSS 3.
          • Column splitting is present in CSS 3... possibly others, I just skimmed through a few pages of the proposal and decided to stop there because i'd feel spoiled for the next 5 years. Yeah i know, it's not very helpful to do real work but still.

            And of course you realize that XSLT is not in any way a replacement to CSS... When using XSLT to do web stuff you generate HTML with xslt, and style it with CSS.
            At least a cool thing about CSS is that it can remove a lot of complexity in XSLT sheets since most of th

    • 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

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

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

  • rounded corners (Score:3, Funny)

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

  • Simple answer (Score:4, Informative)

    by kennygraham ( 894697 ) on Sunday June 11, 2006 @12:47AM (#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)

  • ok.... (Score:2, Funny)

    by B00yah ( 213676 )
    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 (Score:2)

    by bahwi ( 43111 )
    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 @09: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.

    • "A good carpenter doesn't blame his tools" (Score:4, Insightful)

      by Assaulted_Peanut ( 742517 ) on Sunday June 11, 2006 @03:48AM (#15511999) Homepage
      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 get designs from print people that require using absolute. I think part of the process of turning a design in to a template is for better or worse doing what the designer intended. So I would say fully relative positioned "bullerproof" layouts are the ideal, but in practice aren't always possible.
      • 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
  • Since we're talking about CSS anyway, maybe somebody could explain to me what happens in IE with the following CSS:

    div#left {width: 4em; height: 1.5em; float: left;}
    div#right {width: auto; height: 1.5em;}
    IE renders them next to each other and on the same line (as intended), but there's a ~4 pixel gap between these two boxes. I checked margins and borders, that's not the problem. To fix it, I placed these two into another div with the background, but that for some reason seems to screw up Ope
  • I'd post this on the "omg ponies /. redesign" thread, but it's closed.

    What can you do if you don't much like /.'s new CSS? I mean, it's okay for the most part, like a new haircut. It doesn't turn Helen Hunt into Jessica Alba. But the part that I don't think I can live with long term is the switch to Verdana from Times. Say what you like about Times -- and the most wounding thing is perhaps "it was just the default. So that font is called 'Times', eh?" -- it's a remarkable print typeface and I got used to se
    • Do it yourself then. I'm not huge about the new redesign, but I was about one of the contestants, so I simply use the Stylish plugin to apply that stylesheet to the page. That's what User CSS is for. Stop bitching and fix it yourself :)
      • I knew I'd probably have to roll my own. I was curious as to the mechanisms available for overriding it. I'll have to look into browser support... (Pity you can't attach a custom css to your profile, then it would go wherever you go, with no browser support required, eh.) Speaking of bitching - where *is* the "I hate the new CSS" thread? I can't be the only one.

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

    by HawkingMattress ( 588824 ) on Sunday June 11, 2006 @04: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.

Slashdot Top Deals

"If it ain't broke, don't fix it." - Bert Lantz

Close