Question for Urs Hunkler - classes for alternating table rows?

Question for Urs Hunkler - classes for alternating table rows?

by Daryl Hawes -
Number of replies: 28
Urs - do we already have any classes defined for displaying alternate table row backgrounds? If not might I ask you to suggest how we might best tackle that issue?
Average of ratings: -
In reply to Daryl Hawes

Re: Question for Urs Hunkler - classes for alternating table rows?

by Urs Hunkler -
Picture of Core developers

Hi Daryl,

with CSS you can address many objects by their CLASS or ID or using "contextual selectors" relative to the parents CLASS or ID.

If you for example look at the new DIV framework of the course page

HTML
HEAD
BODY id="course-view" class="course"
DIV id="page"
DIV id="header"
DIV id="nav-bar"
DIV id="content"
DIV id="course-content"
TABLE id="layout-table"
TR
TD id="left-column"
TD id="middle-column"
TD id="right-column"
DIV id="footer"

You can address the TR of the main layout-table and change the background color of the course page starting beyound the navbar and ending before the footer:

#layout-table TR {background-color: #FFD991}

Could I answer your question with this example or do you want to change the backgrounds of a special table row background? Could you then please tell exactly which ones? With contextual selectors much can be done, but not everything.

Good luck
Urs

Average of ratings: Useful (1)
In reply to Urs Hunkler

Re: Question for Urs Hunkler - classes for alternating table rows?

by David Scotson -

I think the original question refers to the striped effect used for tables of data in Mac OS X applications like iTunes:

iTunes screenshot showing striped background

This makes it easier to read tabular information by following the stripes along horizontally.

In PHP code you generally assign a class (e.g. "odd-row") to every second <tr> tag as you loop through the code producing the table. This should only be used in a table used for tablular data e.g. lists of users and not for tables used purely for positioning.

You can also achieve the same effect in javascript if you are dealing with static HTML or have no access to the server-side code.

In reply to David Scotson

Re: Question for Urs Hunkler - classes for alternating table rows?

by Martin Dougiamas -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers
The question is really this:  as Moodle developers, what structure can set up to best allow theme designers to add alternating colours to our tables?  

We need to standardise on some sort of method for this so we can apply it to tables throughout Moodle.

Shall we just add "row-odd" and "row-even" classes to the standard style sheet?
In reply to Martin Dougiamas

Re: Question for Urs Hunkler - classes for alternating table rows?

by Urs Hunkler -
Picture of Core developers
<td class="row-odd"> and <td class="row-even"> within all data tables would be great. As David mentioned, it's important to avoid them in the layout tables.

Into the theme CSS go two properties like
.row-odd {
    background-color:brightcolor;
}
.row-even {
    background-color:darkercolor;
}

In reply to Urs Hunkler

Re: Question for Urs Hunkler - classes for alternating table rows?

by David Scotson -

You don't really need both odd and even identified by a class. Each data table should itself be identified e.g. id="course-student-table" which means the 'normal' row can be targetted without a class.

#user-table tr { }

#user-table tr.row-odd { }

This can reduce repetition in your CSS if you have both striped and non-striped tables and it lets you set styles that apply to both odd and even rows (font-size etc.) only once, only having to override the values that change (usually just background color).

Actually, I've changed my mind on this, having both has no real downside (except an extra 7 characters per table row) and allows different people to approach the same problem from different directions so why not?

Average of ratings: Useful (2)
In reply to David Scotson

Re: Question for Urs Hunkler - classes for alternating table rows?

by Martin Dougiamas -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers
Nice lateral thinking!

I was sold on it, but after pondering a bit more, I'm still for row-odd and row-even.  Having just one means extra work on the designer ... styles need to be defined individually for every table (rather than being able to change the data tables for the whole site in one go).

Changing fonts for all rows in a table will still be the same using both approaches, though.
In reply to Martin Dougiamas

Re: Question for Urs Hunkler - classes for alternating table rows?

by David Scotson -
I edited my post that Martin replies to above roughly 30 minutes after I originally posted, eventually diagreeing with myself, in case anyone reading this later is confused.
In reply to David Scotson

