Lion Button #1023
Unanswered
jorenbroekema
asked this question in
Ideas
Lion Button
#1023
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Current situation
LionButton:
<button>on submit handlers (e.g. enter key). This is where most of the fuzzy logic existsThis is easy to extend, especially for those who want to create a more complex button that requires it (or is more practical) to be a webcomponent.
The negative part is that it's a bit heavy, since it has a lot of logic for the implicit form submission, handlers to make it behave like a button, and a click area div.
The alternative is using a native
<button>which is lighter. The click-area can be done through CSS only. See @jorgecasar PR: #1019 as well as a POC by @erikkroes (maybe he can link his codepen here). Since a button accepts HTML content inside, it should cover having rich content inside as well, although the styling of that content will not be encapsulated, as<button>does not have a shadow root.Points to get an agreement on:
<lion-button>to<button>inside lion, wherever we can practically get away with it. Examples: lion-switch-button, lion-select-rich-invoker. POC ❌ Depends, only if it really makes it easier and not harder<button>as the defacto standard over<lion-button>and document in which cases using the webcomponent actually makes sense.as well as export it as a functional style component so it can be reused even for native. POC ✅<button>Beta Was this translation helpful? Give feedback.
All reactions