I unfortunately need to have a leaflet-dvf app that uses Chart Markers that needs to also work in IE 11. It works fine in Chrome and Firefox. The markers example here doesn't render in IE 11 either:
http://humangeo.github.io/leaflet-dvf/examples/html/markers.html
Is there a workaround ? I tried added the meta X-UA-Compatible IE=edge to my app but that doesn't seem to help.
The fact it doesn't work in IE is because the custom SVG markers are an experimental feature (it's written in source code), and the error comes from
var children = gradient.children;
var childLength = children.length; // Cannot read property length of undefined, line 2739 of the file
So the only solution at the moment is to modify yourself the source code.
The gradient is just a gradient SVG element.
I guess that's because IE does not support children property on DOM elements, but instead you should try to use the childNodes property.
var children = gradient.childNodes;
var childLength = children.length;
I can't test it right now but it might do the trick, or perhaps you will go around these step and find a further issue with IE. Just note that childNodes is different from children because it returns all the nodes of an element, and not just the elements of it, so the length will differ.
See here.
If you don't want to get your hands dirty by debugging the code step by step to make it work on IE (even if I think it's just a little effort to do), use a DOM Shim like this and it will get rid of the issues you face.
One of the project authors here.
This issue should be fixed in the 1.0dev branch (compatible with Leaflet 1.0), but I'll make the same fix in the master branch and push that up. Thanks for pointing this out!
Related
I have a simple wireframe renderer, outputting with svg. An example of use is on the site:
https://0polymer0.github.io/implementation/Teapot/Teapot.html
Polygon elements, representing triangles, are updated in an animation loop.
The svg renderer works well on Chrome, but not on Firefox. Can this be fixed? And if not, why?
I think the performance relevant code is here:
for(let i = 0; i < mesh.length; i++){
dom_mesh[i].setAttributeNS(null,
"points",
triangle2D_to_string(screenspace_mesh[i])
);
}
Things I've tried
Converting childElements() output to an array (dom_mesh) didn't change anything. Reading from children didn't change anything. And directly accessing attributes rather than assigning strings to "points" didn't change anything.
I think the problem has to do with writing to svg, because the benchmarks suggest that's where the browser is spending most of its time.
I'm open to this approach being unworkable, I'm just surprised it is working as well as it is on chrome. It would be nice to understand why.
I have a component in JavaScript that will provide an <svg> element to its host. I want to populate the SVG element using d3.js.
If I let d3.js create the SVG element and add it to the <body>, then things work as expected:
var chart = d3.select('body').append('svg');
However I already have an SVG element. I want my code to more closely resemble:
var svg = document.createElement('svg'),
chart = d3.select(svg);
This latter approach populates the SVG element (as seen in the elements panel of Chrome's developer tools) but it does not render properly.
Am I going about this incorrectly?
I don't mind if d3 creates the SVG element, so long as it doesn't attach it to the DOM and I can access it.
EDIT I've created a jsFiddle that reproduces my problem. You can toggle the APPROACH variable between 1 and 2 to see alternate approaches. I see this issue in both Chrome and Firefox (latest versions on Ubuntu 13.04.)
EDIT 2 I've created a screenshot showing the working and non-working versions side by side:
You can see that the element trees are largely the same. However on the non-working version (left) the Styles panel (to the right of the element tree) is missing some user agent rules. I have no idea why this should be different. I'd suggest it was a bug in Chrome, but the same behaviour is visible in Firefox.
The problem is that you're creating the SVG element in the HTML namespace where it gets interpreted incorrectly. If you replace
var svg = document.createElement('svg');
with
var svg = document.createElementNS("http://www.w3.org/2000/svg", 'svg');
it works fine. D3 takes care of this for you by setting the namespace automatically.
I'm currently working on a WYSIWYG solution and need a function to correctly select with a range a node (by this I mean the node itself, not only it's content)
DOM lvl2 clearly have a function for this w3.org/ranges and define that
range.selectNodeContents() // Select the contents within a node
and
range.selectNode() //Select a node and its contents
The problem is that when selectNode() perfectly work with Firefox or even ie9, it seem to be impossible to achieve with any Webkit browser (at last Chrome and Safari). On Webkit both selectNodeContents() and selectNode() select the node content only (which according to the specs seems to me to be a bug)
To make it work I tried to emulate the selectNode() goal by using
range.setStartBefore(node);
range.setEndAfter(node);
but the result is still the same, it work everywhere (ie>8 of course) but not on webkit browsers..
If you want to try it I made a little jsfiddle with which you can play here (just open the console and look at the console.warn result which is not the same on webkit :/ )
I searched a lot but I can't find a way to actually select a full node on webkit browsers.
By miracle would some of you know a way to do it or even just any tip to continue my quest ? :/
ps : I know "rangy" lib but I can't use it in my project and ,from what I read in the source, I'm not even sure they deal with that thing anyway :/
The problem is not with selectNode(), which works fine in WebKit, but with WebKit's selection object, which mangles ranges to fit in with its own (not always unreasonable) idea of where selection boundaries and caret positions are allowed to be. There are bugs filed against this with WebKit:
https://bugs.webkit.org/show_bug.cgi?id=23189
https://bugs.webkit.org/show_bug.cgi?id=15256
You're right, Rangy does not deal with this, preferring instead to reflect the reality of the browser's native selection. Pretending the selection is different would quickly lead to odd behaviour.
I'm looking at Rangy (http://code.google.com/p/rangy/) and it seems it has a bunch of DOM utilities but I don't understand them without examples. So I'm turning to SO with my ideas and hopefully you guys can show me how this can be done:
What I need to do with Rangy is use it to find the position and dimensions of the selection. I want to get the frame or Rect of the selection, whether relative to the document or parent element. Then I can position my callout accordingly.
I believe the demo that comes with Rangy already illustrates what you want. specifically http://rangy.googlecode.com/svn/trunk/demos/position.html inside showSelectionPosition function
Considering the fact that selection may be spread across multiple elements, it'd be best to use the coordinates of either startSelEl or endSelEl to anchor your callout to the beginning or end of a selection.
There is an embryonic, unreleased Rangy module I wrote for getting pixel coordinates of a selection or range. Unfortunately the difficulty of getting this working properly in all browsers and all situations has put me off completing it and I have essentially abandoned it. However, if you add a bit more detail about what you're trying to do I may be able to suggest something.
I'm looking for examples of processing.js working in Internet Explorer via ExplorerCanvas or similar.
It can be done! There are some gotchas, however. The page htxt links to is fine, as far as it goes, but please note the following:
1) Both script and canvas elements must have id attributes. The init function uses these attribute id's to associate a given script with a given canvas. I found the simplified init function easier to understand than the official one. You will want to master the official one if you have multiple canvases on one page.
2) If you use internet-style color designations, like #23ff9a, watch out! IE 8 wants all upper case hexadecimal color numbers from Processing.js/canvas. Write #23FF9A! This is what the documentation shows, so it shouldn't be a complete surprise. The error is a sometime thing, which makes it crazy to figure out. Mostly, larger numbers (for lighter colors) with lots of f's seem to be afflicted. White, #ffffff, is OK, but #ff00ff is not. Firefox and Safari are case-insensitive in this regard. The documentation says you can use an alternate hex notation with alpha channel (the CC) that looks like 0xCC006699. This didn't work for me; maybe it's on the to-do list.
3) The .equals() method on strings is missing! Andor Salga, one of the Seneca College crew working on Processing.js, wrote a simple boolean stringsEqual(str1, str2) function you can see here. This will do until the matter is definitively fixed.
4) It's not true that stroke() doesn't work with excanvas.js. It does. However, if your Processing.js code has even one little syntax error (I can't really categorize which kinds, but trying to use .equals() will do it) your routine will probably fail silently in IE8, whereas, in Safari or Firefox, your rectangles may lose their outlines, i.e. stroke() will quit working. IE on Vista, and Safari on the Mac, have both exhibited stronger syntax checking than Safari or Firefox on Vista, which will blow by certain errors and render a defective graphic.
5) Text, invoked using the text() function, renders in Firefox (in an unchangeable font of Firefox's choosing), but, as far as I can tell, not in IE8 or Safari. The Glyph Method is suggested here. The code is in place, but getting the fonts looks like a problem. Inkscape looks pretty impenetrable to me. As far as I can tell, what is needed is a lot like old pen-plotter fonts - a vector path with pen-up and pen-down commands between runs of nodes. Turns out FSF/GNU has some that might be massaged into the right format without too much trouble. I don't know where the format is defined, but it's probably over at W3C somewhere. The approach with real potential for presentable fonts is the IE/VML wing of Cufon. See How does it work? I really want this last link in the chain, but I could use some help.
Processing.js is one whale of a project that deserves our support. It has enormous potential. I would encourage you to pitch in if you are able.
The sparklines example on the processing.js exhibition page uses ExplorerCanvas. It seems like it's just a drop-in solution, no extra coding necessary.
This page describes how to get processing.js + excanvas working together.
It basically involves writing your own onload init method that IE can understand.