How to effectively show/hide parts of table cells (and replace js onclick)?

Thank you again, deathshadow. I will go with buttons.

I have some doubts about the script's performance though. At the moment the script takes ~1s to process 400 table rows (measured using the Opera 12 Profiler) on my desktop machine, and much longer on a slow mobile phone (Nexus S).

Would it be possible to improve the speed a little bit without changing the overall logic? I do like the current method of clear separation of HTML and JS but the site was actually loading noticeably faster when the code was placed directly in HTML from the beginning

 

If you're putting 400 rows on a page, you're doing something WRONG. Pagination, USE IT!

No, seriously... Whiskey Tango Foxtrot. NOBODY is going to want to scroll through that and OF COURSE processing it is going to be slow.

Rule #12 of data output, never do more than 60 rows of data per page, there's a reason 8.5x11 is 66 rows at 1 pica fonts and 11x17 was used for landscape output... it was the cutoff before the data became unwieldy. There's a reason you don't see normal pages putting that much crap on the page at once at places like craigslist, amazon, ebay or newegg, or that on sites which do like facebook or G+ they post-load the extra data on scroll via AJAX.

400 records per page? EPIC fail. Of COURSE it's slow. If you're pulling this data from a SQL database, you may want to learn to use the LIMIT command.

Makes me wonder if this is the real reason you're resorting to the scripttardery in the first place...

Now that said, if you insist on such ridiculously massive pages filled with information overload, it might be better to consider DOM walking instead of the array lookups. The exisiting table lookup functionality is handy, but JS arrays are agonizingly slow -- the ones that are collections and not true arrays even more so. That's when resorting to firstChild and nextSibling with nodeType filters can help speed things up.

... and be glad we're not using innerHTML, as that would utterly bang the brakes if you're got that many elements.

 

You are probably right with pagination although to implement it would require reworking the whole site and also adding some kind of JavaScript based search function which at the moment is way beyond my skills. It is just a static website (simple HTML, no PHP, etc.) related to my personal interests / hobby so I really do not feel like asking someone to do the whole work for me :/ I will likely try to do something in this matter later once I have enough time to learn the required code.

Anyhow, after changing the spans to buttons the problem of visible elements with CSS disabled is present again. In case of empty spans they were simply invisible but the empty buttons still show up (as thin gray lines) which looks rather ugly. Would you recommend any better way to deal with it other than adding the HTML5 hidden attribute?

 

You could try anchors, but they don't navigate the same way as buttons -- differnt key mapping that's not even uniform across browsers, though tabindex on anchors may fix that -- it's been a LONG time since I tried that.

the only other thing I could suggest is waiting for onload before processing the page with the script, and then seeing if a specific element on the page has a non-default style applied to it to tell you if CSS is working or not. That's ugly, and will make the page be fully visible before hiding things for significantly longer than would probably be desirable. Maybe a two-stage before </body> to hide things then after CSS/onload add the buttons...

Really though it sounds like it might be time to slap on the big boy pants and dive into PHP or some other server side language. Even if you just converted these rows to CSV or JSON and read them in from a static file that way it would be an improvement... though really with that many records, that's time to saddle up and use a DB.