Topic: IE hates my position:absolute divs (Page 1 of 1)

I'm more of a programmer than designer and my understanding of css is basic as best, I'm also working with someone who is a good designer but not much better than me as far as understanding the css standards and the rendering engine flow. Anyway I built this semi-nifty schedule for a local low power radio station and when I view it in any reasonable browser it's fine(although quite a hack job in my opinion) but when I try it in IE it doesn't even display my divs, I'm not sure if the main div is obscuring them or they just aren't being displayed. I tried to set the main div to a negative z-index and the cell divs to a positive z-index, no luck.

Here is the page: http://kpov.org/KPOV.2/test.html (moved schedule onto it's own page for easier viewing)

Any links to an in depth reference on this sort of issue would be greatly appreciated, I've been struggling with this for some time now without any insight.

One of the things I'm doing which I'm not sure if it could be affecting IE is I set the div to a preset class then override the style with the dynamic data to obtain the correct position and size.

For example: <div style="top:19px; left:72px; height:36px; width:214px;" class="cell">

(Edited by OpticBurn on 03-11-2006 09:26)

One word: TABLE.

This is *exactly* the type of informatiion that tables are intended to display. Working this hard to mimic a table rather than using one is completely counter-productive.

In addition - position:absolute; , as well as fixed pixel sizes, should be used only when absolutely necessary. A simple increase in text size via my browser and the whole thing is shot to hell.

However, I vewed this page with both Firefix and IE 6, and it displayed the same in both.

I must reiterate though - TABLE! This is why tables exist, and this is where a table should be used.

=)

I guess I'm confused, for one I don't get any problems when I resize the text, I thought that would be a problem with using tables.

I've never used position:absolute before, I prefer to just let things flow relative to each other but the designer on this project uses them all the time...

I'll try to rebuild this with a table, now that I've thought about it some more(slept on it) I have some more insight into how to approach this, I'm just confused about how you build a single cell that spans multiple rows and columns.

(Edited by OpticBurn on 03-11-2006 22:37)

colspan, rowspan

Any time you use absolute pixel dimensions for an element, you will have problems with text resizing. In any browser other than IE, the text will expand beyond the bounds of the divs. In your case, the sizes are all so small that this happens with only a small change.

I would strongly recommend not setting the height or width of any of the table cells, unless perhaps you set each column to a certain percentage width.

I agree, I'm just not seeing how you use colspan and rowspan together. One of the problems is that the design elements that contain the table are fixed with pixel dimensions so if I allow the table(or div) to resize with the window or text sizes it will obscure the elements on the sides of it. I should have a talk with the designer though.

quote:

---

OpticBurn said:

I agree, I'm just not seeing how you use colspan and rowspan together.

---

Well...you just...use them together A cell can have both a colspan and a rowspan. It's been a long time since I've had to worry about such things, but it should all work out fine.

One important note - make sure to use <th> tags for the row and column headers. That's why they are there (makes the css go a little simpler too...)

As for the other elements - if you get rid of any absolute positioning, resize of the page/table will be no problem whatsoeve - regardless of fixed widths.

This is my problem and why I originally didn't use tables, notice how the 'Souled Out' show overlaps nicely with the divs but not so nice with the tables. I think I might have to use something besides rowspan, just make the border inbetween rows invisible or something.




(Edited by OpticBurn on 03-12-2006 10:20)

Just an information architecture question here for you. Your table is supposed to show a schedule of radio shows, yes? Your absolute divider then, is the days. Because a show won't extend over two days, but it *will* extend over two or more time periods in a day. So all you need to make it work, and to get it to make sense is rowspan. I'm not sure if I'm making sense here.

You should never need to expand across columns, only across rows, to show one show fills tow time-slots.


Justice 4 Pat Richard

