Wout comments

Results 155 comments of


                                            Wout

Update README.md

Can you give me the full error console output from Chrome?

Wrong id's on parent g elements

I've been running some tests and I am unable to reproduce it. Id's always get transferred correctly. Where you're mentioning `attr.id` I'm assuming you mean `attr('id')`?

Wrong id's on parent g elements

Yes, I'll have a look.

get() should work from the roots, not only from the store

As of version `1.0.0-rc.10` this will be possible out of the box. So this plugin won't be necessary anymore.

Use imported SVG to render base SVG element to avoid nesting complexity

I've been thinking about that too. I fact I am planning on writing a plugin called svg.adopt.js, which does exactly that. But no ETA I'm afraid as I'm extremely busy...

Use imported SVG to render base SVG element to avoid nesting complexity

You could try with this JS shim: https://github.com/phaistonian/SVGInnerHTML/blob/gh-pages/svginnerhtml.js It enables `innerHTML` on svg elements. I haven't tested it myself so let me know how it goes. :)

Use imported SVG to render base SVG element to avoid nesting complexity

Here is an idea, why loading the entire svg image and embed it if you are not going to use its contents for interaction anyway. It might be easier to...

Use imported SVG to render base SVG element to avoid nesting complexity

Right, there was a problem with the attributes on stops (they weren't applied). That's fixed now. Could you let me know how goes?

Use imported SVG to render base SVG element to avoid nesting complexity

You'll see it appearing quite soon ;)

Use imported SVG to render base SVG element to avoid nesting complexity

That's not right indeed. The `attr` method on line 119 (https://github.com/wout/svg.import.js/blob/master/svg.import.js#L119) should overwrite default id's. Additionally, the id is a defs id (SvgjsDefs8425) because a group id would be SvgjsG8425....