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
-
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