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
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...
1D arrays.
- The method implemented isn't actually 100% perfect - if you mix arrays
and scalars, then the behaviour is undefined. But that shouldn't
happen in DataTables. Will look into it further, though
- This is actually a little more complex than it might first appear
since any classes which have been added by DT_RowClass need to be
removed. We can't just bindly remove all classes, so we need to track
that classes have been added in a private variable.
- It appears that ti is impossible to know in CSS if a table doesn't
have a tfoot element reliably and cross browser, so I've added a class
which is added to the table automatically if the table has no footer
or the fotoer is empty to complete the styling of the table.
- Fixed error when there are no cells in an empty TR row in the footer.
- With the change to camelCase, it is easier to extend the usageof
optiosn now, and in this case I've allowed the `orderFixed` (formally
`aaSortingFixed` parameter to be passed in as an object as well as an
array. As an object the `pre` and `post` parameters are used to
specify prefix and / or postfix ordering. Useful for gouping.
- The _pluck() function that was being used to get the tr elements
didn't remove nulls, while jQuery doesn't like removing a class from!
- Thanks to `RagingTroll` in the forums for spotting this:
http://datatables.net/forums/discussion/18651
the property being expanded is an object or not. If not, then set it to
be an empty object which will be extended. Only really effected the
`ajax` property
Based on the discussion in the forms (
http://datatables.net/forums/discussion/18456 ) the fix from 8935b8a
wasn't good enough. What was happening was that the _save_data function
was doing a deep copy of all arrays (minus the data array) so the
default sort was stil applied.
The fix is to reinstate the _fnExtend function which does a jQuery like
deep extend on objects and a shallow extend on arrays. That is extended
slightly to allow array references to be broken on initialisation, to
resolve the issue 8935b8a attempted to (sorting array would be used for
two tables for example), by an optional parameter. This should resolve
the issue correctly this time!
