Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
feat: apply hover effects anywhere on the component #3796
feat: apply hover effects anywhere on the component #3796
Changes from 4 commits
cbaebd6
bd3d799
a7aed14
ad6cea3
91d4c76
7b2dbb8
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Targeting
:host(:hover)
assumes that the consumer of these styles is a simple input component wrapper, not a component composed of multiple elements. I didn't dig into them but it does appear that app components are also consuminginputStyles
directly. I think we need to assume they could be pulling those styles into a huge component composed of lots of different things, possibly even multiple inputs. Even if those cases are "ok" with this change, this does still make me feel a bit uneasy. I think it would be better if there was an element that we could target that would isolate this behaviour, like one of the wrapperdiv
s. 🤔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.
Agreed. These input styles are intended to be used standalone on a
<input class="d2l-input">
and as Dave mentioned the "host" may be a much larger component composed of many different things.I think if we want to do this it'll have to be something constrained to
<d2l-input-text>
, which is the thing that knows about the label. We may need to programatically add/remove a.d2l-input-hover
CSS class when the host is hovered/blurred, and then add CSS here to handle it -- similar to how this already understands.d2l-input-focus
.