Forums: Front End:

I wanted to get some peeps perspectives around how you design for tableless deployment? To be honest, I don't. Not because I dont want to, but because I havent quite connected the dots, thats why Im hoping to gain insight from ya'll

I still design and build in the following fashion:
1) design spectacular composite in potatoshop
2) from photoshop, go to fireworks and slice and dice - export to html
3) bring the sliced up stuff into dreamweaver and clean up the code, etc

So how in the world do you design with a tableless (CSS) deployment in mind? Does it restrict your thoughts when you are creating the layout in photoshop from the start?

I appreciate the insights!

I usually start with a photoshop layout as well, but instead of slice and dice, i just recreate it in xhtml/css and compare as i go.

most of the table-type functionality that you're using you can recreate using divs and lists.

I'm going to move this to frontend, most of the css skillaz hang there.Like Herr Riddle I too start with p'shop, so I know what will look good & so I can calculate pixel values easily.

I start in Photoshop, always (though on a few rare occasions I start in CSS and build the structure, then figure out a more refined look afterwards). I've never ever used the slice features in Fireworks, Photoshop, whatever. I don't trust them, and with a CSS layout you end up with a lot fewer images (usually). Plus with a CSS layout you're usually not as concerned with turning every square inch of the design into an image to use, so you pick certain parts to export and for me that's easier to just use the marquee tool for...

Very rarely does what's possible in CSS dictate what the Photoshop design looks like. Basically anything you can design can be created via CSS (with a few exceptions for shitty IE6).

I've found that CSS development is more of a stepped-process than table-based development. With tables, you cut up an image, stick it in that table cell, and you're done. With CSS, you first spend time creating and positioning blocks of content before you ever make them look a certain way. So for awhile, a CSS based layout might look like really generic content that just happens to line up the way you want it to.

It's definitely a shift in thinking to go from the table way of doing things, to the CSS way. I remember when I was forcing myself to learn CSS, it was really hard for like the first two weeks and then it totally clicked.

Your first instinct will be to use like a thousand divs all nested together to create what is basically a table without the table. But you'll get past that and into really lean code.

I learned totally through trial and error, so I'm not sure what great teaching advice I can give. The best way to learn is to find sites you like, view their source and check out their style sheets and the page markup. Pick them apart and figure out how they did what they did.

It's all about blocks of content, and layers of content - rather than just a flat grid of flattened content like with a table.

Jerkstore explained that all very well .... what he said.

if you just dig into learning css, bit by bit it will all come together. learning how to control floats is a big part of it.

if you want to jumpstart your process maybe find a site that is done in all css, download the whole thing and swap out all the graphics. that will give you a really good feeling for how it all works.

here's a good resource that i use all the time ...
w3schools.com/css/default.asp

once you get that all under your belt ... look into "reset" style sheets, they'll save you a lot of hassle regarding browser variation

and once you really take off with it, try this on for size:
code.google.com/p/blueprintcss/

i'm just learning it now ... it's a css framework ... pretty well thought out with regard to multiple column layout and font issues ... keeping a common baseline between columns. (read the comments on that page, there's valuable info there)

I'm finding the transition from tables to CSS to be difficult, frustrating and unpleasant. I feel like I've traveled back in time to the Land Before WYSIWYG.

I hope it comes more naturally to you, Sir.

I can't tell you how to design, but perhaps you should start trying to make your usual designs work in XHTML/CSS, and by doing so you'll learn about how CSS works and maybe that will later on influence how you design.

I don't do XHTML much anymore, but I used to have to code up other people's PSDs. Thinking back that doesnt' make a lot of sense - designers who couldnt' even make the design work in tables let alone CSS and me who couldn't design a thing... yeah, glad I don't do that anymore :-)

MC - it is worth the effort to learn, going back from CSS to tables now would be like going from a using a PC to daubing mud on a cave wall.

what about screen readers

A lot of the issues have already been talked about.
One critical point that Jerkstore touched on that I'd like to reiterate is that it's more about blocking critical areas of content than focusing on table cells. I always develop the design in photoshop. But then I focus on the areas of content and map out the dimensions of those areas in css.

