christophergandrud / networkD3

D3 JavaScript Network Graphs from R
http://christophergandrud.github.io/networkD3
650 stars 269 forks source link

Whitespace (viewBox) around sankeyNetwork exported with saveNetwork #218

Open giocomai opened 6 years ago

giocomai commented 6 years ago

If I create any sankeyNetwork, export it as Html file, and open it in any browser, I see a substantial amount of whitespace around the graph. This makes it much smaller than the size in pixel I defined in the sankeyNetwork function and makes it terrible for use in documents or to be embedded as iframe.

Example:

library(networkD3)
library(magrittr)

URL <- paste0(
  "https://cdn.rawgit.com/christophergandrud/networkD3/",
  "master/JSONdata/energy.json")
Energy <- jsonlite::fromJSON(URL)
# Plot
sankeyNetwork(Links = Energy$links, Nodes = Energy$nodes, Source = "source",
              Target = "target", Value = "value", NodeID = "name",
              units = "TWh", fontSize = 12, nodeWidth = 30) %>%
  saveNetwork(file = 'Net1.html')

If (e.g. by pressing F12 in Firefox) I look at the output, I can remove the whitespace by deleting the Viewbox property of the svg.

There seems to be no easy way to accomplish the same in the output html file.

The only workaround I found is to saveNetwork() with selfcontained = FALSE, remove the viewBox part in sankeyNetwork.js, and uncomment the resizing part above of the same file.

This works. But shouldn't this be the default behaviour, or at least easily accessible through options? After all, I'd expect that the html output is mostly exported to be embedded somewhere else. Also, exporting with the current default, the output is effectively much smaller than what it should be according to the `height' and 'width' parameters set in sankeyNetwork.

cjyetman commented 6 years ago

The viewBox is there to facilitate resizing in a variety of contexts. It is a compromise between competing use cases, but it is not arbitrary. saveNetwork() simply wraps around htmlwidgets::saveWidget(), so there is currently no way for it to generate a different version of a sankey plot than what sankeyNetwork() generates. Of course it would be possible, but it would not be trivial... either two separate versions of the JavaScript would need to be maintained or there would need to be logic within the JavaScript to decide when or not to use viewBox.

On my macOS 10.12.6, both Chrome and Safari display the sankey network without a large border... only Firefox (56.0) seems to add a large border. What combinations have you tried?

giocomai commented 6 years ago

I wrote "any browser", but I now realise I did not really pay attention to cross-browser compatibility. So after all, it may indeed be a browser-specific issue, as I have focused troubleshooting on Firefox (Firefox 56, on Linux). I have tried again now with Chrome and Webkit-based browser, and the large white band is not there. So after all, this may be specific to Firefox. However, as the white band is visible also once the html is embedded, I'd say this is not negligible. Also, removing the viewBox did not seem to have any negative consequences in either Chrome or Firefox (yet, I acknowledge I may be disregarding other use cases).

I understand conditional javascript based on userAgent or feature detection may in principle be an option, even if probably not ideal for maintenance.

Perhaps it would at least be possible to mention in the documentation of sankeyNetwork() that Firefox users may experience issues, and hint at how they can be resolved?

cjyetman commented 6 years ago

It's hard to say for sure, because we have no way of collecting such metrics, but based on my experience with issues submitted here and questions on Stack Overflow, it's my impression that viewing these sankeyNetworks in RStudio's viewer, and embedding them in Shiny, RMarkdown, and flexdashboards are far more common use cases than exporting HTML to embed somewhere else. Those are the use cases that the stated compromises were made to deal with (flexdashboard primarily iirc).

I wonder if there's some reason why Firefox does that while the other browsers do not... and if that was always the case, or if that's a recent regression in Firefox. It would be more ideal to have the different browsers render proper HTML/CSS/SVG consistently than build in different behaviors for each one.