Merge remote-tracking branch 'remotes/pigiax/patch-1' into k0stya-rowspan
JSHint/JSCS happiness
fix crash: use startX/Y instead of pageX/Y in dragstart event!
fixup/update for the new header .l/.r classes: now named .hl/.hr to easily differentiate between these and their grid cell .r/.l equivalents.
also kill the timers in the plugins when they (or their slickgrid instance) are destroyed.
The new header/cell column resize logic which edits the .l/.r and .hl/.hr classes, turns out to be very fast (at least on a modern browser). This leads to the removal of the now obsolete `options.syncColumnCellResize` option as from now on it will be ALWAYS ON.

The plugins which addressed this option have adjusted accordingly.
tightened the formatter API as bit: CSS classes and CSS styles should be set via the `cellMetaInfo/rowMetaInfo.cellCss` and `ditto.cellStyles` arrays rather than patching them directly via `ditto.attributes.css` and/or `ditto.attributes.style` attributes of the same structure which is passed into the formatter: the latter (`.attributes`) is provided to allow custom formatters to tweak arbitrary HTML DOM node attributes (e.g. `data-xyz` attributes via `cellMetaInfo.attributes['data-xyz']='bugger millenium hand and shrimp';`) ... but not the DOM node's CSS classes or CSS styles.
onRenderStart event: allow userland code to abort or otherwise replace the grid render process at will (by calling e.stopPropagation() / e.preventDefault()); one use case is where complex application logic may allow the render() timeslice while the grid is in a temporary flux, e.g. a complex data update with semi-invalid state during that update process. Then you don't want the render() timeslice to kick in and crash in userland custom formatters, etc., but instead you want the render to hold off until the other process has completed and things have stabilized again enough to warrant a grid (re)render.
Fixed selected class is not applied to new columns
- fix bug in columnpicker: column select menu would list all columns twice.

- adjusted setActiveCellInternal() and gotoCell() interface: instead of multiple boolean parameters, now a single settings object is passed in: examples have been adjusted accordingly. This makes the latter public API (and the setActiveCellInternal() internal API as well) behave more in line with 'explaining variables' best practices: see also http://blog.ometer.com/2011/01/20/boolean-parameters-are-wrong/ & http://programmers.stackexchange.com/questions/161970/is-defining-a-variable-to-name-a-method-argument-a-good-practice & http://programmers.stackexchange.com/questions/147977/is-it-wrong-to-use-a-boolean-parameter-to-determine-behavior & http://martinfowler.com/bliki/FlagArgument.html

- reorganized the LESS theme file: `prefix &` appender usage is great ( https://github.com/SomMeri/less4j/wiki/Less-language-Nesting#appender & http://blog.slaks.net/2013-09-29/less-css-secrets-of-the-ampersand/ ) but we cannot use it ( thanks to there being no movement on https://github.com/less/less.js/issues/1075 to allow producing any kind of 'reduced' parent selector ) - the `slick-row` and `slick-cell` rules have been adjusted to ensure a `selected` or `active` row and cell is now visible

- also note that in relation to the above item, several fixes have been applied as the new colspan/rowspan feature implies that your `active` row (`activePosY`) is not necessarily identical to the `activeRow` of your `activeCellNode`: hence both navigation code and CSS styling now do not expect the `active-row` to always be the `activeRow` row: you may observe this corrected behaviour in the examples/example-0042-row-span.html example when navigating the grid: rowspanning cells can be 'active' while the actual 'active row' (tracked by `activePosY`) is not the top row of the current rowspanning cell: go to row 7 in the example and navigate left and right to observe that these new fixes now ensure that you stay on row 7 instead of being 'pulled up' to the top row of each of the rowspanning cells that you will visit and 'activate' while navigating left & right on that row.

- some examples showed that the minimal header row width enlargement (on scrollbar width' orth) is too small when the grid columns do not fill the available space, e.g. examples/example-0008-compound-editors.html: now the old slickgrid behaviour has been restored with a twist: the HEADER_ROW_WIDTH_CORRECTION constant defines the amount of extra width allotted to the right for each header/footer row.

- fixed bug where invalidating a row did not update the row DOM node attributes (classes, styles, etc.) on render; this was the main culprit why, for instance, selected rows would forever remain marked as selected -- until they disappear from view and later on may be completely regenerated, that is. Now the same 'metadata ~ attributes' processing methodology used for updating cell DOM nodes is also used for row DOM nodes.

- fixed bug where userland changes to a cells rowspan and/or colspan did not reflect properly in the rerender process: now the cleanup and update-on-dirty render process identifies DOM nodes lingering in the cache while they are now being overlapped by another colspan/rowspan-ing node: these nodes are now deleted. See examples/example-0042-row-span.html.

- fixed bug where userland rowheight changes did not reflect properly in the subsequent render/update process. See example-0042-row-span.html.

- augmented the getCellNodeBox() API to include rowspan/colspan info; this is used, for example, to produce corrected redraw range specs.

- ditto for getCellFromElement() API.

- as mentioned above, revisited the navigation code (goto* APIs) and applied several fixes (jumping over rows when gotoDown(), etc.); also fixes a crash due to a misunderstanding about the purpose of each field in the span object returned by these goto*() APIs.

- fixed a few crashes due to APIs being invoked by userland code using out-of-range row/cell coordinates.

- new public API: invalidateCellSpan() accepts a span (row/cell/rowspan/colspan) to invalidate; use this to invalidate a range of cells, e.g. following a selection range edit action.
Merge remote-tracking branch 'remotes/cdeng/master' into k0stya-rowspan: Fixed an issue where the selected class is not applied to new visible columns (mleibman/SlickGrid#1026)

Conflicts:
	controls/slick.columnpicker.js
updated github analysis script to find out which clones have actual work done in them
a plethora of fixes for grid invalidate/update/render, rowpan/colpan support, DataView fundamentals and aggregation/grouping support, examples' updates, etc.:

- fixed several render() glitches which were due to the slightly incorrect order of execution in the render() process which failed to properly update/refresh & complete the viewport at all times when rowspan/colspan cells are involved.

- fixed several issues related to the cellSpan cache, which caused SlickGrid to produce incorrect renders for grids when userland code fiddled with the colspan/rowspan metadata.

- added the new API `getCachedRowRangeInfo()` to help userland code drive and hint SlickGrid & DataView more correctly. The API returns the range of rows which are currently (at least partly) cached. These will be the rows range which must be invalidated if userland code does something drastic (e.g. when changing the grouping of the data: examples/optimizing-dataview)

- fix bugs in resizeCanvas() when the grid is not readily visible.

- fixed the DataView aggregation, grouping and collapsing issues: examples/example-0027-grouping.html now works as expected. Related to #896: one of the culprits was that the `range.bottom` value was *inside* the range (hence the +1 fix worked), while everywhere else a `.bottom` is considered '1 past the end' i.e. beyond the selected range.

- fix DataView lazy aggregation: `lazyTotalsCalculation`; for one, this fixes a crash in examples/example-0027-grouping.html

- DataView recalc(): cleanup: the function only accepts a single parameter anyhow

- DataView: added a new `getOptions()` API so userland code can obtain the actual options for this DataView instance.

- ditto for the GroupDataItemMetaProvider: : added a new `getOptions()` API so userland code can obtain the actual options for this MetaProvider instance.

- all aggregators now use exactly the same checks when the input data is expected to be numeric: we *skip* any NaN in the data, while we *accept* +/-Infinity as valid numbers.

- getCellFromPoint() and getCellFromEvent() now accept a `cfg` configuration/options object parameter where the caller can, for example, instruct SlickGrid to `clipToValidRange: true`, i.e. to always convert the given pixel coordinate to a valid cell/row reference by projecting onto and clipping to the legal grid area. This is an important addition when, for example, clicking in the canvas outside the rendered grid cells should produce a sensible row coordinate at least.

- getViewportWidth(): new API; currently identical to getContainerWidth() but this one at least conveys the correct notion/purpose.

- fix the click/doubleclick/rightclick catching and handling: even when clicking in the canvas but not hitting a rendered cell, then SlickGrid will catch the click and compute the addressed cell coordinate; this is particularly important now that we have delayed render() activity and thus *must* expect grid DOM nodes not to be present *yet* when the user 'aims' at a cell by clicking in the grid canvas.

- fix the click/doubleclick/rightclick event bubbling: do *not* fire the handlers *twice* any more: `signalEventObserved()` is the critical new part for this.

- extra: for the above we also added a new, simple, test page at tests/test-event-modification-transferability.html to check whether browsers support userland modification of the native event object. Chrome does so; we still have to test the others browsers though as signalEventObserved() currently depends on this behaviour where userland code tweaks the native event object and the browser then bubbles up the event including the user tweaks (i.e. browser feeds every registered handler along the event bubble path the same JavaScript event object instance)

- updateCanvasWidth() now implicitly render()s the grid when the changes imply such may be necessary: all the spots where updateCanvasWidth() is called do require a grid update via render() and this is the 'cleanest' way to ensure the render() happens at the right time, consistently. Previously some of the callers didn't invoke render, which had, for instance, the nasty effect that resizing columns (shrinking them) would move previously unseen columns into the viewport area but would *not* trigger a grid render() to update the grid accordingly. Such misbehaviour has been corrected now.

- the column headers are now rendered in a fashion similar to the grid itself, so that 'nested columns' are properly supported by allowing columns to span multiple (header) rows or columns: these characterisitcs are computed and stored in the column definition objects themselves as these attrbiutes:

  + headerRow: the 'header row index' into the `getColumnsInfo().lookupMatrix` 2D array

  + headerRowLayerIndexz: the 'header column index' into the `getColumnsInfo().lookupMatrix` 2D array

  + headerRowSpan

  + headerColSpan

- fix all header DOM node referencing logic to support the 'nested columns' feature by using the overhauled getHeadersColumn(), getHeaderRowColumn() and getFooterRowColumn() APIs internally.

- replaced and corrected the 'level' approach with a proper headerRow approach for the column headers: this way the code is more legible and it also fixes a few glitches alongside.

- fixed bad bug in the grid row render code which would use the wrong formatter for the grid row DOM node itself: now DataView et al are polled for the corect formatter.

- performance/cost: do not register separate drag and click handlers for each header column but instead treat that area like the grid canvas itself: only register single 'delegate' event handlers on the container (`$headerScroller`) instead

- added the new `onColumnCalcWidth` event which allows userland code to produce a suitable column width when the column resize DIV is doubleclicked: this means the grid is requested to 'auto size' that particular column and the built-in approach is merely an approximation; sophisticated grids benefit from having userland code provide a better 'auto sized' column width and then skip (stopPropagation/preventDefault) the built-in approximation.

- refactored the getVBoxDelta() / getHBoxDelta() code (the latter is an entirely new function as a result of this minimal refactoring action)

- grid improvement: use the new `invalidateColumn() / invalidateColumns()` APIs where applicable.

- fix: tighten up the handling of the `setOptions()` API invocation: check option changes and trigger recalculation/rerender activity where necessary.

- fix: `setOptions()` API now returns TRUE/FALSE whether the new options could be set or not; invoking `setOptions()` is illegal and nil when, for instance, a cell edit action is currently pending.

- fix: ensure that the columnsById[] mapping is a guaranteed reversible 1:1 relationship and that the column.id field is always set to something sensible. This fixes the situation where user column definition sets do not carry unique IDs for each of the columns. This is particularly apparent in scenarios where 'nested columns' are employed.

- validationtooltips pkugin: use tooltipster instead of the obsolete tooltipsy library. More work must be done here before this'll actually fly...

- fix crash situation in the RowMoveManager plugin

- updated the jquery-fixclick library

- fixed several examples to ensure they work with the latest SlickGrid incantation

- re-indexed the examples

- more JSHint/JSCS happiness
clean up my act regarding proper grid initialization in Chrome: we ourselves let the app (userland) code take care of this business via using the `options.explicitInitialization` option and calling finishInitialization() until it reports success, but that leaves all the other SlickGrid usage scenarios hanging: now the code runs a timer-based browser poll to ensure the init stage runs to guaranteed completion in case you do *not* have the option `explicitInitialization` set (setting that option implicitly tells SlickGrid that the userland code knows best and SlickGrid then should not bother trying to be 'smart' about this issue).

Either way, we now only fire the onAfterInit event when *everything* that is SlickGrid has really been properly and completely initialized, including the stylesheet setup that is bothering us all so much (see issue #223 and all related and linked there). The essence is that only applying #919 is not good enough; nor does https://github.com/tradingtechnologies/SlickGrid/commit/bf21472f2aa0c1f1b2278db591906c5b349fe557; nor is https://github.com/mleibman/SlickGrid/commit/d10eb9039dcce7b0b37e3a1ce05b44e3c165faa1 (which is the 'lazy get' that starts it all and is a good approach; however, guaranteed init success is only guaranteed when the browser gets some 'air' to include the new style node in the DOM properly, so a timer-based polling approach is called for as a last-ditch effort.

As part of this change we now feed back success/fail return values from any function which depends on these stylesheet access/updates to succeed: the code then uses these return status reports to determine whether a retry/poll is called for. (Again, this is assuming userland code didn't take full control of the situation by setting the option `explicitInitialization`!)
- upgraded the performance measurement utility object (Slick.PerformanceTimer) to provide a more powerful API.

- added a crude test page to measure user activity timings in the browser, e.g. the time it takes the browser to decode a mousedown+up as a click and/or doubleclick. This is mostly relevant for our jquery-fixclick library usage, but landed here as the observation is that click-to-visual-feedback-of-cell-activation is noticably delayed and we're looking into ways to get this resolved without reverting to the old trouble of click vs. doubleclick handling.
- updated the libraries

- JSHint/JSCS happiness
updated qUnit and other libs
updated submodules' registration scripts
HTML5 fix: Make every cell keyboard-focusable as per W3C spec ( https://html.spec.whatwg.org/#focus-management-apis ); without us setting a valid `tabindex` DOM node attribute any `cfg.takeFocus=true` config option for `setActiveCell()` et al will fail to deliver in Chrome 38.x and upwards, at least, as calling `.focus()` on a node which doesn't have this apparently keeps the focus (`document.activeElement`) stuck at BODY level :-(  -- also added assertions everywhere in the code to catch this problem when it's recurring.
Merge branch 'k0stya-rowspan' into gh-pages

Conflicts:
	.gitattributes