One issue to take into a account is that the various browsers will read the stylesheet differently and minute variations can royally screw up a design (ie6, in particular)...by switching to stylesheets, you're introducing yourself to a slew of issues that you're not exposed to by using the static tabular format for displaying your pages. Be prepared for a new series of frustrations...

Switching to CSS cuts down on a lot of the bloat associated with webpages as spacer gifs and table layouts are minimized. I've had forms originally designed with tables drop down to a fraction of their size, once I switched to a css formatted layout.

Again, it'll take some getting used to...but its worth it.

awesome feedback everyone!

WingNut, I plan on looking at those links this weekend and giving a few hacks at some simple designs to get my brain working with it

poliguin, can you elaborate? better yet, know of a good Mac screen reader you can suggest?

I've used css for several years in conjunction with my sites so it's really a point of now wanting to be able to make that leap and leave tables altogether...I think its just a giant mental block and I need to unlock it in my dome.

you all rock, great feedback! Feel free to offer more insights as you get them, ill post some of my questions as I start to hack with this stuff in the next few weeks

the thing I find easiest is to break the design up into component parts (header, navigation, columns, main content, footer etc) and write out the semantic HTML first...

This will give you your content which you can then go through and apply ID's and classes to, to style it up and flesh it out.

CSS - layout and style
HTML - content

Have a go at getting your head around floating elements and positioning etc as they are the area's that cause most people the most problems.

My work flow

Photoshop/illy for designs > Coda to hand code the pages and style using CSS > testing in multiple browsers


also remember, with IE7 and 6 still causing problems, conditional comments will be your friend

screen readers can utilize elements of tables a whole lot better. there is a lot of useful information that can be supplied with tables to direct vision impaired users towards the content that you just can't do with CSS based layouts. i'll see if i remembered to bookmark a site that discuses this in more detail and get back to this on monday.

whoa, that's interesting. You don't hear much about that being spoken when it comes to CSS considering the big push to be W3C compliant all the time.
It's quite surprising that CSS doesn't have"information elements" for screen readers where comment could be added specifically for screen readers to read.

Originally posted by: poliguin
screen readers can utilize elements of tables a whole lot better. there is a lot of useful information that can be supplied with tables to direct vision impaired users towards the content that you just can't do with CSS based layouts. i'll see if i remembered to bookmark a site that discuses this in more detail and get back to this on monday.

i can't speak with authority on this ... however i don't know if the above statement is true or not.

i tend to think that css solutions have a different style of solving this, perhaps by swapping out the entire css file as you would for a print specific css file.

i quickly found this reference, but i don't have time to read it right now

w3.org/TR/css3-reader/

bobby, the concept of resetting style sheets is helpful one ...

developer.yahoo.com/yui/reset/
The foundational YUI Reset CSS file removes and neutralizes the inconsistent default styling of HTML elements, creating a level playing field across A-grade browsers and providing a sound foundation upon which you can explicitly declare your intentions.

meyerweb.com/eric/thoughts/2007/05/01/reset-reloaded/
this guy's got a lot of good stuff on the subject of css

namely the summary and caption for the table are some things that you can't replicate in a css layout. there is also the support for the lang as well (while the span does support it).

not saying this should be the reason why to stay with a table based layout, just as you need to wait for regular web browsers to catch up with the w3 spec, there may need to be some wait for screen readers to take full advantage of what is there.

w3.org/TR/WCAG10-HTML-TECHS/

thanks for explaining that further, i'll have to do some more reading

just a little more follow up reading:
access-board.gov/sec508/guide/1194.22.htm#(g)

for me the pro/con of tableless layouts has to be weighed a bit. quite frankly i'm to impatient to deal with all the different hacks needed in order to get forms working properly.

there's also the problem of having a css file that is too large. yes it will get cached, but that is after the initial page load and the initial page load is the one that you want the fastest. so while you've sped up all other pages you have in effect slowed down the page you need to target the most.

kind of my take on the whole thing:
andybudd.com/archives/2004/05/an_objective_look_at_table_based_vs_css_based_design/index.php

Originally posted by: poliguin
screen readers can utilize elements of tables a whole lot better. there is a lot of useful information that can be supplied with tables to direct vision impaired users towards the content that you just can't do with CSS based layouts.