In other words, that "Democracy Now" cell that spans Monday and Tuesday? That's kind of weird. It should be two different cells because the show is on two different days. It doesn't span both days, does it? "Souled Out!", on the other hand, actually does span two time slots. What you've got up there right now is applying two different standards to the idea of spanning. Not only is it inconsistent, it's not really standard practice (from what I've seen of television/radio schedules on the net) and might confuse viewers.

Skaarjj was perfectly clear in his comments, of course, but I just wanted to expand a little on them.

And I just have to say that, after trying for so long to get people to use CSS instead of tables for layout, it's almost refreshing to see someone insisting on using CSS instead of tables for tabular data. Talk about a pendulum swing.




___________________________
Suho: www.liminality.org | Cell 270 | Sig Rotator | the Fellowship of Sup

Actually this method of spanning columns is fairly common in radio show and tv show schedules to indicate a show that is on every morning at the same time slot. Really I suppose the major issue I had here was that the table format will not accomodate all the possible scheduling layouts, since using rowspan and colspan only allows for square cells and it might be possible to need one that is say, L shaped. So mainly the problem is if a two repeats over two days it can't have a different length.

Here's a classic example of the type of schedule the radio people want to mimic.
http://www.opb.org/radio/grid.php?c=fm

Here it is in all it's tabtacular glory, thanks for the all the comments, I think this will be more than adequate. This has been my first project with php and trying to build a dynamic website, very educational experience.

http://kpov.org/KPOV.2/schedule.html

quote:

---

OpticBurn said:

Actually this method of spanning columns is fairly common in radio show and tv show schedules

---

I have spent a good deal of time looking at radio and tv schedules and have never seen such a thing (at least not to the extent that your examples are trying to show...). It simply doesn't make sense from a data point of view or from a presentational point of view.
ANywhere than an 'L' shape would be used would be much better presented by breaking it up into seperate areas anyway. It would be a bitch to have to look at a schedule with overlapping L shaped blocks that don't break down clearly into day/timeslot.

The finished product looks great.

One more note on the code front - you currently have every single <th> with the same class, and every single <td> with the same class. This is a whole lot of wasted bytes. If they are all the same, then no class is needed. If you are concerned about other tables elsehwere in the site, then all you need is a class for the table.

something like <table class="schedule">
and then in your css -

table.schedule th {
..your th styles...
}
table.schedule td {
..your td styles...
}

Makes for much cleaner code and much easier updating.

{{edit -

Ok, on looking further at the code: same goes for your nav menu links. Each <a> has the same class.

Also, you've got a very bog no-no with the navSection - you've got 7 divs with the ID of navSection. An ID is unique - it can only occur once per page.



(Edited by DL-44 on 03-13-2006 03:06)

quote:

---

Suho1004 said:

nd I just have to say that, after trying for so long to get people to use CSS instead of tables for layout, it's almost refreshing to see someone insisting on using CSS instead of tables for tabular data. Talk about a pendulum swing.

---

That just begs me to disagree

I've seen this kind of issue over and over, unfortunately, and it is a case of the actual point being totally lost. The point was never that tables shouldn't be used, but that they should only be used when appropriate. Of course, I know that you are well aware that, Suho, but feel it important to reiterate.

It's *never* about not using a particular element. It's *always* about using the element that is appropriate for the content.

Going out of your way to mimic a tag with semantically poor methods is at least as bad as using tags for the wrong reasons.

FWIW

Agreed, it is important to reiterate. But I was just attempting to be sarcastic... guess I failed.


___________________________
Suho: www.liminality.org | Cell 270 | Sig Rotator | the Fellowship of Sup

I look on radio schedules and TV guides the same way I look at the timetables it used to be my job to crank out for every man and his dog at the school I used to work at. There is an absolute divider, the divider across which nothing goes. That divider is the day. Temporal physics, after all, does not allow you to jump straight from 7:30 AM on a Monday to 9:30 AM on a Tuesday without crossing the 26 hours in between. So nothing crosses that divide. With that in mind, then, you look at your schedule in terms of page layout. Is it going to be portrait, or landscape? If it's portrait, then your days form oyur columns, and your hours the rows. If it's landscape, the two are reversed. Whichever you use, you need only tell your table to span one type of divide: row or column.


Justice 4 Pat Richard

It's interesting this persistent insisting about the "absolute divider."

For starters the client said: "This is what I want." So that's that, if he wanted me to print out the schedule ordered by the inverse square root of the numerical representation of the first character in the show name, I would have done it.

Second, personally I think it looks better and more readily conveys the information: This is the same show from 8-9 monday-friday.





Third, if you google "radio schedule" on the first two pages, of the shows that list by week in a table, only 1 doesn't print out the data in this same format. Since that includes NPR, OPB and almost all of the public radio stations it's pretty easy to see why a low power radio station would want to emulate that style of graphical display.

(Edited by OpticBurn on 03-14-2006 22:48)

Personally, I'd have to agree with the others that your second example makes more sense. Democracy Now is on 5 times, once on each M, T, W, Th and F. It doesn't span those days.

Besides, it's very easy for my eye to choose Wednesday, then follow the column down where it meets 11:00 am to see what's on. In the first example, it takes me a couple of seconds to interpret what intersects what. But the client gets what the client wants.

Also, I'm very happy to see people on my side concerning the "table tags for tables" argument. I recently had this argument with a developer with whom I was working on a site. Every table on the site is made up of an extremely complicated set of divs, with multiple classes to make them act like a table. I told him he should just use a table for that. His response? "There is nothing preventing me from semantically re-labeling the div's (row, column, and cell elements) as e.g. ul's or dl's, to provide baseline accessibility. ... A table is really nothing more than a list of lists." He insisted that "tables themselves are notoriously inaccessible."

He used divs for damn near everything and labeled every damn tag with a new class. (Take a look at how nested his divs are using Firefox's View Rendered Source Chart.) H1's got classes like "Blurb_h1." He also refused to let me use IDs for unique elements, insisting that a class would do the same thing. His style sheet is horrendous; nothing cascades. It's just a list of unique classes for every element:

.ClassThis { ... }
.ClassThat { ... }
.ClassThatForThis { ... }
.ClassSomethingElse_1 { ... }
.ClassSomethingElse_2 { ... }

Plus, when he modularized the site, he created not only a separate sheet for every module (banners, each table, side boxes, navigation, etc.), but SEVERAL different sheets for every module. He couldn't understand how it made more sense to have at least the majority of the styles in one place. It was impossible to maintain.

I finally had to step away from the project.



(Edited by Wes on 03-14-2006 23:25)

Maybe I should make an anchor so that people can switch between the two views, what would something like that be called?

Sorry to derail here, but... Wes! Where is that nifty View Rendered Source Chart? I've never seen that in FF before.

And to make an on-topic comment: I suppose that what the client wants will drive your design. And I can kind of see the logic behind the day-spanning, even if I don't agree with it. However, doing it that way could lead to some ugly L shapes (like the one that was giving you headaches). If none of the other arguments are convincing enough, maybe the possibility of having those ugly L shapes would dissuade you.


___________________________
Suho: www.liminality.org | Cell 270 | Sig Rotator | the Fellowship of Sup

Suho1004: there goes the View Rendered Source Chart Firefox Extension

Very cool - I was not aware of that extension either. =)

An important note:
Ultimately, the bottom line is that what the client wants s what they get. However, it is also your job to at least attempt to influence the client, and direct the client along the lines of things like proper coding, readibility, usabilty, accessibility, etc.
This applies whether we're tlaking web deisgn, heavy construction, or anything else.

FWIW.

And Suho - yeah, missed the sarcasm out of concern for that view propagating further

poi: Thanks! That's a nifty little extension.

DL: Just as long as you know which side of the fence I'm on.


___________________________
Suho: www.liminality.org | Cell 270 | Sig Rotator | the Fellowship of Sup