eevee/spline-pokedex — Issue #23: Some pokemon-moves tables are absolutely gigantic, making loading and JS filtering/sorting very slow
Author: encukou
Created: 2012-01-26 22:04:26+00:00
State: open

**Reported by [Anonymous](http://bugs.veekun.com/users/5) on 2010/05/05 02:32:01 +0000 · Migrated from [Redmine issue 253](http://bugs.veekun.com/issues/253)**

---

[Substitute](http://veekun.com/dex/moves/substitute#moves) is a good example. It has over eight hundred rows because it’s one of those moves that every Pokémon can learn except the handful with a restricted movepool, and it’s been both a TM and a tutor.

Original content:

> [http://veekun.com/dex/moves/substitute](http://veekun.com/dex/moves/substitute)

>

> Appears to be something broken on the Substitute page, the layout is a bit odd, the buttons used to choose the order of the tables won’t work and I get a ‘stop script’ notice.

Redmine metadata:
Updated on: 2010/09/27 18:21:42 +0000
Start date: 2010/05/05

---

**Comment by [Mystic](http://bugs.veekun.com/users/21) from 2010/05/05 05:16:24 +0000**

The table ordering buttons are (kinda) working, they’re just taking a really long time because the Pokémon table on that page has over 800 rows.

---

**Comment by [Sanky](http://github.com/sanky) from 2010/05/05 07:19:13 +0000**

Possibly change to “All except for…”?

---

**Comment by [Zhorken](http://github.com/zhorken) from 2010/06/07 15:45:20 +0000**

The layout being odd has been fixed—I don’t remember exactly what it was, but there was some bug that made some header rows too short or too long or something.

Updated subject

---

**Comment by [Zhorken](http://github.com/zhorken) from 2010/06/07 15:45:54 +0000**

Updated subject

---

**Comment by [Zhorken](http://github.com/zhorken) from 2010/06/07 15:46:07 +0000**

Project: veekun-incoming ⇨ spline-pokedex

---

**Comment by [Eevee](http://github.com/eevee) from 2010/08/14 15:42:06 +0000**

I did give those tables `table-layout: fixed`, which should help the client-side rendering significantly, both on initial render and when futzing with the JS controls. It asks the browser to use my requested column widths no matter what, rather than taking them as suggestions. Makes table rendering a lot simpler, thus a lot quicker.

Any noticeable impact?

---

**Comment by [Zhorken](http://github.com/zhorken) from 2010/09/27 18:21:42 +0000**

Doesn’t seem like it.