[nycphp-talk] And the HTML CSS guru is....
ken at secdat.com
Fri Jan 12 09:43:46 EST 2007
Rob Marscher wrote:
> Usually if you avoid using tables for layout, you can drastically
> change the layout of your page without altering the html. If you keep
> to the indended use of the html tags, then the page should look
> somewhat ok if you turn off your styles altogether (which is maybe how
> it would look for someone using Netscape 4 or some other ancient
> browser). You can also supply different layouts for other uses like
> printing or for mobile devices without changing the html. I think
> screen readers for visually impaired people read table html elements
> expecting it to be some type of data. I can't say that from
> experience though. So if you don't really care about those things,
> I'm not sure there's anything else wrong with using tables for layout
> except you'll have young "know-it-alls" who just got out of their html
> development class saying that you have really bad code (happened to me
> before). You also can't put those cool xhtml/css compliant badges on
> your page ;)
Rob, this is actually one of the more persuasive arguments I've heard
for the DIV/CSS model. You hear a lot of dogma about CSS, which has led
me to this conclusion:
CSS is to HTML Tables as Java is to PHP
In other words, one of them was designed by a committee of thought
police, while the other lets me get my job done.
Another argument I would have put against your reasoning is that I don't
drastically change my layout, once its delivered to the customer, that's
it. However, your post led me to an Aha! moment, I do in fact change
layout drastically a lot, during *development*. Until it is finalized
we are forever tweaking it. This makes it worthwhile to experiment a
little with CSS during layout of specialized data screens, I'll let you
know how it turns out.
So what is the proper use of HTML Tables? A form of INPUTs, with
caption on the left and inputs on the right, are table anointed for this
task, or Divs looking to do this one also?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 261 bytes
Desc: not available
More information about the talk