Hacker News new | past | comments | ask | show | jobs | submit login

You could look at the html source of csszengarden. I'm guessing it uses a bit less markup and is a bit more readable than an equivalent table based layout.

CssZenGarden also shows that refactoring a CSS-driven site is easier since you can do it without changing your templates.




To be so CSS-styleable, CSS Zen Garden uses multiple layers of DIV in DIV in DIV all over the place. Hardly better than table. Also this gem:

      <div id="extraDiv1"><span></span></div><div id="extraDiv2"><span></span></div><div id="extraDiv3"><span></span></div>
      <div id="extraDiv4"><span></span></div><div id="extraDiv5"><span></span></div><div id="extraDiv6"><span></span></div>


> CssZenGarden also shows that refactoring a CSS-driven site is easier since you can do it without changing your templates.

In my experience, this just doesn't happen in the real world.


That's not true. One of the products my team has built is a "white-label" syndication system for our content. We built that driven by CSS because it's the only way to drastically change the look and feel without touching the JSPs. We currently have at least 30 or so different looks for the same outputted HTML. As long as you attach classes/IDs everywhere and do it intelligently you can do all sorts of funky overrides (learn selectors!) to change the way the pages render and seriously never touch the HTML.

You can't radically change the flow of the pages but that's not the point.

The other area where CSS driven design makes things easier is debugging or experimenting with the look and feel of the page using Firebug. It's alot easier if all of your positioning and layout is set via IDs and CSS classes because I can go in and modify properties, add properties, etc. without needing to change CSS files or edit the document inline (it's much easier to modify CSS than inline style settings). Tables make this harder to do because tables are a pain in CSS with regard to which elements take specific CSS elements.

I'm not a CSS zealot but once you learn CSS properly (and it seriously doesn't take much time if you just focus on it a bit and find someone good to mentor with a bit) it makes things so much easier, especially if you're using the same generated code across different sites requiring different look and feels.


> learn selectors!

The grand majority of those selectors are not available in IE6, which most of us still have to support, so this is a non-starter. Nobody is arguing that we wouldn't be much better off with better CSS support. The argument is that with CSS support as it is now, most non-trivial changes to a sites design are nigh on impossible without changing the markup.

> You can't radically change the flow of the pages but that's not the point.

You know, sometimes it is.

> once you learn CSS properly

Can we quit with the "you probably don't know CSS" schtick?


That's different, though. You built your site with the intention of supporting multiple layouts/L&F. He's talking about refactoring a site designed one way to be laid out a different way without changing the content at all, without prior knowledge of the future layout that would be used.


I'm actually refactoring our marketing site, and most of the the work is done in CSS stylesheets. I sometime edit the markup to change classes or add the occasional <div>.

What I gain from CSS is that I can easily play with the layout and get a feel of what works best.

I also code by hand. I guess table-base layout would be easier to experiment with using a wysiwyg editor.


> you can do it without changing your templates.

...

> I sometime edit the markup to change classes or add the occasional <div>.

Case in point.

> I guess table-base layout would be easier to experiment with using a wysiwyg editor.

Christ on a cracker, if a person is using a wysiwyg, they shouldn't even be in this discussion.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: