Search code examples
slickgrid

Why does slickgrid add 1000px in JS, then reverse it in CSS style?

When calculating the avaialable space for headers, slickgrid carefully measures each column, then adds 1000.

function getHeadersWidth() {
  var headersWidth = 0;
  for (var i = 0, ii = columns.length; i < ii; i++) {
    var width = columns[i].width;
    headersWidth += width;
  }
  headersWidth += scrollbarDimensions.width;
  return Math.max(headersWidth, viewportW) + 1000;
}

When it puts it in the DOM, this 1000 is reversed out with CSS:

$headers = $("<div class='slick-header-columns' style='left:-1000px' />").appendTo($headerScroller);

You can see this live in this example, just inspect the .slick-header-columns element.

What I would like to know is, why? What does this css trick do?

Solution

  • git bisect delivers the answer:

    https://github.com/mleibman/SlickGrid/commit/c299a5628c791a3b3cb390a22312eb2247b07cd5

    Author: David Lee

    Date: Fri Mar 12 07:39:02 2010 +0800

    Comment:

    Improve column reorder behavior

    Compatible with jquery-ui 1.8rc3

    Columns can be dragged beyond the left edge, as can be done beyond the right edge, so that columns can be dragged to the leftmost position, even if the distance from the column's left edge to the initial mousedown is greater than the distance between the left edge of the grid and the midpoint of the previous leftmost column.

    Notes:

    1. The rationale is this:

      When you reorder the columns using the jQuery UI 'sortable' component, you, the user, can drag a column to the left and the leftmost column will move aside to give you room to preview the reorder action: that means columnn 0 will be, at least temporarily, positioned in negative coordinate space (left @ -columnwidth, right @ 0px=left viewport edge).

      Since SlickGrid allows for arbitrary width columns, which may be changed during the grid lifetime, David Lee (the author of the edit merged by Michael Leibman) apparently (I assume here; I didn't check his pull request or other source datums) used a worst-case column width assumption of 10000 pixels (see the c299 commit) to give the SlickGrid init code a one-size-fits-all setup/init.

      See the next note for the commit when Michael Leibman changed this to the current -1000px value.

    2. I had the same question for quite a while and couldn't find why -- earlier git bisect attempts misled me to https://github.com/mleibman/SlickGrid/commit/f2d480ce959b9f8504f718d6f7a825782d488415 which only changes the negative offset by a decade, while I did not know SlickGrid internals well enough back then to confidently set up a proper git bisect to hunt this one down. (The real change was done back in the SlickGrid 1.x series and there was a lot of code changed then)

      Only now that I took out the -1000px myself and noted the column reordering getting worse, did git bisect help me dig up the relevant bit of history.

    3. Off topic: using git bisect taught me once again that git considers bad to be 'the new situation' and git bisect good to represent the old situation: I had to remind myself this while using git bisect as here the old situation (when the -1000px/-10000px code was not part of SlickGrid yet) was the 'bad' situation, at least to my mind. I.e. git bisect bad ~ 'this is like the new situation; git bisect good ~ 'this looks like the old situation'.