-
Re: Upcoming TABLE Code Changes
Quote:
Originally Posted by
Seerow
I wonder, is there some way to get the vertical lines, but not horizontal? With the striped colors, the horizontal lines aren't as necessary, but without vertical lines the tables end up looking kind of cluttered.
Not exactly, to my knowledge, but here is the closest I’ve been able to achieve:
Spoiler: Vertical-lined table (-ish)
Show
Animal |
|
Vegetable |
|
Mineral |
Elephant |
|
Broccoli |
|
Feldspar |
Dolphin |
|
Chestnut |
|
Corundum |
Cheetah |
|
Okra |
|
Quartz |
Mako |
|
Avocado |
|
Kimberlite |
Macaw |
|
Snap Peas |
|
Basalt |
Monarch |
|
Daffodil |
|
Granite |
I agree it would be great if there were a vertical_grid table class (and a horizontal_grid class too for that matter), but the tables as they currently exist are certainly quite useable and flexible.
Quote:
Originally Posted by
Seerow
After preview: looks like Colspan works beautifully with it. It sorts by the first column that it affects rather than causing any funky results like switching cells around to put them in order. Perfect.
That is not quite how colspan interacts with sortable headers. The nth header cell sorts by the nth column, regardless of colspan. So in the following table, the last header cell (being the third of them) sorts by the middle column (which is the third column), even though the first two header cells each have colspan: 2.
Spoiler: Vertical-lined table (-ish) with colspan
Show
Animal |
Vegetable |
Mineral |
Elephant |
|
Broccoli |
|
Feldspar |
Dolphin |
|
Chestnut |
|
Corundum |
Cheetah |
|
Okra |
|
Quartz |
Mako |
|
Avocado |
|
Kimberlite |
Macaw |
|
Snap Peas |
|
Basalt |
Monarch |
|
Daffodil |
|
Granite |
Also note that the second header cell there (as well as either of the blank interstitial pseudoheader cells in the first table) have their “sort” arrows act by reversing the current order of the rows, regardless of whether or not they are currently sorted by any other criterion.
Edit: new discovery, almost certainly of no good use (probably not of neutral use either):
Spoiler: Vertical-lined table (-ish) that refuses to sort
Show
Animal |
|
Vegetable |
|
Mineral |
Elephant |
|
Broccoli |
|
Feldspar |
Dolphin |
|
Chestnut |
|
Corundum |
Cheetah |
|
Okra |
|
Quartz |
Mako |
|
Avocado |
|
Kimberlite |
Macaw |
|
Snap Peas |
|
Basalt |
Monarch |
|
Daffodil |
|
Granite |
Edit 2: If you don’t mind losing the ability to sort rows, you can also make a table of one-column tables:
Spoiler: Vertical-lined table (no sorting possible)
Show
Animal |
Elephant |
Dolphin |
Cheetah |
Mako |
Macaw |
Monarch |
|
Vegetable |
Broccoli |
Chestnut |
Okra |
Avocado |
Snap Peas |
Daffodil |
|
Mineral |
Feldspar |
Corundum |
Quartz |
Kimberlite |
Basalt |
Granite |
|
Also, I just found a bug of sorts. If you put a table inside a table and make the inner table wider than the column it’s in, it almost works, except the sort arrows float on top:
Spoiler: Vertical-lined table (-ish) with minitable bug
Show
Animal |
|
Vegetable |
|
Mineral |
Elephant |
|
Broccoli |
|
Feldspar |
Dolphin |
|
Chestnut |
|
Corundum |
Cheetah |
|
Okra |
|
Quartz |
Mako |
|
Avocado |
|
Kimberlite |
Macaw |
|
Snap Peas |
|
Basalt |
Monarch |
|
Daffodil |
|
Animal |
Vegetable |
Mineral |
Elephant |
|
Broccoli |
|
Feldspar |
Dolphin |
|
Chestnut |
|
Corundum |
Cheetah |
|
Okra |
|
Quartz |
Mako |
|
Avocado |
|
Kimberlite |
Macaw |
|
Snap Peas |
|
Basalt |
Monarch |
|
Daffodil |
|
Granite |
|
-
Re: Upcoming TABLE Code Changes
So, for everyone interested I made a thread wanting to showcase/highlight/explain all what the new table code can do.
It is located here.
If you have anything to add or to say (some tag is missing, some things are inconstant with what your browser does, you have a awesome example to share, ...), feel free to stop by and post something about it. I want this to be as accurate and useful as possible.
-
Re: Upcoming TABLE Code Changes
So, I've just changed how table sorting works. I think this works a lot better. No resizing of the table when you sort, no floating shenanigans, and no being hidden behind objects. It also looks nicer too.
Let me know if you run into any problems with it.
-
Re: Upcoming TABLE Code Changes
After I click on a header there are two sort arrows coming up, one black and one in the color of the text.
-
Re: Upcoming TABLE Code Changes
Quote:
Originally Posted by
Prime32
After I click on a header there are two sort arrows coming up, one black and one in the color of the text.
Clean your cache (empty your temporary internet files) and let me know if it continues.
-
Re: Upcoming TABLE Code Changes
Quote:
Originally Posted by
Rawhide
So, I've just changed how table sorting works. I think this works a lot better. No resizing of the table when you sort, no floating shenanigans, and no being hidden behind objects. It also looks nicer too.
Let me know if you run into any problems with it.
Much better! I experience no odd behaviour now.
For my mobile device I needed to clear my cache to get it to work, so before reporting problems clearing your cache might solve it.
-
Re: Upcoming TABLE Code Changes
So lets see...
Spoiler: Vertical-lined table (-ish) with colspan
Show
Animal |
Vegetable |
Mineral |
Elephant |
|
Broccoli |
|
Feldspar |
Dolphin |
|
Chestnut |
|
Corundum |
Cheetah |
|
Okra |
|
Quartz |
Mako |
|
Avocado |
|
Kimberlite |
Macaw |
|
Snap Peas |
|
Basalt |
Monarch |
|
Daffodil |
|
Granite |
Also note that the second header cell there (as well as either of the blank interstitial pseudoheader cells in the first table) have their “sort” arrows act by reversing the current order of the rows, regardless of whether or not they are currently sorted by any other criterion.
-
Re: Upcoming TABLE Code Changes
I have no idea what you're trying to do there, but I will remind you of one thing:
Do not use colspan with sortable tables!
-
Re: Upcoming TABLE Code Changes
Quote:
Originally Posted by
Rawhide
sortable tables
Since these apparently sneaked up on me, let me proclaim my heartfelt gratitude for you managing to make this happen.
-
Re: Upcoming TABLE Code Changes
While not perfect, tables should look much nicer on the mobile theme now.
Sortable tables are currently still main theme exclusive.
-
Re: Upcoming TABLE Code Changes
I've added three new classes:
borderless |
Not needed if you don't set any other classes, borderless can remove borders from classes that don't set borders (e.g. the two below) so that the borders otherwise behave like they are in a classless society table |
no_line_padding |
Removes top and bottom padding |
no_side_padding |
Removes left and right padding |
Note: borderless might be removed later as I play around with the CSS, but only if it becomes unnecessary. It won't destroy your table layouts having it in there if it is removed, however (it will just be ignored).
-
Re: Upcoming TABLE Code Changes
Quote:
Originally Posted by
Rawhide
I've added three new classes:
borderless |
Not needed if you don't set any other classes, borderless can remove borders from classes that don't set borders (e.g. the two below) so that the borders otherwise behave like they are in a classless society table |
no_line_padding |
Removes top and bottom padding |
no_side_padding |
Removes left and right padding |
Note: borderless might be removed later as I play around with the CSS, but only if it becomes unnecessary. It won't destroy your table layouts having it in there if it is removed, however (it will just be ignored).
Nice to see more options. Though I'm not sure whether borderless works as intended. In combination with alt1/alt2/head it doesn't work correctly:
Header 1 |
Header 2 |
Cell 1 |
Cell 2 |
Cell 3 |
Cell 4 |
Cell 5 |
Cell 6 |
Cell 7 |
Cell 8 |
|
Header 1 |
Header 2 |
Cell 1 |
Cell 2 |
Cell 3 |
Cell 4 |
Cell 5 |
Cell 6 |
Cell 7 |
Cell 8 |
|
Header 1 |
Header 2 |
Cell 1 |
Cell 2 |
Cell 3 |
Cell 4 |
Cell 5 |
Cell 6 |
Cell 7 |
Cell 8 |
|
Big thank you for keeping improving the table code :smallsmile:
(If others want to see tables with the new options, I have posted some in my thread I curate to showcase the table code.)
EDIT: It seem to work a bit different on the mobile site version:
- "no_line_padding" and "no_side_padding" have no impact (since the default tables have no panning to remove)
- "borderless" with "alt1" and "alt2" show no borders (but "alt1" and "alt2" alone doesn't have borders, so that is no surprise)
-
Re: Upcoming TABLE Code Changes
Quote:
Originally Posted by
ChristianSt
Nice to see more options. Though I'm not sure whether borderless works as intended. In combination with alt1/alt2/head it doesn't work correctly:
Yeah, it is. borderless doesn't strip borders from a table, borderless just starts you with a blank slate from which borders can be added.
Quote:
Originally Posted by
ChristianSt
It seem to work a bit different on the mobile site version:
Yes, tables don't look 100% the same on the mobile theme at the moment. Tables do look a lot better than originally implemented, and as they are now very close and look "good enough", trying to get close to 100% same appearance is of a lower priority to other features (including sortable tables on the mobile theme).
Honestly, it's a case of diminishing returns now. Struggling to get the CSS working as close to the same as possible across all browsers in all themes at this point takes more and more time to change smaller and smaller differences.
-
Re: Upcoming TABLE Code Changes
I didn't want to imply that you should try to make desktop and mobile site work exactly the same. It is probably not really possible without locking ugly on either version (especially with the panning feature). The mobile versions looks good, and I'm personally fine with it as is. [Though honestly I'm not a big fan of mobile sites normally, so even on my mobile phone I use the desktop version].
And I only said something about it since the interaction with alt1/alt2 and borderless seems to be somewhat bugged (i.e. removing the inner vertical borders, but not any others). If you say that it isn't intended to combine those then I take it as it is. (Though honestly I would find "borderless" more intuitive it it could remove borders from alt1 alt2 and head, too.)
That was also the reason for mentioning the mobile site differences: If this is a bug a want to fix, additional information might be helpful.
-
Re: Upcoming TABLE Code Changes
I'm not upset, I'm just explaining what and why.
-
Re: Upcoming TABLE Code Changes
I'm suddenly having a problem with alt1 and grid or thick_grid when making tables (specifically, [table="class:grid alt1 thick_grid"]). What's odd is it is only a problem for new tables I am making, with prior ones I made still looking like they are supposed to. (this turned out to be incorrect, see below)
First off, I tried this on both Safari 7 (Mac OS X 10.9.3) and Chrome (35.0.1916.153) and an ancient version of Firefox that I keep around for legacy purposes (6.0), all of this on my desktop computer.
I tried to post a table similar to the following:
Spoiler
Show
|
Comic Number |
Votes Received |
Vote Percentage |
|
|
441 |
0 |
0.00 |
|
|
442 |
1 |
4.17 |
|
|
443 |
1 |
4.17 |
|
|
444 |
0 |
0.00 |
|
|
445 |
4 |
16.67 |
|
|
446 |
1 |
4.17 |
|
|
447 |
0 |
0.00 |
|
|
448 |
3 |
12.50 |
|
|
449 |
14 |
58.33 |
|
|
450 |
0 |
0.00 |
|
It is supposed to look like the table in this post: https://forums.giantitp.com/showthread.php?p=17612873
Instead it comes out like above.
ADDED NOTE AFTER INVESTIGATING FURTHER:::: I just went and checked on another computer and it looks like my old tables ARE broken elsewhere, so I think my main computer is displaying an old cached version of the table. This is what the table is supposed to look like:
http://i8.photobucket.com/albums/a35...b.png~original
If I try them singularly, it still works:
Spoiler
Show
|
Comic Number |
Votes Received |
Vote Percentage |
|
|
441 |
0 |
0.00 |
|
|
442 |
1 |
4.17 |
|
|
443 |
1 |
4.17 |
|
|
444 |
0 |
0.00 |
|
|
445 |
4 |
16.67 |
|
|
446 |
1 |
4.17 |
|
|
447 |
0 |
0.00 |
|
|
448 |
3 |
12.50 |
|
|
449 |
14 |
58.33 |
|
|
450 |
0 |
0.00 |
|
Spoiler
Show
|
Comic Number |
Votes Received |
Vote Percentage |
|
|
441 |
0 |
0.00 |
|
|
442 |
1 |
4.17 |
|
|
443 |
1 |
4.17 |
|
|
444 |
0 |
0.00 |
|
|
445 |
4 |
16.67 |
|
|
446 |
1 |
4.17 |
|
|
447 |
0 |
0.00 |
|
|
448 |
3 |
12.50 |
|
|
449 |
14 |
58.33 |
|
|
450 |
0 |
0.00 |
|
Spoiler
Show
|
Comic Number |
Votes Received |
Vote Percentage |
|
|
441 |
0 |
0.00 |
|
|
442 |
1 |
4.17 |
|
|
443 |
1 |
4.17 |
|
|
444 |
0 |
0.00 |
|
|
445 |
4 |
16.67 |
|
|
446 |
1 |
4.17 |
|
|
447 |
0 |
0.00 |
|
|
448 |
3 |
12.50 |
|
|
449 |
14 |
58.33 |
|
|
450 |
0 |
0.00 |
|
But I can't seem to combine them anymore.
So I'm flagging this to see if something is wonky on my end, if I am doing something wrong, if something has changed and I wasn't aware of it, or if it is a possible board issue you should be aware of. :smallsmile:
-
Re: Upcoming TABLE Code Changes
I'm having a similar problem. The [ table="class:head alt1 alt2" ] tag used to produce a table with a dark brown header and white text, with outlined cells that alternated between light and moderate brown. Now it produces a table with no background colors, and where only the header is outlined.
Like so. |
Like so. |
Like so. |
Like so. |
Like so. |
Like so. |
-
Re: Upcoming TABLE Code Changes
I'm seeing the same problem with the tables in The Index of the Giant's Comments, and the last post changes were over a week and a half ago. Like Porthos indicated, using a single table CSS class works fine; and like zimmerwald1915 is showing, attempting a combination of table classes results in the default table formatting.
My offhand/uninformed guess is that for whatever reason, the style parsing is trying to read the space-separated lists of CSS class names as a single class name, and since there isn't an exact match for that name no CSS class is applied.
-
Re: Upcoming TABLE Code Changes
Lets have a look:
Spoiler: Sample ten-level prestige class
Show
Level |
Base Attack Bonus |
Fort Save |
Ref Save |
Will Save |
Special |
Spells |
1st |
+0 |
+0 |
+0 |
+0 |
Class Ability |
+1 level of existing spellcasting class |
2nd |
+1 |
+0 |
+0 |
+3 |
Class Ability |
+1 level of existing spellcasting class |
3rd |
+1 |
+1 |
+1 |
+3 |
Class Ability |
+1 level of existing spellcasting class |
4th |
+2 |
+1 |
+1 |
+4 |
Class Ability |
+1 level of existing spellcasting class |
5th |
+2 |
+1 |
+1 |
+4 |
Class Ability |
+1 level of existing spellcasting class |
6th |
+3 |
+2 |
+2 |
+5 |
Class Ability |
+1 level of existing spellcasting class |
7th |
+3 |
+2 |
+2 |
+5 |
Class Ability |
+1 level of existing spellcasting class |
8th |
+4 |
+2 |
+2 |
+6 |
Class Ability |
+1 level of existing spellcasting class |
9th |
+4 |
+2 |
+2 |
+6 |
Class Ability |
+1 level of existing spellcasting class |
10th |
+5 |
+3 |
+3 |
+7 |
Class Ability |
+1 level of existing spellcasting class |
-
Re: Upcoming TABLE Code Changes
I'm also having the same problem today. This code: [TABLE="class: head alt1 alt2 thick_outer_border_grid sortable"] suddenly isn't behaving. Even if I quote a post that has the desired table design, mine is rendered differently. I'm using Chrome, which hasn't given me trouble recently.
-
Re: Upcoming TABLE Code Changes
It's not just you-most of the table functionality seems to have disappeared. I'd better go and check my older posts..:smallfurious:
-
Re: Upcoming TABLE Code Changes
The tables appear to display correctly as long as the post hasn't been created or edited since the problem arose... looks like today that this started. Tables in my older posts seem to display fine, but those I've edited today have reverted to the basic style.
-
Re: Upcoming TABLE Code Changes
Quote:
Originally Posted by
Aedilred
The tables appear to display correctly as long as the post hasn't been created or edited since the problem arose... looks like today that this started. Tables in my older posts seem to display fine, but those I've edited today have reverted to the basic style.
I've checked several of my old tables and they are all incorrectly being displayed, even though I haven't edited them today. Could be a browser cache thing at work on your end, perhaps.
-
Re: Upcoming TABLE Code Changes
This is a bug introduced by a recent fix applied to the forums and will be fixed. What it fixed is too important to simply revert, but it will be fixed as soon as it can be resolved.
It needs no further reporting, but thanks for the reports you have already given.
-
Re: Upcoming TABLE Code Changes
I also encountered this just now, while editing my homebrew. I took a look at this table guide thread for comparing different table types depending on class combinations.
From what I conclude, any combination of "Head", "Alt1", and "Alt2" class values will default into a "Borderless" class. that ignores all other class parameters (even ones such as padding and sortability). Not sure specifically why that happens, but I'm just posting this in case anyone wants to immediately fix their tables' aesthetics. (That is, avoid combining those three class values)
-
Re: Upcoming TABLE Code Changes
As a workaround it seems possible to limit the number of table classes used for a table to one class. Since head, alt1 and alt2 aren't really problematic to emulate, I think most tables could be rewritten manually if this persists longer.
This tables emulates how old tables |
can |
be created |
without using |
more than |
one class |
though it increases the character count and is not as easy to change - which is certainly of concern for some threads using large tables.
Spoiler: Code
Show
Code:
[table="class:grid"]
[tr]
[th="bgcolor:#8E5A2E, align:center"][color=#FFFFFF][b]This tables emulates how old tables[/b][/color][/th]
[th="bgcolor:#8E5A2E, align:center"][color=#FFFFFF][b]can[/b][/color][/th]
[/tr]
[tr]
[td="bgcolor:#F0E7D3"]be created[/td]
[td="bgcolor:#F0E7D3"]without using[/td]
[/tr]
[tr]
[td="bgcolor:#DCCDAD"]more than[/td]
[td="bgcolor:#DCCDAD"]one class[/td]
[/tr]
[/table]
(If it doesn't get fixed soonish, I will update my thread to acknowledge this problem.)
-
Re: Upcoming TABLE Code Changes
Hi guys, as said, this is now a known issue (as of my last post, it wasn't known before then, so thanks again for reporting it). It will be fixed and we do apologise for the inconvenience.
-
Re: Upcoming TABLE Code Changes
hey rawhide, would it be possible to see a few classes for TH & TD that can override one cell's outside thickness?
EX: regular on all sides but one is thick like the left, right, top or bottom or even make a side borderless.
-
Re: Upcoming TABLE Code Changes
So when will this annoying bug be fixed?
-
Re: Upcoming TABLE Code Changes
Quote:
Originally Posted by
Southern Cross
So when will this annoying bug be fixed?
When it's fixed.