Re: Question for Urs Hunkler - classes for alternating table rows?

by John Papaioannou -
Can I pitch in here to say:

"Please guys, remember to use thead and tbody in your selectors"? smile

My pet reason for that is that you probably want different formatting for table thead th and for table tbody td, but you probably get the picture. Of course that means forcing people to write thead and tbody from now on, but IMHO it will lead to better semantics for Moodle's pages = better control with CSS.

Jon
Average of ratings: Useful (1)
In reply to John Papaioannou

Re: Question for Urs Hunkler - classes for alternating table rows?

by David Scotson -

"you probably want different formatting for table thead th and for table tbody td"

Do you mean different formatting for table thead th and for table tbody th i.e. subsidiary headers in more complex tables of data since table th and table td selectors should be enough for the majority of tables. Of course that only applies to the selectors in the CSS because if tbody and thead aren't added in the HTML then no-one will be able to use them no matter how good their CSS is.

And in case anyone reading this gets confused, remember this entire discussion is about tables used for tabular data with rows and columns of information, not tables used for visually grid-based layout and formatting. For presentational layout tables only 3 of the table tags (table, tr, and td) should be used to prevent accessability issues.

Average of ratings: Useful (1)
In reply to David Scotson

About thead and tbody in realtion with th

by John Papaioannou -
Actually to be more specific, this is what I have in mind:

Suppose you want your table to have a header, like "Submission Data". Now this should be, let's say, centered and bold and maybe have a bit larger text size. On the other hand, for the form itself, you might want to have a display like
   name: __________
age: __________
address: __________

It's evident that this reads best if the "labels" are right-aligned and maybe bold. Now you definitely don't want to have every label be td style="text-align: right; font-weight: bold", and also giving them a class isn't very elegant because you could say that semantically they are headers.

If there is a selector which reads "table th", then people would have to add a class to their tables and override that selector to achieve the desired effect.

What I 'm saying is that with my proposal, I believe that it would be easier to reuse and "work with" the Moodle default styles, rather than "working in spite of them".

Make sense?

In reply to John Papaioannou

Re: About thead and tbody in realtion with th

by David Scotson -

Yes, I see what you mean. Note that the info "Submission Data" could perhaps be placed in the caption tag, or simply placed in a header tag outside of the table i.e. h1 tags if the table is the main or sole content of the page.

thead is described in the spec as enabling ... user agents to support scrolling of table bodies independently of the table head and foot. When long tables are printed, the table head and foot information may be repeated on each page that contains table data.

This may seem rather esoteric, but some accessibility software takes advantage of this info too so I think it is worth including.

Some of the examples I was talking about, with multiple th tags distributed throughout the table can be seen here:

Techniques for Accessible HTML Tables

In those examples (if you imagine a table with hundreds of entries) you can see why the horizontal column headers would need to be repeated over multiple pages or remain static while the data scrolls (as in desktop GUI apps). The row headers on the other hand are located at the left hand side of the row and can be read across easily as they are always attached to the relevant data.

edit: Also, note that every table should be identified with an id. Your example of table th is too wide anyway, (as is table thead th) because it would apply to every single table header in the entire site, including many user entered data tables. This is shown in the "standardxhtml" that used that exact selector to attach the gradient background to several of the tables in Moodle's interface that had no suitable id or class. Unfortunately this also affected all tables in user entered resources, forum posts etc.

In reply to David Scotson

Re: About thead and tbody in realtion with th

by Martin Dougiamas -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers
Every table doesn't need an id, because usually there is only one of these big data tables on a page, and every page now has a unique selector.
In reply to David Scotson

Re: About thead and tbody in realtion with th

by Urs Hunkler -
Picture of Core developers

Hi,

yes, Martin, with the page ID and the group CLASS for all Moodle pages addressing the objects on the pages is much easier.

As I see it in the moment the standard layout tables could have an ID. For example just class="layout-table" to make them individually addressable with for example ".forum .layout-table td {padding:1em}" to define the distances of the objects on all the forum pages.

A big advantage in addressing data tables would be to give them an ID and CLASSes (for example if you deal with simmilar types of tables on different pages you can change the layout for all in one step via the CLASS and layout only one via the ID).

