Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SVG/XMLNS Proof of Concept #381

Closed
wants to merge 1 commit into from
Closed

SVG/XMLNS Proof of Concept #381

wants to merge 1 commit into from

Conversation

siler
Copy link

@siler siler commented Aug 31, 2018

I've been playing around with yew a bit and am enjoying it so far, but I really wanted SVG support. This is a working POC I'm toying with at the moment. I wanted to put this up for discussion as there are others interested in yew correctly rendering SVGs: #328, #143.

It is implemented as a sort of final pass after packing the virtual DOM stack generated during html macro execution. The solution I applied is to intercept specific tag names (namely svg) and add a namespace to their VTag. Then, at the conclusion of processing the html macro, the configured namespaces are proliferated down the children graph (unless explicitly overridden by a deeper explicit namespace being configured - which isn't currently possible). Finally, when apply is called, if the VTag has a namespace then create_element_ns will be called instead of create_element. Note that this change is contingent on koute/stdweb#271 or something like it being accepted.

Anywho, points for discussion:

  • Is it appropriate to implicitly change the namespace of elements beneath an element like svg? This is how it works in HTML via the xmlns attribute, but we aren't bound by that.
    • If not, how will syntactic access to namespaces be provided?
    • If so, how can children reference other namespaces?
  • Should namespaces be aliased at a top level node (if necessary) and elements referenced via prefix e.g. < .. xmlns:svg=".."><s:svg> .. ?

I also tidied up the grammar/formatting a bit in areas I touched. If that is an issue, those changes can be reverted.

.create_element(&self.tag)
.expect("can't create element for vtag");
let element = if let Some(ns) = &self.ns {
document().create_element_ns(&ns, &self.tag)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was trying to type in svg notes in yew, and was wondering why it showed in the DOM when inspecting the element, but was not rendered. It turns out, you need to use document.createElementNS in javascript in so that the svg document fragment will be valid.

https://developer.mozilla.org/en-US/docs/Web/API/Document/createElementNS

@ivanceras
Copy link

Is there anyone else interested in having support for SVG in the DOM? Come on, Svg is part of html now.

@fstuess
Copy link

fstuess commented Mar 8, 2019

would love to help but i am far to noob. Maybe a comment of Denis would help here?

@sbditto85
Copy link

I've merged master into @siler 's svg branch and opened a PR against his repo. If they merge it then the conflict will hopefully go away and this can be merged :) I'm currently using my master branch with the changes to do a project involving svgs right now.

@jstarry
Copy link
Member

jstarry commented Jul 30, 2019

@siler we definitely want to add SVG support! Sorry for the delay, would you mind rebasing your changes?

@jstarry
Copy link
Member

jstarry commented Aug 3, 2019

Closing in favour of #550

@jstarry jstarry closed this Aug 3, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants