Zoe M. Gillenwater wrote: > While this is a great proof of concept, I wouldn't use it on an actual > project. This is really tabular data and belongs in a table.
That was my first thought too - looking on the given example. Then I considered the data to be presented, the loads of code that would be needed to present empty space, and finally the fact that the page to be set up here is hardly the data-storing part of the set up, it's only presenting something from a database or a datasheet of some kind. > With this > sort of layout, there is no underlying semantic meaning that the user > agent can make sense of without CSS. Turn off CSS and see what I mean. I was going to suggest that starting and finishing times should be written on every entry of work/vacation etc (it would be a help, regardless of whether a table is used in the setup or not), but forgot in the hurry. With a database behind, there is not a much devellopment to be done here in order to make a list of each employee's engagements for the day - actually it could be fitted into an xml structure without major changes to the setup. The lists of engagements are visionally relateable to check hour overlaps - in a table-like way - I agree :-). > Even in an intranet setting where you can assure that everyone has CSS > turned on, this might not be a good solution because if it needs to be > significantly restyled it will probably take considerably more work than > restyling the table would. I agree that much will have to be done to convert into a new setup if the data is stored in this page only. On the other hand, saving these data as a table is madness in terms of storage, far too much code, used for nothing, is saved. > With a lot of employees with very different > schedules, it could also get pretty messy -- a ton of ids to form the > colored spans for each of their schedules. Maybe I'm wrong about this > last though -- maybe the PHP is doing something that makes this far more > efficient than I can see. I've held the positioning indicating pixel/hours of each task inline, close to the classification, as those two will mostly have to be changes at the same level of administration. If a database is behind (as I asume), it's still easier to enter those data there, than in an external sheet where they would be un-administrationable, I agree. A final note: if this is along the lines of an ancient "what is tabular data and what's not" debate or the like, then I've overlooked it, and would like to be kindly kicked in the right direction. I'm still very much learning here and everywhere else concerning the web standards and their proper use. Best regards Jesper Brunholm ______________________________________________________________________ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/