homepage Welcome to WebmasterWorld Guest from 54.198.94.76
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Become a Pro Member
Home / Forums Index / Code, Content, and Presentation / CSS
Forum Library, Charter, Moderators: not2easy

CSS Forum

    
Seeking Answers - Please, No Agenda
old_expat




msg:4346552
 8:47 am on Aug 2, 2011 (gmt 0)

Not wanting to start a debate but I really need some expert guidance.

I'm not a developer, but design and code my own small family of websites (no WYSIWYG). The sites vary from 5 pages to 600+ pages of content.

My newest planned endeavor may well be my last "large" web site (I'm 70), so I want to get it right. It will be partly experimental, but hopefully a successful mix of editorial content and affiliate pages -- every affiliate page written specifically for 1 product/link.

Previously I have designed using tables, but only for layout.

I don't nest tables, rather style with CSS, mainly p, div, span, etc.

After reading endless online debates about Tables vs. (pure) CSS, I started trying to learn the Pure CSS methods. But I kept banging my head against browser issues that, even with hacks, are actually quite a pain.

I read about the better SEO of CSS, cxontent closer to the top of the page, the quicker page load times of CSS, etc.

So I tried an experiment. That involved download one of the latest examples by a CSS guru, and wokring my way through changing designs one of my simpler sites.

It was getting pretty painful when I noticed some of what I consider contradictions. So I removed all content in both CSS and Tables layout. Removed Doctype, etc .. down to the basic code.

Typed Characters

Tables - 227
CSS - 214

Lines of code in external style sheets
Tables - 67
CSS - 72

So my questions are, for folks in my position:

1 - Is CSS really worth changing methods?
2 - Will a SE spider really see the difference?
3 - What am I not considering?

 

Paul_o_b




msg:4346561
 9:42 am on Aug 2, 2011 (gmt 0)

From experience in converting table sites into exact copies but made with CSS only I regularly see savings of about 30% on code and in quite a few cases up to a massive 80% saving.

However, it does depend on the code used and a tightly written table site that only uses tables for the main structure can be comparable in size to a css version - although I have yet to see one that is actually smaller in size.

It also depends on how the CSS/html is constructed and I still see a lot of wasted divs being used even these days. Things like wrapping a ul in a div instead of using the ul as the wrapper. Wrapping heading text in divs instead of using heading tags and so on...

You already know the benefits of CSS as you have mentioned them quite clearly so I guess the problem is more one of application and how to make CSS work for you. The problem often arises in that going from tables to css designers often immediately try to copy table concepts and end up using hacks to achieve certain features that are specific to tables. The solution is to work with CSS rather than against it and use its strengths rather than its weaknesses.

If you are copying a well constructed table layout and you make the exact same thing in CSS then there may only be a small difference in code especially if you are not using nested tables and are already using some CSS. However, the CSS version will be instantly more adaptable, accessible and maintainable than the table version just by design.

Very few people actually use tables for layout these days especially now browsers from IE8+ are all supporting the table display properties anyway. For supporting older versions I'm not averse to throwing in the odd table element for an element that is too awkward to code otherwise but to be honest I can't remember the last time I used a table other than for tabular data and I probably code 3 or 4 new templates a week for clients.

There is a steep learning curve I'm afraid though and CSS does have many rules that need to be obeyed. (Remember how long it took you to understand tables (I'm still confused by them)). As you get more proficient you learn the correct methods to use and avoid most of the hacks needed.

In the end its your choice and boils down whether you want to keep up to date with what's going on and spend a little time learning some new concepts. Or you can just go back to what you know safe in the knowledge that it will work but not quite as well as it should :)

londrum




msg:4346565
 10:01 am on Aug 2, 2011 (gmt 0)

a couple of the arguments in favour of using CSS over tables i think are just completely overblown. when people say that using tables for layout makes your site inaccessable to the blind and site impaired users, then okay. that may be true. but how many of those people actually use your site? hardly any. they might be a bit inconvenienced by it, but as long as you add all the captions and legends and cell headers, then its still perfectly usable. so i think getting rid of tables just to make it more accessable is not a good reason.

people also say that a CSS layout will display quicker than a nested table layout. that is true, but if you've only got a simple table with a few cells, then that is not a good reason either, because it will make no difference at all.

the only reason for switching that i'd pay attention to, is that a table layout will tend to look rubbish on a smaller screen, because it wont fit. whereas a CSS layout can adjust itself to fit the smaller screen. so if you are expecting a lot of mobile users for example, then i would definitely stick with CSS. but if its just a hobby site then maybe its not worth the hassle.

