Forum Moderators: open
When Dreamweaver gave me the option of tables, DIVs or layers, I thought all three displayed pages in much the same way so you chose the method that worked best for you.
Well, I come from the world of print page layout (began using PageMaker 1.1 in 1986) so I found using layers the most natural for me -- just like designing a print page. Except now I'm learning that my layers-heavy pages look crummy when viewed at anything other than Medium text size in the accursed IE.
I've always found tables hellish to use -- talk about pouring a bucket of ice water on your ardor. And DIVs look just as daunting. Although many people are talking about DIVs and CSS as the next coming, there are just as many cautionary voices -- almost all pointing at that accursed browser, owned by the world's weathiest man, which messes with CSS. ($46 billion and counting and we can't get a freaking browser that works!)
One of my layers-heavy sites I need to update two or three times a week. Often I'll need to change the design -- add three or four photos, some new text and so on. Adding a layer or three, this is easy. Is it just as easy using DIVs and tables? Or do you need to create a template design and not waver from that?
If you want to comment on this specific question, or the broader issue I'm concerned about, I'd be very grateful.
Print is designed for a fixed piece of paper and no variation - whereas html was intentionally created to separate semantic meaning from visual appearance, and that appearance can vary all over the place. Attempts to lock down a web page into a similar appearance across all possible visual user agents (browsers) are usually way too complex and ignore the major advantages that web pages offer in accomodating a wide range of end user needs.
LAYERS:
There is no such thing in the HTML standard. For a brief moment Netscape 4 had a proprietary <layer> tag - but it never went any where. So this is a confusing word introduced by Macromedia for Dreamweaver. I haven't used DW this century, but I believe they use the word "layer" to indicate a div with the possiblity of some javascript - DTHML in other words.
TABLES:
Before browser support for CSS-P became somewhat dependable, the <table> tag was the only real resort for holding a complex layout together. The ideal is that tables are used only to hold "tabular" data - and maybe some day we'll get there. For now, I still use tables to establish the basic framework for most of my layouts.
Tables can seem mystifying at first, but put in one afternnon with a test page, playing with the various tags and attributes (have border="1" so you can see what's happening) and the basics start to come clear.
DIVS:
Divs are a bit tougher to master than tables, but once you do they're quite intuitive. The big deal is all the browser bugs that still make it hard to position divs and get the results you intend cross browser. But without a doubt, divs are the way forward.
YOUR PROJECT:
You should be able to set up a template that takes new content easily - filling in a set spot in the mark-up, whether that spot is in a table cell or a div. My only concern about your comments is that your current approach may be turning off visibility for previous versions of your page, but still leaving that old content in the mark-up. If that's the situation, then the file size of your pages will just keep growing and growing and growing.
We once had a site brought to us where the pages averaged over 1MB in size and we reduced them to 8KB on average. Those pages were over 100x the size they needed to be - and the website (naturally) had no dial up traffic. I have visions of that kind of nightmare if you are only doing WYSIWYG development.
[edited by: tedster at 10:07 pm (utc) on April 24, 2005]
I believe they use the word "layer" to indicate a div with the possiblity of some javascript - DTHML in other words.
My understanding is that MM's "layers" are <div>s that are absolutely positioned on the page. This would explain why resizing the text causes problems with your (pab1953) layout. Resizing text usually causes <div>s to get taller, but when those divs are all placed via position:absolute, the location of other elements does not change with the alteration of a given <div>s height. Therefor these "layers" will overlap one another and destroy the finely-constructed layout.
Like tedster, I have not used DW as a design tool for quite some time, but if the program now makes a distinction between "layers" and "divs," I would have to guess that they are finally adding support for non-absolute positioning schemes, and that this is what the "divs" option provides.
If so, I strongly recommend going that route. You'll learn more about CSS that way, and at the same time wind up with far more flexible pages. IMO, absolute positioning has it's uses, even in a fluid layout, but it requires far too much control - control we simply cannot reasonably expect to maintain on the web - in order to ensure it's stability.
My advice would be to use the "divs" option and try to spend some time tooling around in "Code View" to get a sense for what CSS DW is using to accomplish your needs. Then spend some time tooling around in the CSS Forum [webmasterworld.com] to get a sense for what that CSS means.
cEM
Ted: No, my pages aren't bloated. But the home page, in particuar, is dynamic and requires adding and substacting content holders as situations warrant.
Create: Critics of CSS (really critics of IE) say that until MS gets IE CSS compliant, CSS-heavy sites risk displaying unpredictably.
Critics of CSS (really critics of IE) say that until MS gets IE CSS compliant, CSS-heavy sites risk displaying unpredictably.
In my experience, this is not true. What is true is that IE's patchy compliance requires extra learning in order to work around those browser differences. But it's worth saying that in almost every case, there is a way to get IE and other browsers displaying the same without resorting to fickle hacks and loop-de-loop coding.
But yes, it's certainly not as simple as one would like for it to be.
The real problem is that IE misinterprets some pretty important CSS, resulting in inconsistent display between browsers unless worked around. IE5.x and younger use the "wrong" box model; fixed background-attachment works only on the body element; float widths are wrongly calculated in certain (and, as it happens, very common) circumstances; floats are enclosed whether you want them to be or not. But again, most of this is workaround-able. And when the day comes that IE really is better at CSS support, those who use it now will have a simple adjustment to make from working around IE's bugs to not having to.
cEM
without resorting to fickle hacks and loop-de-loop coding
LOL. I once called it "code yoga". If you are the only one working on the code, then I can see learning all the required asanas and positions. But if you are working with a team of any size, it becomes quite impractical in my experience, and mostly, as cEM points out, because of IE's misinterpretations of the standards.
I still like to use tables instead of divs (of course, layers are now gone) because of their reliability: I can't think of any browser that mishandles table code.
The problem with IE and CSS (as mentioned) is its confusion with padding and the document object model. Even their own documentation differs from source to source on how that browser handles padding/margins, especially when nested.
If you really need to do something fancy with the page, like overlap content, dynamically expose hidden elements, or have things moving around on the page, then you're looking at DIVs, which are quite similar to the layers mechanism found in PageMaker and Photoshop and others.
Tables don't float, but they do keep your layout together no matter what the font size or browser capability. You can count on them.
So I recommend using tables for page layout (draw a simple outline of the sections on-page and you have your table layout) and use DIVs for the slippy-slidy stuff. That way your base content will always be accessible and predictable and you'll only have to fuss with the tricky things.
(Here's a simple, quick table example to give you hope:)
__________¦_1_¦_2__¦¦___3____¦<table border=1><tr align="center"><td>1</td><td>2</td></tr><tr align="center"><td colspan=2>3</td></tr></table>I'm not a fan of WYSIWYG editors, as (a) they usually use too much code and (b) they do not offer a very good lesson in what the heck is going on, so you come to rely on them to do what you want instead of being able to fix things when they go awry. Try typing the above table code into a text editor like Notepad (not a word processor like Word) and open the saved file in your browser. Then, if you feel inspired, check out the options at the W3C [w3c.org]. It's sometimes a little geeky, but scroll down to section 11.2.1 for the very few options available, then try them in your test table to see what they do. Gaaaah! Must ... stop ... typing ...
Have fun!
As far as WYSIWYG editors go, some are ok, but I code by hand, in source view, in Dreamweaver...so :P
I should confess that before HTML came out, I worked regularly with various typsetting machines (Linotype, Compugraphic, etc.), so I was already writing similar code for print while experimenting with SGML on the 'net ... so I probably think it's easier than it really is for a newbie.
= :o)
Strict Html may be the future, but for now I'll work with tables too.
