Is there a <div> and <table> equivalence?

  RWest 13:51 19 Jan 08
Locked

I'm used to tables, and like them - the rowspan> and colspan> features and invaluable is getting neat useful layouts.

I've examined div> blocks, and the way CSS is (supposed to) permit fine adjustments. But I can't find any clear statement of how the blocks are made to fit together in the way you want. Is there some way to translate table> tr> td> and the span commands into div> /div> blocks? Without using 'deprecated' left and right etc commands?

  CodeMeister 15:02 20 Jan 08

I think that the generally accepted rule is that <table> tags should only be used for displaying tabular data and should most definitely not be used to define the structure of your pages.

Essentially you need to nest your <div> tags and position child <div>s within parent <div>s by using CSS (e.g. <div style="float:left">) which isn't deprecated.

  RWest 20:04 20 Jan 08

[1] I take it a 'child' <div> just means a <viv> </div> block withing another?

[2] then the CSS makes one of the 'child' blocks move left - possibly 'float left' means as far left as possible? Pretty much the same as <tr> </tr> which will automatically go left

[3] the only difference I can see really is that if the view window is narrowed, a <div> </div> block may float down, whereas a table wil probably squeeze up more narrowly.

  barryoneoff.co.uk 22:40 20 Jan 08

on whether you size by percentages or pixels, pixels would would simply produce a scroll bar if the screen was smaller than the layout size.

  RWest 00:21 22 Jan 08

yes, I agree, percentages look better, especially as there is now an ever increaing number of large screen sizes available & you want max felxibility.

I think what I'm wondering is whether the arguments for divs are in fact conclusive. It's true that, with tables, the browser has to work out what'd going and and where to put everything. But surely this is just as true with divs?

Part of the problem is the accounts of CSS never define what is meant by 'fixed', 'absolute' and 'floating' - or at least not in my books. Does fixed stay where it is on screen, or is it fixed along wwith the screen if it scrolls?

Kemistri produced a list of advantages of divs, and one was that a 'broken' table causes more problem than broken divs. I ahven't tested this but surely a missing </tr> say and a missing </div> both make the thing go badly askew; and anyway either errors is detectable by a validator.

Also the point of my query really is that if you have some properly-defined table, the identical effect, but with more precise control, ought to be achievable with divs; again I've never seen any ccnsideration of this, tho it seems very obvious.

  ElanMan 13:57 22 Jan 08

To try and answer the definitions of different positioning.
Placing an element with position:fixed places that element in relation to the browser window.
eg. div#fixed (position:fixed;top:50px;left:50px;} would position that div 50 pixels from the left and 50 pixels from the top of the browser window. It won't move even if you scroll the page.

Placing an element with position:absolute places that element in relation to it's nearest containing block that is also positioned.

Both of these remove the positioned element from the flow of the page.Other elements don't know they're there and can be obscured by them. The z-index can help with this.

Floating an element also removes it from the flow of the page but inline elements do flow around it meaning they won't be obscured.

Using css via separate/external style sheets has lots of advantages.
The main ones being that site-wide amendments can be acheived by changing perhaps one line of code in the stylesheet as opposed to altering every page and also that the browser caches the stylesheet the first time it sees it meaning that subsequent pages that reference that stylesheet load much quicker.

Hope that helps

  Kemistri 15:05 22 Jan 08

"Kemistri produced a list of advantages of divs, and one was that a 'broken' table causes more problem than broken divs."

I think you may have misquoted me and misunderstood me.

  RWest 15:07 25 Jan 08

Thanks all for your replies.

Maybe I should say what I'm looking for. My previous site still works ten years later. I want my new site to be robust, but to take advantage of the new more precise layout and tpyefaces, where there are nicely defined easily read chunks.

A standard (in e.g. Newspaper websites) seems to be 5 columns - when I say 5 columns I include banners which straddle all five, portrait-style pictures which fit upright with blocks of text around them, search engines and windows going across several, etc.

I take it <DIV> blocks can move around, and <TABLE> is best where there's a definite link which has to be kept. (E.g. <DIV> blocks are fine for unconnected newspaper items - a pop star item doesn't need to be next to some political comment.)

I've examined newspaper sites' HTML, but they are so choked with javascript it's hard to see what's what.

One problem is screen pixel sizes. iPhone has publicity stuff showing 5 col newspaper layout. This may be specially programmed to respond to screen size, as the default seems to be 1024x768. But there are of course now much larger screens; it seems wasteful to have wide strips of bare screen at each side.

Is there some easy way to make one bit of code fit all these?

Another problem is: I'd like a fixed sidebar to help navigation. This may take up too much of a small screen; I'm not sure.

I can't make sense of the philosophy of <DIV>s; they seem to be a collection of bodges. Is there some simple way of implementing them? E.g. it may be that if they all float left, they will fit; I just don't know and want a minimum effort solution, if possible!

[Another issue (which seems insoluble) I raised and e.g. Kemistri replied; it would be nice to able to change the entire site, for example to reversed-out text, with one click; but since each page has its own stylesheet, there seems no easy way to do this].

  barryoneoff.co.uk 23:04 25 Jan 08

need it's own stylesheet? You just make one stylesheet and point each page to it.

I think you are confusing yourself by trying to get right into the technicalities at once. Unless you intend to write the whole site in Notepad there is no reason to learn everything at once.

Just mess about with a WYSIWYG editor for a while and only learn what you need to, as you go along.

  RWest 16:18 02 Feb 08

barry - I was concerned with a specific problem, which is whether the appearance of an ENTIRE SITE can be changed. For example, I sometimes like reversed out text; or perhaps a background to relieve pure whiteness. Or maybe some people like serif as opp. to sanserif text. I was trying to work out whether an entire site could be changed - remember those sites trying to show how wonderful stylesheets are? But which apply only to one single page. There seems no easy way to do this.

However the message I take away from this is that most people don't hard code for themselves, and the <DIV> structure is done for them by eg Dreamweaver; which perhaps is fair enough.

  Kemistri 20:26 02 Feb 08

As I mentioned briefly in your previous thread, this particular kind of user-chosen persistence is always controlled with a cookie. Even if the scripting is done on the server - which is possible - it still requires a cookie or a login system. A good example of that is the way in which Wikipedia's editors (such as myself) often employ our own javascript and CSS files (stored server-side) that are applied to all pages whenever applicable. These allow an enormous amount of customisation of the appearance, interface and technical features, but you need to be logged in to see it.

click here to see one of many sites that employ basic text resizing that requires a cookie in order to be persistent. It still functions without the cookie, but since it is only changing the text size, the viewer might as well change their browser settings or use the scroll wheel. They may well already have a preferred text size.

Some bright spark may have worked out a server-side way to deliver persistence with neither cookies or a login system of any kind, but I have to yet to discover it.

At the end of the day, this is not about any limitations of stylesheets - this is about the limitations of client- and server-side scripting.

And if you may not find very many hand coders around this particular forum, but there are a great many of us out there. Many of the more technical fora are well populated with them.

This thread is now locked and can not be replied to.

Nintendo Switch review: Hands-on with the intuitive modular console and its disappointing games…

1995-2015: How technology has changed the world in 20 years

Method Studios' title sequence for BBC series Taboo is truly unsettling

Best Pages for iOS tips | How to use Pages for iPad & iPhone: 7 simple tips to get more out of…