oh, and theres another reason too... its better for SEO if put all the relevant text near the top of the page. and sometimes its hard to do that with tables. you sometimes end up with all the navigation at the top. but if you really want to stick with tables then there are ways around that, by using the empty cell trick. and like the guy before me already said, its a lot easier to change the site design later on, if you want to have a switch around. (you want to move the reviews from the right to the bottom? takes 2 minutes with CSS, but 2 days with tables). but if you dont want to change anything, that is a non-argument too.

HelenDev




msg:4346578
 10:32 am on Aug 2, 2011 (gmt 0)

if you are expecting a lot of mobile users for example, then i would definitely stick with CSS


Mobile use (phones, tablets etc.) is only going to increase, so I would say that everyone should be thinking about how their design appears on such devices.

I don't only use my mobile phone for social or maps, often I do general browsing on it (it's surprising what kinds of questions pop into my head when I'm mooching about the house!) and if a site renders horribly I will hit the back button straightaway.

CSS is surely the better way for mobile usability.

rocknbil




msg:4346734
 4:20 pm on Aug 2, 2011 (gmt 0)

I started trying to learn the Pure CSS methods. But I kept banging my head against browser issues that, even with hacks, are actually quite a pain.


Do you validate [validator.w3.org] your pages? I cannot express how must easier this makes developing with CSS only, and my guess is that 90% of cross browser issues automagically disappear. If you have to apply hacks, look for another approach.

1 - Is CSS really worth changing methods?


As a recovered table addict, absolutely.

2 - Will a SE spider really see the difference?


Questionable, but the real effect is not so much SE's, it's devices or clients. As mentioned, mobile devices, screen readers, and especially devices that haven't even been invented yet - all will benefit from using semantic markup (next. . . )

3 - What am I not considering?


Semantics. I believe one of the most overlooked Important Things about building documents is we've forgotten what they taught us in high school for our essays, the idea of document structure (heading, introduction, subheading, paragraphs, lists, conclusion.) This is how people digest information, this is how you write essays, this is how you build documents. When you surround content with a <p>, the device reading it knows it's a paragraph. <h1>This is the page heading,</h1> which tells us what the document is about. And <table><tr><td>this is tabular data, a two dimensional set of intersecting data values.</td></tr></table>

In respect to accessibility, it's not so much that is makes it inaccessible (Javascript can do that, oh yeah) it's just that it makes a confusing journey through what can be simple content. When a screen reader encounters a table, it expects to find data in rows and columns, and takes your message out of context. Consider

<table>
<tr>
<td>This is my content and</td>
<td>New! get it while it lasts, $20 off unrelated widgets!</td></tr>
<tr><td colspan="2">now my wraparound message has my ad in the middle of it. That's not good.</td>
</tr>
</table>

Reads like this (apologies in advance if it's not entirely correct . . . )

"table data" This is my content and "table data" New! get it while it lasts, $20 off unrelated widgets! "table data" now my wraparound message has my ad in the middle of it. That's not good.

Another important reason is the basis for using CSS based layouts - separating content from markup. With tabled based layouts you have a lot of in-document markup that is not relevant to the page (CSS can do this too, look for "div-itis" here - it's the same problem as table based layout in that developers use "div" for everything when a semantic container is a far better choice.) When you use semantic markup and take away the style sheets, you should see a simple source code where each tag represents the content it contains - no <br> (or <br/>) for spacing, no &nbsp; or other visual tricks - those are managed by CSS. If you keep empty elements to a minimum (<table> for layout, <br>, <div>, <span>, these have no semantic value) Your document becomes easier to read, and affords context to the content. I have no proof, but I have a pretty strong feeling that this also affects document relevance.

This also allows you to leverage another important point, the concept of SOC (Source Ordered Content.) An item can be at the bottom of the page in display but if you want it at the top of the source code for SE's, you can position it accordingly with CSS. As we know, "what's up top" is often most important as it's rumored SE's may not consider "all" the document relevant. *

* You can apply SOC with tables too, but it takes a lot of ingenious tweaking and most often heavily nested tables to move the same content to the top.

Last is one that will hit home for most of us - once you get past the learning curve, it's far easier to maintain. A table "locks" you into a set of rows and columns. To reformat the page, you need to modify the layout table structure, which means going into every page and modifying it. With CSS, most of the time you can just tweak the CSS.

It also allows you to use the exact same content for a mobile site version - instead of developing a whole new site, if a mobile device is detected you use the same content but the CSS and images are located on a mobile subdomain. You can't really do that with this:

<table width="1100" cellpadding="0" cellspacing="0">

people also say that a CSS layout will display quicker than a nested table layout. that is true, but if you've only got a simple table with a few cells, then that is not a good reason either, because it will make no difference at all.


This was really an eye-opener for me - the concept is the browser must render from <table> to </table> before it displays. It can be a simple table but if it's socked with content, it won't render as quickly. I've seen it happen even with a single cell container table.

I am not a purist, nor an "expert," but it's a decision you just know is right when it hits you - like finding God or the first time you hook a 2 pound trout (take your pick. :-) )

old_expat




msg:4346969
 5:25 am on Aug 3, 2011 (gmt 0)

Thanks to those who provided thoughtful comments.

It also depends on how the CSS/html is constructed and I still see a lot of wasted divs being used even these days. Things like wrapping a ul in a div instead of using the ul as the wrapper. Wrapping heading text in divs instead of using heading tags and so on...

I agree and like lean fast pages, so don't overuse code. Except for some specialty 3rd party stuff, I use no javascript.

Mostly I use styled p's, styled lists -- divs only where required. All header tags are styled. But that seems to be a separate issue from Tables or CSS.


the only reason for switching that i'd pay attention to, is that a table layout will tend to look rubbish on a smaller screen, because it wont fit. whereas a CSS layout can adjust itself to fit the smaller screen.

Will a table layout designed for a small screen " .. look rubbish .. and [not] fit? Remember, tables were used on small screens for years. How different is a 640 X 480 layout from an iPhone? (480 X 320) I really wonder how successfully a CSS layout designed for large screens will ".. adjust itself to fit the smaller screen."

I just tried an experts CSS redesign of a tables site. I re-sized the browser and, you're right -- nothing changed. But who want's to browse on an iPhone with a horizontal scrollbar. I don't have an iPhone, but have read that using a horizontal scroll on a smart phone is a real pain.

For mobiles, I plan on using a completely different and scaled layout. I just can see trying to force 5 pounds of navigation and content into a 1 pound bag.


by using the empty cell trick.

Been doing that for years.

Do you validate [validator.w3.org] your pages?

Yes. I run all my sites through a validator. BTW, are you aware that the Google +1 code will not validate on the W3 machine?

Last is one that will hit home for most of us - once you get past the learning curve, it's far easier to maintain. A table "locks" you into a set of rows and columns.

I'm locked into:

1 row (colspan="3") for header
1 row of 3 colums
1 row (colspan="3") for footer

As I said in my OP, everything else is CSS.

I have a system of modularizing my sites with SSI's:

Header include - contains and top navigation, search box, logo, etc.
Footer include - contains the column 3 goodies, aforementioned "empty cell trick" side navigation, footer, footer menu, etc.

What's left on the page is the doctype, html, head, body, title, meta tags, and the content mostly styled with p elements. I even use different headers and footers for different sections of my larger sites to get some special effects with menus and simple CSS so I don't need ANY javascript.

My content can't be "reordered" with the stylesheet, but I would wager that reordering the content in a realistic manner on most pure CSS sites is not as easy as some folks claim.


This was really an eye-opener for me - the concept is the browser must render from <table> to </table> before it displays. It can be a simple table but if it's socked with content, it won't render as quickly. I've seen it happen even with a single cell container table.

I just tried an experiment:

I deleted the footer cells (including the footer tr's and td's as well as the closing "table" tag) from one page of one site and reloaded the page, flushed the cache (FF).. What was left displayed just fine. Then I tried IE9 and Chrome. Same result.

topr8




msg:4347075
 10:10 am on Aug 3, 2011 (gmt 0)

my 2 cents worth, is that most css bloat - of which there is plenty is because most people have no idea how to use cascades properly (infact they don't use them at all)

the whole point of css is the first 'c'

HelenDev




msg:4347096
 11:15 am on Aug 3, 2011 (gmt 0)

For mobiles, I plan on using a completely different and scaled layout. I just can see trying to force 5 pounds of navigation and content into a 1 pound bag


Good plan, and I'm sure this would be easier just by using a different stylesheet rather than two different versions of the html. Easier to maintain in the future anyway.

londrum




msg:4347130
 1:15 pm on Aug 3, 2011 (gmt 0)

sounds like you are happy sticking with tables. but it also sounds like you already know a load of CSS already, but cant get the layouts to work. but have you seen those sites on the web that offer ready-made CSS layouts? you can pick the number of columns, rows, headers, footers, whatever you want, and it spits out all the CSS that is compatible with all the different browsers. maybe that is an easy way to do it. try googling "css layouts"

Global Options:
 top home search open messages active posts  
 

Home / Forums Index / Code, Content, and Presentation / CSS
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved