Hacker News Reader

Comment by btipling | Hacker News Reader

Well I meant to downvote and accidentally upvoted but anyway if you're using a table then you are probably not expecting to do anything dynamic via JavaScript on it since it's not a collection of block elements, but table-cells. There's a lot you can not do with table-cells. Also, it's semantically incorrect and really takes like maybe ten minutes of reading a how to guide as to how to figure out how to do it with real css. Also attempting to control dynamic table cell widths is far more painful than anything you might ever want to accomplish with CSS. Finally, yes sometimes you have to reread the guide when you want to do it again. So

1) It doesn't work (with JavaScript and fluid, dynamic cell widths) 2) It's actually not that simple. 3) It's only cross-browser if you have a lot of reset CSS and do nothing fancy. 4) It's reliably problematic.

View on HN

"Semantically incorrect"

A "table" is an abstract concept with certain properties. If a layout shares those properties, it might as well be a table. If it quacks like a duck..

> takes like maybe ten minutes of reading a how to guide as to how to figure out how to do it with real css.

Sorry but I'm skeptical.

If you could prove this by sharing a paragraph or two (should be all it takes, right?) teaching how to use CSS to build reliable layouts I would be grateful.

Me too.

I suspect what he meant was that you can come up with a simple layout with 10 minutes of reading, but that's a strawman. The real problem is that it's extremely easy to rapidly make a once-simple layout a nightmare to maintain or debug.

With bitter experience I've realized I need to be extremely disciplined when I use the CSS directives margin, padding, and float. Everything else is relatively straightforward, with localized implications. But anytime you mess with the box model itself you really need to think about the big picture of your page's layout.

Step one is to abandon your initial requirements and rewrite ones that are compatible with robustly portable CSS.

After that I think the quoted statement works.

Can you gives some examples of requirements that must be abandoned?

There are many CSS books that give concrete examples of various layout types that work in all browsers.

Dan Cederholm wrote one of the best: http://simplebits.com/publications/bulletproof/

Thank you, this look like a good resource. :)

However, a book is a very different investment from "maybe ten minutes of reading a how to guide".

If you want that, see this:

http://www.maxdesign.com.au/articles/css-layouts/

It was written in 2002. Cross-browser layouts are a "solved problem" :)

"There's a lot you can not do with table-cells."

Could you give a few examples?

"it's semantically incorrect"

So is "float".

"So is "float"."

No, 'float' is a property - '<table>' or '<td>' are elements. Float has nothing to do with semantics, it's purely presentational.

By marking up content semantically - it's possible to do interesting things with your marked-up content. For instance, content can be scraped more easily and a screen-reader can use elements to make inferences about the make-up of a page's contents. xHTML can be translated to other forms of XML using XSLT - and HTML content can be shared between desktop and mobile devices with just a stylesheet change. Liquid layouts can be utilised and JS can be used to move content dynamically.

There are a huge number of reasons for marking content semantically.

Using a table is a bad solution for anything other than tabular data.

> HTML content can be shared between desktop and mobile devices with just a stylesheet change.

Have you been able to pull this off in most cases?

In my experience, the mobile version of a site requires changes to the HTML, such as turning links into buttons and removing content.

It depends how complex your markup is.

I've found that a site that's been developed for the desktop can usually be made much more accessible by offering a different stylesheet. I.e. it's better than the alternative of doing nothing ;)

But I agree - it's not always as straightforward as you might hope would be. Sometimes it makes sense to serve different markup.

You can't resize them easily with JavaScript, you can't move them, you can't hide them and then show them again. You can maybe change the contents and add or remove a class, but because there's so little you can do to tablecells, good luck doing something other than changing background color. Since you're using a table cell for your overall design, heh. Not good.

> [it] really takes like maybe ten minutes of reading a how to guide as to how to figure out how to do it with real css.

This is the crucial point! CSS isn't remotely difficult.

Please demonstrate it then. I hear many more people saying CSS isn't difficult than showing it.

To be sure, I'm talking about CSS for layout here, not styling. I find CSS for styling to be relatively straightforward.

Reply on news.ycombinator.com