-
Notifications
You must be signed in to change notification settings - Fork 844
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
[EuiMarkdownEditor] Add readOnly
prop
#5627
[EuiMarkdownEditor] Add readOnly
prop
#5627
Conversation
Preview documentation changes for this PR: https://eui.elastic.co/pr_5627/ |
Preview documentation changes for this PR: https://eui.elastic.co/pr_5627/ |
@miukimiu I pushed a small change that makes the checkbox plugin respect your |
Preview documentation changes for this PR: https://eui.elastic.co/pr_5627/ |
Thanks, @chandlerprall for helping with the issue with the checkboxes not getting disabled. I have another question. How should we handle the But we can have more complex plugins that the consumer would need to get the state because not always just CSS would work. Like in the checkboxes plugin for example where we got the When creating plugins is this state exposed so that consumers can get it? Do we need to expose it? And how do we document this? |
Preview documentation changes for this PR: https://eui.elastic.co/pr_5627/ |
I haven't looked super closely at this PR at all but just wanted to suggest something potentially very dumb. Why not cover the entire editable contentarea of the editor with an overlay div of the same background color as the editor and a 50% opacity? This serves the following:
This may need some extra finagling to ensure that the underlying editor is inaccessible to keyboard/screen reader users, but for visual and mouse users it should work 🤷♀️ EDIT: If an overlay div is too basic we could also look into CSS filters |
Preview documentation changes for this PR: https://eui.elastic.co/pr_5627/ |
Thanks, @constancecchen for suggesting the overlay div. I changed the PR back to draft. Based on our weekly sync discussion I decided to add a For our use case "adding a comment", we just want to restrict editing but users should be able to read properly what they wrote once they post the comment. If we decided to add an But how do we notice that editing is restricted? In editing mode, all toolbar and footer buttons get disabled. This would make it more visible to users that the editor is in a different state and no more editing is possible. The In previewing mode the toolbar buttons are already disabled. The only difference from a normal state is the editor mode button gets also disabled. All the rest look the same. Components that allow changing the content like This can be tested in https://eui.elastic.co/pr_5627/#/editors-syntax/markdown-editor. The logic for the checkboxes plugin in previewing mode is not implemented yet. For now, they just get disabled. Any thoughts on this new approach? |
isDisabled
propreadOnly
prop
@@ -32,3 +32,13 @@ | |||
background-size: 100% 100%; | |||
} | |||
} | |||
|
|||
.euiMarkdownEditorTextArea-isReadOnly { | |||
cursor: default; |
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.
This cursor: default
is following our EuiTextArea styles. But I'm not quite sure is really necessary... If we can copy the text shouldn't we keep the cursor that a textarea
gets by default cursor: text;
?
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.
When hovering on an enable textarea, the cursor everywhere is text
indicating it is enabled and to click anywhere to insert text. The default cursor overrides this behavior to try to indicate that you can no longer edit by showing the arrow cursor everywhere. What we probably want to do instead is cursor: unset;
which defaults back to the browser's behavior of arrow cursor until hovering over text. I checked this specifically on our EuiTextArea and it works the way I'd expect, but I didn't check the Markdown editor.
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.
The EuiTextArea and other form controls when in readOnly
get a cursor: default;
:
eui/src/global_styling/mixins/_form.scss
Lines 216 to 222 in 6b3279d
@mixin euiFormControlReadOnlyStyle { | |
cursor: default; | |
// Use transparency since there is no border and in case form is on a non-white background | |
background: $euiFormBackgroundReadOnlyColor; | |
border-color: transparent; | |
box-shadow: inset 0 0 0 1px $euiFormBorderDisabledColor; | |
} |
But almost every browser behavior when in readOnly
gets a cursor: text;
. This cursor indicates that the text can be selected (https://developer.mozilla.org/en-US/docs/Web/CSS/cursor).
So I'm just adding this cursor: default;
because I'm following the pattern of our EuiTextArea. Is this the behavior we want to maintain?
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.
Right so, we probably want to align better with browser's innate use of cursor. If we're using the HTLM property readonly
which applies the pseudo class :read-only
we shouldn't have to change the cursor. You can undo our non-readonly cursor by just reverting it back to the browser's default via cursor: unset
. But I can't be positive that all uses of the mixin is in fact applying the readonly
property directly.
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.
If we can copy the test shouldn't we keep the cursor that a textarea gets by default cursor: text;?
Agreed. It feels weird with this set to default
Changed the I played with the checkbox styles some but didn't like anything, and I couldn't find an established pattern anywhere around what a readonly checkbox should look like - best I came up with was |
Preview documentation changes for this PR: https://eui.elastic.co/pr_5627/ |
Preview documentation changes for this PR: https://eui.elastic.co/pr_5627/ |
Preview documentation changes for this PR: https://eui.elastic.co/pr_5627/ |
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.
just wanted to say from a UI/UX standpoint I really like it, and it solves our use-case perfectly 👍
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.
Visually & functionally everything works great. Had a couple code & docs suggestions.
<EuiFlexItem grow={true}> | ||
<EuiSwitch | ||
label="Read-only" | ||
checked={isReadOnly} | ||
onChange={onChange} | ||
/> | ||
</EuiFlexItem> |
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 highly suggest adding a sentence about the use of this prop to the text of this example. Maybe explaining, that if the consumer needs to disallow editing while submission is happening, then they should manually update this prop.
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.
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 like it! I just have a quick suggestion to tighten up the language.
Co-authored-by: Caroline Horn <549577+cchaos@users.noreply.github.com>
Preview documentation changes for this PR: https://eui.elastic.co/pr_5627/ |
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.
LGTM!
<EuiFlexItem grow={true}> | ||
<EuiSwitch | ||
label="Read-only" | ||
checked={isReadOnly} | ||
onChange={onChange} | ||
/> | ||
</EuiFlexItem> |
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 like it! I just have a quick suggestion to tighten up the language.
Co-authored-by: Caroline Horn <549577+cchaos@users.noreply.github.com>
Preview documentation changes for this PR: https://eui.elastic.co/pr_5627/ |
Summary
Closes #5129. This PR adds a
readOnly
prop toEuiMarkdownEditor
.Initially, I started this PR by adding an
isDisabled
prop. But after some discussion, I decided to add areadOnly
prop instead. The reasoning for this decision can be found in the following comment: #5627 (comment).Design
Checklist
[ ] Checked in mobile[ ] Checked Code Sandbox works for any docs examples[ ] Checked for breaking changes and labeled appropriately