-
-
Notifications
You must be signed in to change notification settings - Fork 362
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
Implements custom elements with xml namespaces (for SVG) #622
Conversation
app.custom("svg")
app.Custom("svg")
821c94e
to
cc9dc7e
Compare
app.Custom("svg")
cc9dc7e
to
2ecc455
Compare
The second commit changes how the
I would love to see this added as it makes SVG handleable without all the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good idea to use the xmlns to know if a NS element should be created. At this point I'm wondering if there should be just an Elem()
and SelfClosing()
functions.
The reason a did not implement SVG is that it has its own specs and attributes and I did not want to add this to the main package. I'm really wondering if it is worth translating everything. In my projects I had been pretty successful using them in Raw().
pkg/app/custom.go
Outdated
) | ||
|
||
// HTMLCustom is the interface that describes a custom HTML element including its namespace. | ||
type HTMLCustom interface { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems like this could be generated since it takes global attrs and global event handlers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes! I missed that because my first implementation did not use the "XMLNS" attribute. But this can go. I make the modification.
pkg/app/custom.go
Outdated
} | ||
|
||
// CustomSC returns an self closing HTML element of the given name in the given namespace | ||
func CustomSC(name string) HTMLCustom { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This still returns HTMLCustom which has the Body method. User might make errors with this by setting a body.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. I agree that is bad.
I had the "raw" version in my HTML 2 go-app declarative converter but think it would be more useful to have those "custom" ways to create an abstraction. Like with my example. You can build a little library of SVG helpers to create graphs and don't need to go back to string manipulation. I don't think that the whole SVG spec should be included and if, then in a separate package maybe. |
I added a new implementation using generate and
What do you think? |
I don't understand why it changes If the file differs between systems or is dependent on Go versions it may be better to have it included in another way maybe? |
@maxence-charriere I actually need to know if you will take this (or a similar) PR eventually. |
I think so, I see the need for a custom element. |
What did it need to make this go through then? |
I need a bit time to think it. I ll probably take your branch and modify it directly. |
OK! |
As mentioned I wrote a HTML to declarative converter which helps us to translate sites quickly esp. for prototyping. It may help you to see some example of what the current implementation looks like:
P.S.: Seeing this I wonder why we create empty |
bcad00d
to
6a379fb
Compare
6a379fb
to
a51f91d
Compare
I just updated this to the latest version of go-app (as we use it quite a lot now in our projects). |
Looks like I missed something as I got build errors. No time to check this currently. Our apps seem to compile fine. |
a51f91d
to
e43fc14
Compare
e43fc14
to
57ae299
Compare
I removed stob. Had some problems with some go versions. |
57ae299
to
da82f9e
Compare
I see. I forgot to update my forks master for some mysterious reason ;-) |
da82f9e
to
4a424eb
Compare
@maxence-charriere What do you think about this PR? Is there anything I can do, to increase your acceptance? |
I want to make some work about how the html elements are dealt with. Keep this open since your work as often be very insightful about how the package should evolve. |
Sadly this PR is holding us back to use your releases for our development as we use The other PRs (especially the loading progress) are more optional, even if the SkipAllUpdates seem to have quite some impact. We can gate those more easily in builds and just use them on checkpoint releases. So if you only think about the implementation itself, but not about the "how to use it". then you may consider accepting the PR and changing the implementation later, maybe together with the introduction of generics. I think having P.S.: I came back to this because pojntfx/html2goapp#1 (comment) mention this same problem and I noticed that you started to add notifications to the master branch which makes some of my later work obsolete in the near future. |
- Extended generate so it can also handle Elem() - Added a test for Elem() (elem_test.go) - I did not like to add SelfClosing() as method to HTMLElem when ElemSC() is so much easier to do.
We are (extensively) using this in our projects and it proves quite usefull when creating SVG on the fly. So I hope that this PR or something similar will finally be accepted. |
An update on this. I’m planning changes where this will be possible. Keeping this open since i am using it as a reference for the need. Working on it now. |
Closing because #739 is making the dream true ;-) |
I added namespaces to elements and added a method to create custom tags. The reason is, that I wrote an auto converter that can translate HTML to go-app declarative syntax. While experimenting with it, I found that SVG support was missing. But adding all of the SVG seems to be a lot of work. After making a simple variant for custom elements I realized that this will not work for SVG because those elements need to be in a special namespace. So I added namespace support.
I think my implementation is quite nice. I added a test and documentation with an example of the usage:
Of course, it adds the "xmlns" field to every element. But I think this is better than having another interface for SVG.
I am contemplating if there should be an "xmlns" method instead which sets the namespace for every element. That may be a better solution than adding the namespace to the
Custom()
method. Maybe I try that too and push a commit that uses this later on.EDIT: There is another implementation using an
XMLNS()
method on the elements instead of the many parameters toCustom()
. See below!