One example for the challenge to work with pages with very few IDs or CLASSes as hooks are the glossary pages. You need to code the CSS to address the background color of certain cells like:

.glossary center center td table td,
.glossary-edit center center td table td {
background-color:#FFFFFF;
}

Can you guess which parts of the page will be colored? I can't without documentation in the code.

Daryl, could you please take this aspect into your considerations for the blog. Specially because you give the blogger the chance to change blog themes as Dan posted in another thread. I like your interesting approach and am quite curious how your going to implement it.

Urs

In reply to David Scotson

Re: About thead and tbody in realtion with th

by John Papaioannou -
Cool, I didn't know about the &lt;caption&gt; tag. I 've started using it now. approve

The only problem about using e.g. &lt;h1&gt; for table "titles" is that it is possible that the title will have some visuals on it, for example a background, and the table might not take up 100% of the parent element's width. Then you would need to "manually" give the title the same width and positioning as the table. &lt;caption&gt; lets the browser take care of that.


In reply to David Scotson

Re: About thead and tbody in realtion with th

by Amy Bellinger -

> thead is described in the spec as enabling ... user agents to support scrolling of table bodies independently of the table head and foot. When long tables are printed, the table head and foot information may be repeated on each page that contains table data.

I'd forgotten all about the scrolling thing. It could come in handy. I wonder how its browser support compares with iframe.  It's better than iframe for something like statistical data, because it keeps the columns identified all the while.

In reply to David Scotson

Re: Question for Urs Hunkler - classes for alternating table rows?

by Urs Hunkler -
Picture of Core developers

Hi,

I just looked at the code at the skype website, where they use alternating colored rows in lists. They use:

<tr class="r1"> and <tr class="r0">

This is quite short and ok for me.

Urs

In reply to Urs Hunkler

Re: Question for Urs Hunkler - classes for alternating table rows?

by Martin Dougiamas -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers
Urs,
OK, this sounds fine to me too. I will go ahead with
<tr class="r1"> and <tr class="r0">
for the blog module.
Thanks!

(Originally this post was by Daryl Hawes, I edited it to fix the tags)
In reply to Martin Dougiamas

Re: Question for Urs Hunkler - classes for alternating table rows?

by David Scotson -

That seems like quite a computer-science-like approach i.e. starting counting at 0. I for one am not sure how it would map onto the actual rows.

Essentially they could be given any two distinct names but if, for example, I'm implementing a new table for Moodle do I make the first row (that is, row number 1) class="r0" or class="r1"? I don't think it's obvious. On the other side, as a theme designer, if I want the first and third etc rows (#1,#3, ...) to be blue, do I change the class for r0 or r1?

I'd err towards making class names as descriptive as variable names in the code which I think in this case means using the word "odd" and "even" e.g. row-odd & row-even, odd-row & even-row, tr-odd & tr-even or similar.

If brevity is really the key then r1 and r2 would make more sense to me.

In reply to David Scotson

Re: Question for Urs Hunkler - classes for alternating table rows?

by Urs Hunkler -
Picture of Core developers

Hi David,

when I wrote my posting I stumbled over the same question. I searched for "Is zero an even numer?" and found this article at Dr. Math.

I liked the simmilarity of two states in how computers work with 0 and 1 and the two states of emphasize on an off in rows in the tables. In the Skype pages "r1" is used for all odd lines and "r0" for all even lines as it is mathematically correct.

Best wishes
Urs

In reply to David Scotson

Re: Question for Urs Hunkler - classes for alternating table rows?

by Martin Dougiamas -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers
Either is fine ... shall we move on to more pressing issues? wink

David, where's that proposal you had for implementing lists in blocks using list tags - can you revive that discussion? I liked that!
In reply to Martin Dougiamas

Re: Question for Urs Hunkler - classes for alternating table rows?

by David Scotson -

There's some code here, I think Urs has had a play around with it.

I was unsure about how to introduce this without utterly trashing backwards compatability, but if Moodle is to have a standard stylesheet as well as a 'theme' stylesheet then I think that solves the problem (to a large degree) and I'd be quite keen to work out the remaining kinks and have this replace the current block HTML.