~~~~~~~~

namely the summary and caption for the table are some things that you can't replicate in a css layout. there is also the support for the lang as well (while the span does support it).

I have zero authority but I'm gonna say he's bluffing*

Firstly, table captions can be styled with no problems in CSS. (yes, IE6 needs a bit of massaging but it's do-able and I'll get to that browser later)

Secondly, table summary doesn't render in visual browsers. If it's a requirement, either add a paragraph with the summary in it or use some DOM scripting (or server-side tomfoolery) to dynamically create a paragraph with the summary's contents. Then again, a fair amount of the time, a table summary isn't needed - would only make sense if the preceding content or table's caption didn't make the table's function clear enough.)

Thirdly, tables for layout have no use of "summary", "scope", "caption", "tbody" etc unless the purpose is to drive the screenreaders insane.

*sort of like that time in wfg when Mikepol was all like "Macs are shit. I hate them." then suddenly turned around and said "Macs are good." He should have left then. Or something like the end of Eastendenders. "Macs are good." *drums*.

Originally posted by: poliguin
for me the pro/con of tableless layouts has to be weighed a bit. quite frankly i'm to impatient to deal with all the different hacks needed in order to get forms working properly.

there's also the problem of having a css file that is too large. yes it will get cached, but that is after the initial page load and the initial page load is the one that you want the fastest. so while you've sped up all other pages you have in effect slowed down the page you need to target the most.

kind of my take on the whole thing:
andybudd.com/archives/2004/05/an_objective_look_at_table_based_vs_css_based_design/index.php

To be fair, forms aren't that difficult to style using CSS. As long as you're using label, fieldset etc, there's plenty of control in CSS. Some judiscious floating and the job's almost done. Or, if you're feeling sexy, use absolute or relative positioning. Again, IE6 needs some hand-holding to stop it shitting the bed but there's documented solutions and work-arounds.

Big CSS files? Compared to nested layout tables for, say, an OSCommerce or Sharepoint site?

Plus, all the cool kids are using witchcraft and know that the real bottleneck is the number of simultaneous HTTP requests. Filesize be damned. Well, almost.

~~~~~~

Bobby, assuming you haven't fallen asleep at having to go through all my tedium, CSS Layouts aren't that hard. You just have to know the rules.

Rule 1. Learn HTML 4.01. Intimately. You will know the exactly right HTML elements to use to mark up Customer Testimonials.

For bonus points or if you're a bad, bad, sinner, pennance can be gained from having a quick look through the WC3 specs. To save you time, I'll skip to the spoilers. You will learn two things:

1. That was a waste of time. I'll never get those hours back. Damn you W3C. Fucked if I'm ever going to put those faggy "valid html/css" buttons on any websites.
2. They're not entirely consistent when it comes to these specs. Seriously, stick to the blogs and proper websites.

Rule 2. Know that the browsers aren't consistent and range from mentally retarded: IE6 and below to the quirky: form elements in Safari <3. And then get over it. Test on one browser at a time - Firefox or Webkit-based - switching to IE7 once in a while to ensure everything's still okay. Embrace conditional comments or face potential scorn and abuse from teh standardistas *scary horns* for memorizing all the CSS hacks. Finally, fire up IE6 and praise jebus that you know Rule 3.

Rule 3. Learn the browser bugs and their fixes. Position is Everything is the daddy. Also have a skim through the Web Developer's Handbook, especially the CSS Daily Reading section.

Rule 4. Wizardry

I found it easier to learn when I started off using a single layout table, say to set up a 3 column layout with header and footer and then only using good html and css for the rest of the layout and content. If I got stuck, or IE6 was starting to crush my soul, I'd work back and maybe use the old way instead - until I learned how to do it the proper way.

Btw, I hope I'm not coming across as preachy or aggressive. I had to concentrate very hard to get this written.

Almost forgot.

There's a quicker way.

Design as usual in Photoplop.

Out-source the conversion to (X)HTML/CSS.

Have a look through the files they send back.

Do this for a couple of projects (get the clients to pay for it, it feels naughtier) and you'll start thinking about html layout when in Photoplop. A couple of more projects and you'll probably have the basics worked out and can then start doing it yourself.

Sorted.