missing local variable declaration was causing collision with global
"item" variable in IE
Merge pull request #1 from karger/2013-02-25_local_var

missing local variable decl was causing collision with global "item" var in IE
A regression lost ISO8601 date conversion in google spreadsheet converter.
Also fixed a comma that was breaking IE.
Merge pull request #2 from karger/2013-03-07_dateTime

A regression lost ISO8601 date conversion in google spreadsheet converter
global replace .attr("class") with .addClass to preserve preexisting classes
Modified viewpanel to render views inside the tags that specify them.

Previously, views were rendered in a separately created
"view container" that was not a child of the tag specifying the view.
Thus, attributes specified on the view tag (e.g. classes for styling)
would not apply to the rendered view.  Which made it more difficult
for an author to style those views.  In the new version, the view
container is placed inside the tag that specified the view.

If the selected view was defined programmatically, rather than by a
tag, then the view container is placed as an immediate child of the
view panel tag.

This new approach is still imperfect.  To render a view,
the viewpanel empties the target div, which destroys contextual
information such as lenses intended for the view.  For standalone
views this is ok, as the view is rendered only once.  However, the
viewpanel re-creates a view each time that view is selected; the
second rendering will no longer have the context.  To circumvent this
problem, a new div is created inside the view tag to hold the rendered
view.  Thus, when it is emptied for the next rendering, the remaining
content of the view tag is undisturbed.

On the downside, this means that standalone views render in a slightly
different way than views in viewpanels---those in viewpanels are
nested inside a view container that is not present in standalone
views.  However, this is still a significant improvement over the previous
approach, where the rendered view was not inside the viewtag at all.

Longer-term, it seems beneficial for every view to render its content
inside a newly-created, nested view container div.  This would
provide consistency while still shielding the rendering and the
original specification-content of the view tag from each other.
bugfixed history mechanism

eraseState was pushing an invalid empty state
and viewPanel constructor was trying to switch to historic state
index, even if no view with that index actually exists.
Merge pull request #3 from karger/2013-03-16_addClass

glob replace .attr("class") with .addClass to preserve preexisting classes
Merge pull request #5 from karger/2013-03-17_bugfix_history

bugfixed history mechanism
Bugfix: wasn't adding a slot for newly created view
Bug: getURLWithoutQueryAndHash wrong if url's ? and # in wrong order
Bad hack to fix history system on ie9 and other old browsers.
The history mechanism is currently failing in ie9.

In particular, in ie9 the "statechange" event is not being triggered
when it should be (facet selection, viewpanel changes).  I have
therefore introduced the following hack: modified exhibit's
"statelistener" to also listen for the more old-fashioned "hashchange"
event.  However, to prevent "double counting", if a statechange event
is ever fired, then the listener for the hashchange event is turned off.

I've introduced the hack because I don't understand enough about the
history library jquery is using to make a more correct fixed.

The problem appears to be rooted in jquery.history.js , a library
for history management that is included in exhibit
(http://github.com/browserstate/history.js).  This library purports to
offer a uniform approach to history management on browsers both new
(which use the html5 "statechange" event) and old (which rely on an
older mechanism that tracks state view a fragment identifier in the url,
and a "hashchange" event that is triggered when the fragment changes).

Apparently the history library provides emulation, triggering the
"statechange" event even on old browsers.  This allows applications to
uniformly rely on the statechange event, even on old browsers.  Which
is what exhibit does: it rerenders whenever a statechange event is
triggered.

Except, it doesn't seem to be working as intended with exhibit on ie9.
ie9 is an old browser, so html4 emulation is used.  In the file
history.html4.js, the pushstate function engages in some mysterious
logic as it decides whether or not to actually trigger the statechange
event.  In particular, when invoked as a result of exhibit calling
pushstate,  it tests for (newStateHash !== html4Hash &&
newStateHash !== History.getShortUrl(document.location.href)) and,
finding this test to be satisfied, returns early without triggering
the statechange event.  I have been unable to find any documentation
of jquery.history.js, so am unable to determine whether this is a bug
in jquery.history.js or expected behavior/a bug in exhibit.
Merge branch '2013-03-24_urls' of github.com:karger/exhibit
Merge pull request #7 from karger/2013-07-24_bugfix_hack_history

Hack to fix history mechanism in ie9
Merge pull request #4 from karger/2012-03-17_view-panel

Modified viewpanel to render views inside the tags that specify them.