In reply to David Scotson

Re: Question for Urs Hunkler - classes for alternating table rows?

by Martin Dougiamas -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers
Wow, only three days ago!  I never saw that one (I was referring to much older discussions) - glad it's alive!  I've moved it to the Themes forum.
In reply to David Scotson

Re: Question for Urs Hunkler - classes for alternating table rows?

by John Papaioannou -
If we want to have small icons inside the list items, this could be a bit tricky. Do you know of a good way to keep both the icon and the text vertically centered, no matter what the image height and the font size is, no matter what the user's browser is?

To give a real life example, go to http://www.18-24.gr/ (it's a site I 'm developing and webmastering) and look at the bottom block on the left. Play a bit with the font sizes in Firefox. It's all CSS, and I 'm very satisfied with the result only I don't have an uber-solution for vertical centering.

How do you propose to take care of that without using tables?
In reply to John Papaioannou

Re: Question for Urs Hunkler - classes for alternating table rows?

by David Scotson -

Well there are three basic techniques, two of which have problems:

  • the obvious CSS solution is to change the list bullet style to use an image. Unfortunately this is inconsistent across browsers

  • the second is to place an img tag within the list item, which is what appears to be done at the site you link to. The problem with this is that you can't change the image simply by changing the CSS. In Moodle terms, this isn't controllable by the 'theme'

So I went with a third approach, which I used for my block rewrite and which you can see at the demo page Urs set up. The approach is to attach a non-repeating background image to the a tag inside the li which is postioned like so:

.block-list li a {
    padding: 0.2em 0 0.2em 30px;
    background-repeat: no-repeat;
    background-position: 10px center;
    display: block;
}

and the individual images are selected with this:

.block-list li.people-profile a {
    background-image: url(img/user.gif);
}

This has several benefits including allowing the theme to dictate the image, filetype, size and position all of which are constrained to some degree if an img tag is used.

In reply to David Scotson

Re: Question for Urs Hunkler - classes for alternating table rows?

by John Papaioannou -
Very nice! approve

Actually I 've rewritten this answer twice because the more I think about the implications of your post (and what follows here), the more possibilities I see and the more excited I get!

This is how I build the lists on that site:

$items = array(
array('text' => 'Menu item 1',
'href' => 'http://some.site.net',
'img' => 'src="pic.gif"'),
// more items for the list here
);
$SMARTY->assign(array(
'listclass' => 'mainmenu',
'listitems' => $items,
// more vars for Smarty here
));
$SMARTY->display('ul.tpl');

Obviously ul.tpl is "smart" and builds the list tags on-the-fly, depending on what keys it finds in the items contained in $items. Expanding this to support "id" for the list items should work wonderfully.

There's only one really small issue, namely that you have to hardcode a padding-left value for the list items. This could be a annoying because it constrains you a bit regarding the images, but I 'm not sure if it's a problem in practice.

In reply to John Papaioannou

Re: Question for Urs Hunkler - classes for alternating table rows?

by David Scotson -

I'm not sure what you mean by 'hardcode a padding-left value' but, yes, the padding needs to be there to stop the content overlapping the background image.

For example for the 16x16 images used in the block implementation, I've used a 30px padding and positioned the image 10 pixels in from the left to give

[10px-space] 16px image [4px-space] text

However, all these values can be changed easily to use a much bigger image, or varied on an item to item basis. It can be altered when you mouse-over the li, reversed to have the images at the right of (or above or below or behind or in the middle of) the text or left out completely. All these decisions can be controlled on a theme by theme basis (or by javascript stylesheet switchers within a theme) so it's not really hard-coded.

In reply to David Scotson

Re: Question for Urs Hunkler - classes for alternating table rows?

by John Papaioannou -
No, I meant that you can't change the size of the icons in a flash with this scheme, because the padding is hardcoded in CSS and its value has been calculated with the image size known beforehand.

But it's probably not an issue because the icons would be a uniform size anyway in a case like this. Don't pay too much attention to my nit-picking. wink