Zebra does not work really nice! Sheepy help?

Hi, I was using Sheepy's plugin because it has this zebra attribute and some other nice additions which can simplify my templates. But the zebra attribute works a little bit strangely...

If I have a table in which I add a classname alternating per row. But since each row has more then just one column I get a strange result. Every cell get's a new color on every time the zebra tag is used. I thought it should be smarter and only change values every time the block is merged with a new row of data.

If I want to include a classname in the td element which may only alter every row then at this point I am forced to do the following if I have 4 columns:
The alternate way compatible with the current behaviour of the zebra attribute is:
But I don't want to use it this way. Can this behaviour be fixed in the next version?? Or is it behaving this way by design?

correct examples:

There is another problem with thezebra attribute I found out:

When I am using the exact same zebra arguments in another block within the same template:This results in the problem that when row1 has an odd number of rows. Then the second table get' the second zebra argument first:
I do have a workaround: But this is not really the way to go because if I have even more tables I need to keep track of how many I have and change each one!

Could this be fixed as well??

I decided not to wait and have someone else take a look at it. Sheepy, I've found the way to make sure that zebra always starts at the first value for each block. I did it by adding the fieldname to the hash. In this manner the fieldnam+values is unique rather then just the values.

Here's the code:

ps: I do still need an answer to question nr 1! I was unable to see an easy way to do it. Perhaps you know a better one?

Why don't you guys just do a little bit of JavaScript to do your zebra tables?  No client side needed, and all it takes is the usage of a class="zebra" attribute.

It'll be faster and waste less processing power and bandwidth.  That's what I do for all my zebra tabling.

I'm not sure what you mean by "no client side needed" because using javascript explicitly requires javascript to be available and enabled on the client side. I am used to deliver a working website that degrades gracefully. So if javascript fails I din't see why that should effect the colors of my table rows because javascript is not needed to achieve that.

You seem to require javascript for certain things to work. I don't. I don't even require css although I can't help it that when css is disabled my website will look different. But I added extra elements to make things work easier which will only show when css is disabled.

So using javascript is not an option! And it shouldn't be one for you either in this case.

Sorry, I meant "no server side is needed" ;)

I realized my mistake after I posted.

To follow up, the world has come to accept javascript as nearly becoming a requirement for sites.  As long as you create the javascript to work for dated browsers (IE5+), then it shouldn't matter.  Even in my programming for the government, JS has become required for almost all of our web based applications.  CSS is also becoming a standard requirement so I see no point in ignoring it.  By not using CSS you ignore the HTML 4.1.0 standards set out by the W3C.  You also slow down the site by using tags like style="" redundantly. 

Anyway, to each their own.  However in the hayday of "Web 2.0" and the advent of CSS & JS -- it's odd not to use both to their full potential.  You can still degrade a site gracefully with both.

Sorry that I rarely visit forums during weekend.

Thanks for your fix.  I'll put it in next revision, which should be out soon.
If you put zebra in field, it'll alternate each time it's invoked, it's how it is designed.  Merging it once per row or per col is how I use it.

Personally I also don't like doing this kind of stuff with JS, mainly because of perceived performance and further complicating page load script, in addition to my abyssal experience with browser compatibility (as if bad CSS is not enough for IE!), but I know there are advantages in pushing as much processing as possible to client side.

And did I mention I surf the web with js disabled by default? (through noscript, so I can selectivelly enable script when I need it)

I never said I don't use CSS :P
I build up my sites very carefully making sure I also take disabled visitors into account. You can easily forget blind people or people who cannot afford new computers that can actually run modern stuff. (ok, for blind people the alternating color isn't an issue). But I just made a very carefull evaluation of all the techniques and their pro's and cons. And I think you should be carefull when saying something is a requirement with ll the browser versions around and all of their implementations of all the techniques you might be using. So I'll stick with things that work. I can get the same functionality you get. I'm just making sure everything works without as well. You'll be glad to see sites that do when you're disabled ;)

But on the actual topic: why would it be such a big large extreme high load on the server to do the alternate color over there. If you are looking for performance I'm not sure if tbs is the program to use. I recall reading the statement that tbs is more about the way it integrates with templates then it is about speed. (Even thought it isn't really slow either)

Thanks.
But this means I wll always have to put the altcolor in the tr from now on if I want to use zebra... Ah well, smaller html, faster processing and I don't use tables that often anways :P

It might be a thought to explicitly point to this behaviour in the documentation because it was against my expectations when I was merging blocks.

You are the proof to Scythe that my way of using js actually does make sense sometimes. Although on my sites I would recommend enabling js because it improves the ease of use.