-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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(text-input): add read-only variant #3054
feat(text-input): add read-only variant #3054
Conversation
Deploy preview for the-carbon-components ready! Built with commit 5276b58 https://deploy-preview-3054--the-carbon-components.netlify.com |
Deploy preview for carbon-elements ready! Built with commit 6faa37b |
Deploy preview for carbon-elements ready! Built with commit 5276b58 |
Deploy preview for carbon-components-react failed. Built with commit 6faa37b https://app.netlify.com/sites/carbon-components-react/deploys/5d025f43fcc7e3000743d743 |
Deploy preview for carbon-components-react ready! Built with commit c33c472 https://deploy-preview-3054--carbon-components-react.netlify.com |
146d550
to
804fc13
Compare
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.
Looks great overall! A few small things:
- clicking outside the tooltip should close the tooltip (vanilla only, react looks fine)
- new tooltip should show above existing tooltip on screen, potentially not an issue if we can close the other tooltip easily
- Is it possible to disable "error state" on read-only? This situ shouldn't arise. It doesn't give user a way forward since field cannot be edited.
@shixiedesign clicking outside of the tooltip in both vanilla and react closes the tooltip for me. can you provide more details about how to reproduce this issue? |
9148838
to
8ac2852
Compare
@emyarod Depending on what version of the tooltip you are using it could be related to this question i had: #3099 (comment) |
@elizabethsjudd this is using the WCAG 2.0 compliant tooltip. do you mean the behavior is inconsistent when a button is the trigger element? |
@emyarod when a button is used as the trigger for a tooltip, the user can "click" on the button and the tooltip will remain active until the user clicks somewhere else (the button is given focus which also causes the tooltip to display). You can scroll, resize, mouse over other elements, etc all while the tooltip remains open (this is what I believe is causing the scenario @shixiedesign is pointing out by having two tooltips open at once). The one thing I don't know is if this is accurate behavior because in actual offerings we'd expect a button to perform an action which would most likely cause the focus to change/move and therefore I believe the tooltip would hide. The question that I'm bringing up however is that I feel like both of these tooltips seem like they should be "definition tooltips" as they are either explaining the reason something is in a state, or it's just the extended version of the inputs value. My question in the other issue is that I don't feel like "definition tooltips" should be clickable at all unless they are on a button that is actually performing another action. In this use-case I don't feel that the tooltips should be on clickable triggers and the clicking is what is making them persistent. I've done a ton of research and implementations of various types of a11y tooltips so if you have any questions around this don't hesitate to ask. |
@elizabethsjudd that was intentional according to the initial component spec so that the user can select the content (although clicking on the read only input will also select all of the text). from what I understand, @shixiedesign is referring to clicking multiple times outside of the button before the tooltip closes, but I am unable to replicate that behavior (the tooltip is dismissed with one outside click for me). I think I need some clarification on what the bug report is referring to and some confirmation on the expected behavior |
@emyarod thanks for the clarification. Just out of curiosity, are you using the first tooltip that's on this page: https://www.carbondesignsystem.com/components/tooltip/code? At least on the site demo even after I open the tooltip if I try to select the text the tooltip closes (because it closes by clicking anywhere outside the |
@elizabethsjudd, no I don't make any changes to the tooltip code in this PR so it seems you found a vanilla-only interactive tooltip bug. it looks like if I click on one of the interactive elements in the tooltip before trying to select the text the tooltip will not close (but only in the dev environment, not the Carbon website). probably need to examine the vanilla tooltip click handler. we can track this in a separate issue |
@emyarod totally agree that it is out of scope for this issue. Thank you for confirming! |
@emyarod I was just thinking about it. using |
@elizabethsjudd just to confirm, also is this related to #3100? |
@shixiedesign I think this is good for another review before I port this over to React but I may hold off until #3148 and associated PRs are approved and merged |
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.
Looks good!
6557e1c
to
1135b3c
Compare
@jnm2377 I am currently exploring ways to work around it |
If we don't have a clear resolution in place, would be best to close this for now and revisit in our next components project 👍 |
Closing this since the stale warning label was applied >7 days ago 👍 |
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.
I think we could use the :read-only
pseudo-selector here rather than the attribute selector. Would likely only matter for folks overriding using the most "appropriate" selector.
Do we want to remove all the vanilla stuff from the PR?
@@ -80,7 +129,8 @@ storiesOf('TextInput', module) | |||
() => ( | |||
<TextInput | |||
type={select('Form control type (type)', types, 'text')} | |||
{...props.TextInputProps()} | |||
{...props.textInput()} | |||
invalid={props.textInput().readOnly ? false : props.textInput().invalid} |
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.
Nice work ignoring validation here, we definitely want to make sure that's the case in any readonly inputs
Closes #3018
Closes #1672
This PR adds read-only support to the text input and textarea components alongside a mechanism to convert the inputs to controlled mode based on the
onChange
handler andvalue
prop. This PR also reimplements character counter (which was previously reverted but depends on the controlled/uncontrolled separation). Since controlled/uncontrolled separation itself doesn’t provide any benefit from user’s perspective until character counter is introduced, it is being introduced alongside the character counter feature hereChangelog
New
TextInput
andTextArea
to controlled components based ononChange
handler andvalue
propreadOnly
mode stylesTextInput
andTextArea
(ref: feat: text input and textarea character limit counter #2745 which was previously reverted)Testing / Reviewing
Ensure the read-only text input and character counters behave as expected