- This is caused due to different content in the displayed header and
the size forcing header in the body scrolling table. The browsers can
lay the two tables out differently even although the widths applied
are identical, due to the different content.
- The fix is to keep the content in the scroll body header, but hide it
by wrapping in a div which has height 0 and overflow hidden
- See thread 19311 for more information
server-side processing
- A popular plug-in for DataTables is the `fnSetFilteringDelay` plug-in,
which provides a bit of a buffer when typing into the filter input so
you don't make an Ajax request for every key stroke - i.e. don't DDoS
your own server!
- Since we have _fnThrottle built in now for the scrolling, we can also
use it to provide this buffering functionality for server-side
processing filtering in the core. A couple of small changes for
_fnThrottle were required to get the callback context correct and ot
call it not immediately, but only after the delay
footer
Update: Update CSS to display the table border properly when there is no
footer when scrolling
Dev: Update the _fnAddOptionsHtml function to be smaller in code size.
Identical functionality, just smaller code
fact that the table width attribute has been removed, but was being
applied to the table anyway, as 0px - causing the table to be as narrow
as possible. On the plus size, the columns kept their alignment with
such a misconfiguration! However, now the `width` option for columns is
correctly applied in x-scrolling tables.
don't need to look it up with inArray. Also the header renderer does not
pass in the column index now (the column.idx property can be used). This
is to allow operations such as ColReorder to reorder teh columns and
still have the renderers update correctly
- Column width is always a particularly difficult one to get quite
right. In this case, the fix is to have DataTables read column width
information from the `width` or `style` attributes of a column header
cell, if that information is present. If it is, it is treated as
sWidth is (although user supplied sWidth can override). That is it say
that it will be applied to the column width calculation table.
- The remaining gap is if a developer assigns a width using css classes.
We can't get that information, so we fall into the old problem.
- This change comes about from the discussion in
http://datatables.net/forums/discussion/19089 and the fiddle here:
http://jsfiddle.net/EysLd/1/
- What is happening in the test case is that the calculation table is
being created, but it is then stripped of widths due to this commit:
https://github.com/DataTables/DataTables/commit/6a9e324 . That was to
allow DataTables column headers to have their applied size removed, so
a new size could be calculated. Only sWidth would override that - now
the width and style attributes will as well
- IE8- requires that Function.prototype.apply be used with an array or
arguments object as the second parameter - it being "array-like" isn't
good enough.
- This fixes DataTables/DataTables #262
- Added new orthogonal data example
- Updated columns.data and columns.render documentation
- Reordering the manual a little
- Add note to the old orthogonal data blog post to direct people to the
new manual page
plug-ins
- A lot of plug-ins use _fnCalculateEnd and although all that is needed
in the upgrade is to remove it, since the value is calculated
automatically now, it will likely cause confusion and hassle. So I've
added this stub to prevent those errors.
- Chrome (V8) will incorrectly detect '$245.12' and similar as dates,
since V8 will strip unknown characters from a string given to
Date.parse and then attempt to parse the rest of the string - in the
example above: Dec, 245:
https://code.google.com/p/v8/source/browse/trunk/src/dateparser-inl.h#72
- The fix implemented to to check for a leading a-zA-Z, number or +-.
Although this isn't a perfect match for what Chrome does, it, I think,
a good enough effort to chatch nearly all particular use cases.
- Additionaly, V8 will try to parse a single number passed into
Date.parse - 1-12 are months, 32+ are years. As such, the numeric type
detection much be a highter priority than the date detection, since
Chrome might incorrectly use a column as a date. It would sort
correctly, but it isn't "correct".
- The take away from this is that Date.parse cannot be used for date
format validation on its own...
