Javascript Toolbox - Table Sort utility - Column Width cannot be set.

[gandalfrat]

Can anyone help me out with a problem with Matt Kruse' Javascript
toolbox script for table sort/filter?

I've got a flat spot on my forehead from the following problem:

Here's the issue:

The script works very nicely with the exception that it does the
following things:

1. The columns with filters all seem to expand to the width of the
longest entry in their column.
2. Columns with no filters get the leftovers.

Here's the example: http://oldsaw.org/temp/tbl_test/bheaclass.php

the th directive seems to be ignored (<th width="60%">Description</
th>)

The scripts are posted here and there's no doc info related to column
width settings: http://www.javascripttoolbox.com/lib/table/

It's an awesome utility... I'm just stuck.

PM'd Matt a couple of times, made a donation. No info.

Thanks for any assistance anyone can provide. Hopefully not a
neophyte mistake.

GR

 

[Thomas 'PointedEars' Lahn]

Can anyone help me out with a problem with Matt Kruse' Javascript
toolbox script for table sort/filter?

Yes, definitely: Matt. He is somewhat of a regular contributor here,
and has posted recently, so you may be lucky.

However:

[...]
The script works very nicely with the exception that it does the
following things:

1. The columns with filters all seem to expand to the width of the
longest entry in their column.
2. Columns with no filters get the leftovers.

Here's the example: http://oldsaw.org/temp/tbl_test/bheaclass.php

the th directive seems to be ignored (<th width="60%">Description</
th>)

It is not a directive, but an element, and the W3C Markup Validator shows
60(!) errors for your generated markup (I did not even have to go there to
see it, thanks to the Web Developer extension for Firefox).

[...]
PM'd Matt a couple of times, made a donation. No info.

Perhaps your e-mails were filtered out as spam, or he ignored you because
of that beginner's mistake.

Thanks for any assistance anyone can provide.

You're welcome.

Hopefully not a neophyte mistake.

Unfortunately, it is.


PointedEars

 

[gandalfrat]

It is not a directive, but an element, and the W3C Markup Validator shows
60(!) errors for your generated markup (I did not even have to go there to
see it, thanks to the Web Developer extension for Firefox).

<http://validator.w3.org/check?uri=http://oldsaw.org/temp/tbl_test/bhe....>

Thanks. 58 of the 60 were related to having deleted an "echo <tr>" in
the loop reading the file and building each row in the table. All
those are gone. I stil have a couple of XML validation errors but...
is that related to column width issues?

[...]
PM'd Matt a couple of times, made a donation.  No info.

Perhaps your e-mails were filtered out as spam, or he ignored you because
of that beginner's mistake.

Thanks for any assistance anyone can provide.

You're welcome.

Hopefully not a neophyte mistake.

Unfortunately, it is.

Any chance you can give me some pointers on which direction to look
for the column width issue?

The th element is used in several of Matt's examples on the page.
You're right, I mistakenly took it for the deprecated th directive.

I have also tried CSS manipulation of the column widths. font color
and background changes all seem to work with the application of a
style but "width" statements are ignored.

Thanks again for pointing out the above.

GR

 

[Scott Sauyet]

The script works very nicely with the exception that it does the
following things:

1.  The columns with filters all seem to expand to the width of the
longest entry in their column.
2.  Columns with no filters get the leftovers.

As Thomas noted, Matt might well chime in here, but looking at the
generated page, my first thought would be to assign a width in CSS to
the SELECT elements in the header:

select.table-autofilter {width:100px;}

That might be all it takes, but I can't say I've tested in anything
except FF/Firebug.

-- Scott

 

[Thomas 'PointedEars' Lahn]

Thanks. 58 of the 60 were related to having deleted an "echo <tr>" in
the loop reading the file and building each row in the table. All
those are gone. I stil have a couple of XML validation errors

For one, you have a `tfoot' element after a `tbody' element. Strange as it
may sound, the order needs to be reversed. And you really should not be
serving XHTML as text/html; serve HTML as text/html instead.

but... is that related to column width issues?

Very likely, yes. If the user agent cannot reliably determine where the
next row begins, a DOM script would have a hard time finding the cells
which belonged to the same column.

Does it still not work as you expect after you have fixed the markup?
And try HTML instead.

Any chance you can give me some pointers on which direction to look
for the column width issue?

You should make your markup fully Valid first.

The th element is used in several of Matt's examples on the page.
You're right, I mistakenly took it for the deprecated th directive.

"Deprecated th directive"?

I have also tried CSS manipulation of the column widths. font color
and background changes all seem to work with the application of a
style but "width" statements are ignored.

