best method to "hide" a whole <table> column ?

[Evertjan.]

whygee wrote on 22 jul 2009 in comp.lang.javascript:

1) Evertjan wrote :
etc.

2) I complained because I don't want / can't write in advance
the CSS properties of each column of each table that will ever be used,
or else i'll have to make a gigabyte-sized .css
in order to cover any corner case and/or put artificial
size limitations to my code...

As I answered, the code aplies to all tables, not to a single one.

2") Thomas complained for something else, if I understand correctly :
it's about the syntax (hence the description of the BNF below) because
is invalid.

That's also why I thought that Evertjan's proposition
was to be avoided : if the value is not given, then the selector is
useless and can be skipped entirely,

You thought wrongly.

Did you really try my code?

You would have seen that the selector is not useless,
try leaving it out.

using {display:;} can be replaced by {display:block;},
pleasing purists like Pointed, but since this is the default,
present day browsers would do the default anyway.

so I don't have to write the
whole line. Hence my remark later about default values too,
as well as the cloning of the properties.
In my code, I just have to create one correct table with one
correct CSS, and the user interactions will clone then modify the
table and the associated properties, no need of hundred of CSS lines.

Now, the rest of the thread makes new and better sense to me,
and I agree with Garrett & Thomas. However I still don't understand
why Evertjan wrote the code in the first place.

OTOH, Evertjan
doesn't understand that I don't create the tables server-side,
which is a completely different issue

Are you being willfully nasty?

Why should I not understand what you did not state?

My serverside example just shortens your programming effort,
the html sent to the client is not different from the full
CSS.

Furthermore my response was not only for your benifit, as I would have
emailed it, but for the interested memberreaders of this NG as a whole.

(going almost completely
serverside-less is a design choice that pays well for me).

"almost completely", so you have access to it!

It must be that it pays of in your not willing to learn serverside
coding, as serverside coding only simpifies the task of webside
programming and so reduces programming time and effort.

 

[whygee]

Hello,

You thought wrongly.

Did you really try my code?

You would have seen that the selector is not useless,
try leaving it out.

using {display:;} can be replaced by {display:block;},
pleasing purists like Pointed, but since this is the default,
present day browsers would do the default anyway.

I have found that "visibility:collapse"
is the right way to deal with <colgroup>.
I have even seen that no additional .css or <style>
is required for my code to work (the <td> already
have their own classes, wich are used by JS to find
their types). I just have to modify the table scanning
routines, since some old assumptions don't hold, that's all.
For me, the issue is closed.

the <colgroup> option was not knoen to me, but the principle of renaming
the class of the table identified by it's id was my goal.

well, if I understand correctly, if my table has N columns,
then there must be N*N style declarations to deal with the cases
where any of the columns is hidden.
If any combination must be possible, there must be N*2^N lines.
It works for small tables but it is clearly not scalable,
adding a new column will be a manual error-prone process.

OTOH, thanks to Alexandre, an unobstrusive prototype is working
and no additional CSS is required. It's scalable and ideal for my case.

Are you being willfully nasty?

no. I just want to separate the original (and solved) problem
from discussions about things that already work.

Why should I not understand what you did not state?

If I used server-side code, I would not care about
using JS to hide a column...

You can have a look at the first page at http://yasep.org
which, I hope, explains why it looks like a "website"
but it is not limited to this form.

Furthermore my response was not only for your benifit, as I would have
emailed it, but for the interested memberreaders of this NG as a whole. fine.

"almost completely", so you have access to it!

Yes, I use a server to host the site, and PHP is available.
But if it's available, it does not mean that I'm /forced/ to use it.

