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.
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/