-
Notifications
You must be signed in to change notification settings - Fork 308
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
fix: update modal buttons alignments in element dialogs #3365
base: master
Are you sure you want to change the base?
Conversation
note to self: the textarea in USM seems to render immediately while the rest of the UI is loading |
@@ -1,6 +1,6 @@ | |||
@import '../variables'; | |||
|
|||
.be .be-header { |
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 .be
on this selector breaks the .be-is-small &
selector below
input[type='search'] { | ||
width: 100%; | ||
font: inherit; | ||
-webkit-appearance: none; | ||
} |
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'm not too sure what these lines were intended for. my assumption is this was related to a Safari issue but we don't target input[type='search']
for any other components so I don't know why this was needed.
I think it's okay to remove the block now:
width: 100%;
is being added here:width: 100%; font: inherit;
is applied here:font: inherit; -webkit-appearance: none;
from my testing this wasn't having an impact in most recent version of browsers. I also don't think we want this based on this:box-ui-elements/src/styles/common/_forms.scss
Line 106 in b9d196f
-webkit-appearance: textfield;
@@ -23,7 +22,8 @@ | |||
input[type='number'], | |||
div[contentEditable='true'], | |||
textarea { | |||
border-color: $bdl-gray-50; | |||
width: 100%; |
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.
adding width: 100%
here can be a little risky since it'll apply the style to all text fields in all the elements.
I did testing in all the elements but haven't seen an issue yet. most uses of inputs/textareas are already using width: 100%
. e.g:
box-ui-elements/src/elements/content-sidebar/activity-feed/task-form/TaskForm.scss
Line 14 in b9d196f
width: 100%; |
I'll continue more testing of the elements to verify |
This is updating the designs of the modals used in Content Explorer and Content Picker. There are three modal components that this is specifically targeting:
CreateFolderDialog.js
,DeleteConfirmationDialog.js
, andRenameDialog.js
I decided to add
width: 100%;
to all text fields in the base elements stylesheet since100%
seems to be the most ideal value forwidth
in majority of cases for input.At the moment, components are inheriting
width: 262px
from the base components stylesheet but this seems to be an arbitrary value and components are overriding it. e.g.box-ui-elements/src/elements/content-sidebar/activity-feed/task-form/TaskForm.scss
Line 14 in b9d196f
box-ui-elements/src/features/item-details/ItemProperties.scss
Line 16 in b9d196f
box-ui-elements/src/features/unified-share-modal/UnifiedShareModal.scss
Line 181 in b9d196f
Before
After