CSS is no programming language either. Those are _property declarations_.
And CSS issues are best discussed over at
comp.infosystems.www.authoring.stylesheets, with a clear problem
description and a reduced test case. Chances are that building the test
case helps you to solve the problem by yourself.


PointedEars

 

[Matt Kruse]

Can anyone help me out with a problem with Matt Kruse' Javascript
toolbox script for table sort/filter?

As others have noted, I am here

1.  The columns with filters all seem to expand to the width of the
longest entry in their column.
2.  Columns with no filters get the leftovers.

This is just the nature of HTML.

the th directive seems to be ignored (<th width="60%">Description</
th>)

Not ignored, just overridden by other things. If you make your font
really, really small or your screen really wide, you'll see that the
description column does indeed take up about 60% of the width.

Unfortunately for you, if you have content in a cell that cannot be
squished or wrapped, the cell _must_ expand to be wide enough to
support the content. Since the select dropdowns are wide and cannot be
wrapped, their columns will always be wide enough to fit them.

Think of it this way - if you were to expand the Description column to
be a full 60% width, what do you think should happen to the other
columns with the wide select dropdowns? Should they scroll? Be
clipped? Should content just disappear?

You do have some options:
1) Change the js source so that the selects cut off the text after an
arbitrary number of characters
2) Put a css width on the selects themselves, causing the remaining
text to be clipped (this won't work in all browsers, btw)
3) Set an explicit width on the TH cells, and set the style
overflow:hidden; so that the cell will not be made wider
4) Change the font size in the select lists using css
5) Switch to text input filters instead of select lists

PM'd Matt a couple of times, made a donation.  No info.

I get over 1,000 junk mails a day and I have aggressive filters set
up. I also cannot being to respond to all the valid email I get in a
day. If your messages were spammed or not answered, I apologize. I do
try to always answer questions asap from those who are kind enough to
donate

Hope that helps!

Matt Kruse

 

[gandalfrat]

Appreciate everyone's input. Lots of things to try. Clearly in a
little over my head. I wanted to use the utility because I couldn't
roll my own. It worked well for simple use cases. This example where
I need a little more control over layout is definitely highlighting
some weaknesses in my understanding of CSS. Thanks for the pointer on
where to take those q's. Thanks too for the details on what to try...
that's really what I needed to get moving again.

Matt Kruse said:

3) Set an explicit width on the TH cells, and set the style
overflow:hidden; so that the cell will not be made wider

ah. the overflow:hidden is why I couldn't get the other cells to
budge. got it.

Matt Kruse said:

You do have some options:
1) Change the js source so that the selects cut off the text after an
arbitrary number of characters
2) Put a css width on the selects themselves, causing the remaining
text to be clipped (this won't work in all browsers, btw)
3) Set an explicit width on the TH cells, and set the style
overflow:hidden; so that the cell will not be made wider
4) Change the font size in the select lists using css
5) Switch to text input filters instead of select lists

I was hoping to figure out some way of basing the filter list on a
column of short text ("keys" if you will) but then displaying the long
text (wrapped) in the cells below.

Think of it this way - if you were to expand the Description column to
be a full 60% width, what do you think should happen to the other
columns with the wide select dropdowns? Should they scroll? Be
clipped? Should content just disappear?

I ended up using Max Gugliemi's script from javascriptkit to pretty
much do that (scrunch pulldowns in other columns) -- his script is
parameter-driven and not stylesheet driven so it was easier to figure
it out. I feel that yours is superior in end-user usability and
provides cleaner output (duh. CSS)... but have to figure out the
styles side of it first.

BTW... if the filter list was a flyout like many menu controls,
couldn't it display long filter list entries over top of the other
columns (long text in the cells below would wrap per column width
settings).

I get over 1,000 junk mails a day and I have aggressive filters set
up. I also cannot being to respond to all the valid email I get in a
day. If your messages were spammed or not answered, I apologize. I do
try to always answer questions asap from those who are kind enough to
donate

Hope that helps!

Matt Kruse

Thanks Matt. I didn't look at many of the historical comments on the
usenet group to see that you still frequented this group... (last
"what's new" on JS Toolbox is 5/2009). My comment was less about
your response time (realizing you'd taken down the bulletin board on
your site because it was chewing up too much time) and more about
telling others I'd really followed up with you and didn't have an
answer so I was hoping people wouldn't send me back to RTFM when the M
didn't quite describe my use case.

p.s. the php Excel reader seems to have the same issue with large text
entries (http://code.google.com/p/php-excel-reader/issues/detail?
id=55) but for different reasons.