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

Merge colliding html and svg attr names into shared namespace. #71

Closed
busti opened this issue Sep 9, 2021 · 3 comments
Closed

Merge colliding html and svg attr names into shared namespace. #71

busti opened this issue Sep 9, 2021 · 3 comments
Labels
enhancement need to find time https://falseknees.com/297.html

Comments

@busti
Copy link
Contributor

busti commented Sep 9, 2021

I would like to merge colliding html and svg attribute names into a shared definition.
Attrs like height or href exist in both html and svg so when we import both dsl._ and dsl.svg._ then this code a(href := "example.com") causes a compiler error until we rename one of the attrs: import dsl.svg.{href => svgHref, _}.

I would like to create a third attr definition file which contains all colliding attrs which could then be used in both svg and html tags.

Ideally I would like to do the same for tags, but thats where things get a little more complicated since they would also have to produce the correct element based on context and that would probably require some implicit conversion magic.

In this issue I would like to hear some feedback on the general idea before I go forth with implementing this.

@raquo
Copy link
Owner

raquo commented Sep 13, 2021

Hey, that's an interesting issue! Sorry I'm not super responsive right now, I should be able to take a look at this in depth around next weekend.

@busti
Copy link
Contributor Author

busti commented Sep 13, 2021

No worries. I have found a workflow that allows me to use my updated branch while working on the related outwatch pull request.

This kinda depends on #70 but I do not want to make any this extreme changes in that PR. This proposal would probably break existing implementations while #70 does not.

@raquo
Copy link
Owner

raquo commented Dec 4, 2022

The new code generator developed in #89 can do this, if you rename the keys to prevent naming conflicts.

This kind of decision is now up to the consuming libraries. For Laminar, I gave it some more thought, and decided to keep the types as-is for now.

@raquo raquo closed this as completed Dec 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement need to find time https://falseknees.com/297.html
Projects
None yet
Development

No branches or pull requests

2 participants