31–40 of 43 posts
"no Javascript" is very misleading. There are several tags embedded in each svg, including at least two scripts that are loaded from external sources. In fact, nearly 1/3 of the data transferred for the first graph is javascript[0]. https://gist.github.com/hughes/c876b02aa06f897c99e2
"no Javascript" is very misleading. There are several tags embedded in each svg, including at least two scripts that are loaded from external sources. In fact, nearly 1/3 of the data transferred for the first graph is javascript[0]. https://gist.github.com/hughes/c876b02aa06f897c99e2
Hm, how does this work? How can JavaScript be executed like that when it's included as an image?
"no Javascript" is very misleading. There are several tags embedded in each svg, including at least two scripts that are loaded from external sources. In fact, nearly 1/3 of the data transferred for the first graph is javascript[0]. https://gist.github.com/hughes/c876b02aa06f897c99e2
Earlier quoted context omitted.
Hm, how does this work? How can JavaScript be executed like that when it's included as an image?
Curious about that too. If I load an svg in the address bar with embedded script I can show alert(), but linked into html using tag, alert does not run. Sandboxed? Otherwise I could execute JS just by loading in using svg via .
> Any functions defined within any script element have a global scope across the entire current document.
[0] https://developer.mozilla.org/en-US/docs/Web/SVG/Element/scr...
Nice, but its a re-implementation of the Google Chartserver right? (same model, URL describes charts which are returned) The issues Google ran into were as it gets popular you need a more server horse power, and the work of keeping things secure is pretty high. That said I always enjoyed using chartserver :-) so I presume I would enjoy using this. But what I'd really like is a package for python or perl I could load…
I work for the team that maintains Chartserver. It's being deprecated for a number of reasons, none of which you've listed. Mostly, we feel the service has been replaced by JS charting solutions (Google Charts, d3, etc.) which are more flexible and don't have the privacy concerns of Chartserver. Most importantly, the team that developed it has moved on to other work and it hasn't been restaffed. We revisit the deprec…
Isn't that right there an example, or warning, or admonition, or something, suggesting that you not use external services for essential features? I know that no page is likely to last more than five years, but there are going to be many pages that outlast services like this.
Or am I missing the target use case?
Earlier quoted context omitted.
I work for the team that maintains Chartserver. It's being deprecated for a number of reasons, none of which you've listed. Mostly, we feel the service has been replaced by JS charting solutions (Google Charts, d3, etc.) which are more flexible and don't have the privacy concerns of Chartserver. Most importantly, the team that developed it has moved on to other work and it hasn't been restaffed. We revisit the deprec…
> Most importantly, the team that developed it has moved on to other work and it hasn't been restaffed. Isn't that right there an example, or warning, or admonition, or something, suggesting that you not use external services for essential features? I know that no page is likely to last more than five years, but there are going to be many pages that outlast services like this. Or am I missing the target use case?
Earlier quoted context omitted.
> Most importantly, the team that developed it has moved on to other work and it hasn't been restaffed. Isn't that right there an example, or warning, or admonition, or something, suggesting that you not use external services for essential features? I know that no page is likely to last more than five years, but there are going to be many pages that outlast services like this. Or am I missing the target use case?
I'm not quite sure what you mean by "no page is likely to last more than five years," because a large portion of the Web is composed of pages that, once posted, remain indefinitely. If your site is one of them, you wouldn't want to depend on an external source for your charts, or your archived pages could be broken by a third party--which seems to be your (very good) point, so I'm a bit confused by your wording.
Earlier quoted context omitted.
I don't think Google Chartserver offered SVG, though, did it? I think that's a significant difference, in that the variant of this API has the potential for access to the chart elements for styling and interactivity.
Well Chartserver did offer SVG at one point, although at the time SVG was (and kinda still is) under supported in the browser space AFAICT. Having recently rediscovered the non-joy of putting somebody else's javascript on a page (in that case WebRing) I am a bit gun shy of the whole model[0]. I really like the idea of 'server driven charts' for easy web pages and illustration. But I would rather have it be something…