The only place where I use PHP is because I can't do without
/and/ it is not critical to the project :
http://yasep.org/tools/generate_VHDL.html which uses
http://yasep.org/JSgui/test_filefox.html
It is designed to work on any server (even with a local server).
That's all. Anyone can load the .tgz of the project and
use it on his computer, no need to install anything else than Firefox.
Those who want to use filefox have to install a Apache or EasyPHP.
And there is even failsafe JS code that works when PHP is not available
(it's just less user-friendly).

It must be that it pays of in your not willing to learn serverside
coding, as serverside coding only simpifies the task of webside
programming and so reduces programming time and effort.

"not willing to learn ss coding" => I started the project with PHP
but soon reached latency and server load limitations.
Since I'm not doing a "classic web site" I switched to JS-only and although
the pages load a bit slower, the functionalities and performance are much, much better.
In this project I favor interactivity, the possibility to work without
server (without even Internet connection) and if the project is hosted
on a server, then it must be loaded as little as possible.

This is completely different from "usual websites" that do online retail,
for example.

regards, peace, hapiness & bugless code,
yg

 

[whygee]

Hello again,

I'm analysing the code a bit more and a few things now catch my eye.

(function () {

})();

Is there any benefit for this construct,
except for the separation of the scope ?

byId = function (id) {
var elem = document.getElementById(id);
elem.byName = elem.getElementsByTagName;
return elem;
}

https://developer.mozilla.org/fr/DOM/document.getElementsByTagName
says that getElementsByTagName requires a parameter
(the type of tag). So in fact you return a function.
Is it a way to reduce the code size by avoiding calls to getElementsByTagName
in the rest of the code ?

colHeads = byId('books').rows[0].cells;

I never used the .rows[x] syntax before,
this is going to help me make my code simpler
(I relied on .nextSibling, .firstChild etc.
and it's a bit fragile)

Anyway, this piece of code is not obvious but
it is very nice one. I hope that I will soon
raise my JS coding standards up to that.

yg

 

[whygee]

Warning:
- Unfortunately, Firefox as a bug handling css on colgroups

I have hit it and this forced me to change the style a bit.
Compare http://yasep.org/tools/2/listed.html with
the original http://yasep.org/tools/listed.html

Any border of a TD would remain at the same place,
while the background of a hidden column disappears,
which leaves annoying and mistaking traces.
So I disabled the borders...

- it works nearly well on IE 8 (I don't understand why the table
width isn't reduced)

Opera does not react to display:collapse
Fortunately, hiding columns is not a critical feature.

This code is just an example of good practices, but Browsers lacks
makes it a little more complicated
So don't hesitate to use well designed frameworks like JQuery or YUI

I'll keep the current code for now, there are more important features to add now.

yg

 

[Alexandre.Morgaut]

Is there any benefit for this construct,
except for the separation of the scope ?

This construct is important because using it, all variables are
declared locally and not in the global scope
Note that doing so, once all handlers have been set on the HTML
elements, all these variables can be removed from memory, even
functions like "byId", (unless they are used by some handlers).
All the more, if you use some local variables of this function in your
handlers, these ones can be used like private properties only shared
by these handlers

https://developer.mozilla.org/fr/DOM/document.getElementsByTagName
says that getElementsByTagName requires a parameter
(the type of tag). So in fact you return a function.
Is it a way to reduce the code size by avoiding calls to getElementsByTagName
in the rest of the code ?

This function is only a little helper which allows you to write code
quicker and more readable
The size rarely really matter as, all the more for repetitive text, as
you can make it compressed automatically by your HTTP server (content-
Encoding: gzip)

colHeads = byId('books').rows[0].cells;

I never used the .rows[x] syntax before,
this is going to help me make my code simpler
(I relied on .nextSibling, .firstChild etc.
and it's a bit fragile)

Yes DOM methods aren't very user Friendly
JavaScript provide a useful interface to access Forms and Tables
elements

I like this little tree :
http://www.howtocreate.co.uk/tutorials/javascript/domtables

For more details :
http://www.w3schools.com/htmldom/dom_obj_table.asp
http://www.w3schools.com/htmldom/dom_obj_tablerow.asp
http://www.w3schools.com/htmldom/dom_obj_tabledata.asp

Notes :
- you put your head row in the <tbody> instead of a <thead>
- there is a <col> element which could be more accurate than
<colgroup> (sorry, I know, it cames from my example)
- Using HTML templates is a very good idea, I recommand it for any
widgets,
- This template could have been loaded from an Ajax request to a
specific file becoming then more cachable
- Try to use <caption> on tables as often as you can, and setting the
"sumary" attribute is also a good practice
- You don't need the "trash_div", you can set "trash_div" CSS rules
directly on the "trash_image"

Anyway, this piece of code is not obvious but
it is very nice one. I hope that I will soon
raise my JS coding standards up to that.

I hope I'll have the occasion to expose some more good parts ;-)
First of all, try to validate your JavaScript code on http://www.jslint.com,
and your html code on http://validator.w3.org
You will learn a lot of useful things

 

[Thomas 'PointedEars' Lahn]

[...]
This code is just an example of good practices, but Browsers lacks
makes it a little more complicated

Not understanding browser scripting makes it look complicated.

So don't hesitate to use well designed frameworks like JQuery or YUI

You must be joking.


PointedEars

 

[David Mark]

As Alexandre suggested, you can use colgroup elements, then show or
hide the colgroup.


Yes, that's an issue that can be avoided using colgroups.

Here's a script I wrote some time ago that should do the job of
modifying a style rule.  For more information, check the archives,
checkout David Mark's MyLibrary, or peter michaux's FORK.  Matt Kruse
used to have some of this stuff on his javascript toolbox site, but
that seems to have closed down.

Actually, I closed mine down. His is there (at the moment anyway.)

Also, I was looking at addStyleRule recently and spotted some
potential disasters in the feature detection (tests host addRule/
insertRule methods by type conversion of all things.)

[snip]

 

[David Mark]

Yes of course its not required
I wrote this because its usually a better practice to change a class
whereas changing directly the style in that your code becomes more
evolutive

I'am waiting for the day all frameworks will use the same semantic in
their widget so I can apply common css skins to datagrids or calendars

That presumes you would use at least two frameworks in a single
document.

from any of YUI, ExtJS, Script.aculo.us, ...

The last is not a framework but a plug-in for Prototype (which is a
terrible script.) I'd avoid all of these like the plague. Using more
than one at a time is certainly madness.

[snip]

 

[David Mark]

Yes of course its not required
I wrote this because its usually a better practice to change a class
whereas changing directly the style in that your code becomes more
evolutive

I'am waiting for the day all frameworks will use the same semantic in
their widget so I can apply common css skins to datagrids or calendars
from any of YUI, ExtJS, Script.aculo.us, ...

so you could have it as a more unobtrusive code :

Warning:
 - Unfortunately, Firefox as a bug handling css on colgroups
 - it works nearly well on IE 8 (I don't understand why the table
width isn't reduced)

This code is just an example of good practices, but Browsers lacks
makes it a little more complicated
So don't hesitate to use well designed frameworks like JQuery or YUI

[snip]

Sorry, missed this before. The jQuery script is neither well-
designed, nor a framework. I'll concede that YUI is a framework.

 

[Eric Bednarz]

- Unfortunately, Firefox as a bug handling css on colgroups

What bug, which version? Doing a superficial test, the four CSS
properties that apply to col and colgroup elements work for me (if the
constraints are met).

 

[whygee]

What bug, which version? Doing a superficial test, the four CSS
properties that apply to col and colgroup elements work for me (if the
constraints are met).

I have the following problem with FF3.5.1 and others
(Opera and Seamonkey are worse), look yourself :
http://yasep.org/~whygee/colgroup.html
http://yasep.org/~whygee/colgroup_bork.html

One version displays correctly, the other preserves the border
of the hidden cells at the old place :-/

The only difference is the style of the main table :
<table style="border-collapse: collapse">

hope this helps,
yg

 

[Narda]

Evertjan. schreef:










also works in IE8 and FireFox3.5.1

This IS the best, simplest way of hiding columns... and easy to modify
to hide rows as well, thanks