-
Notifications
You must be signed in to change notification settings - Fork 64
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
Theme: ComboBox #258
Theme: ComboBox #258
Conversation
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.
Some questions, and a couple focus styles. Looks good! Since it seems to be branched off textinput/textarea styles, maybe it should get merged after that PR?
src/combobox/ComboBox.ts
Outdated
@@ -401,7 +401,6 @@ export default class ComboBox extends ComboBoxBase<ComboBoxProperties> { | |||
readOnly, | |||
onclick: this._onArrowClick | |||
}, [ | |||
'open combo box', |
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.
Why delete the text? It needs some sort of label, could either be this text wrapped in a visually hidden span, or an aria-label
on the button
src/themes/dojo/comboBox.m.css
Outdated
position: absolute; | ||
right: 0; | ||
top: var(--border-width); | ||
z-index: 1; | ||
} |
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.
Since combobox can have the arrow focused on separately from the input, I think this needs separate focus styles
src/themes/dojo/comboBox.m.css
Outdated
width: 100%; | ||
padding-right: 2em; | ||
z-index: 2; |
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.
We probably need some sort of consistent approach to z-indices. Maybe something like this?
- 10: stuff like this that appears over surrounding inline content (this, tooltips, menus)
- 20: block-level items that need to appear over all other normal page content (e.g. sticky navs, alerts)
- 30: modal overlays
- 40: modal content
I'm probably missing use cases, but I think it'd be good to use and document some sort of system
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.
We could even put them in variables 😁
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, good catch. I will do this as part of a separate PR, this will effect SlidePane and Dialog (at least) once they land.
position: absolute; | ||
right: calc(var(--spacing-regular) * 6); | ||
top: 50%; | ||
transform: translateY(-50%); |
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.
Could possibly use a focus style too
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.
Added.
src/themes/dojo/comboBox.m.css
Outdated
cursor: pointer; | ||
padding: var(--input-padding); | ||
.invalid .trigger { | ||
border-left-color: color(var(--color-error) saturation(-9%) lightness(+37%)); |
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 color (and the success variation) is getting used in more places than I thought. Do you think it's worth thinking of another variable name?
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 fine with color-error and color-success since they provide abstraction from the underlying color. Personally I don't find myself wishing I had more abstraction, but I'm open.
src/themes/dojo/comboBox.m.css
Outdated
width: 100%; | ||
} | ||
|
||
.trigger { |
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.
is it possible to move some of this styling to a shared file? Looks like combo / select / textbox have the same styling
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.
Totally agreed. We have #117 to track that progress, as it's more involved than just pulling out common styling. The underlying DOM is still somewhat different and would require some consolidation.
I definitely think we need to take care of that ticket asap though.
Codecov Report
@@ Coverage Diff @@
## master #258 +/- ##
==========================================
- Coverage 98.78% 98.64% -0.14%
==========================================
Files 24 24
Lines 1478 1481 +3
Branches 436 439 +3
==========================================
+ Hits 1460 1461 +1
- Partials 18 20 +2
Continue to review full report at Codecov.
|
@@ -142,7 +142,9 @@ export class App extends WidgetBase<WidgetProperties> { | |||
} | |||
|
|||
render(): DNode { | |||
return v('div', [ | |||
return v('div', { | |||
styles: { maxWidth: '256px' } |
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 assume this is to restrict the width of the inputs, should they not have their own max width?
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.
Based on talking with Scott, I believe we decided no max width. It makes a certain sort of sense -- desired width can be really variable (no pun intended, mostly), and controlling input width through styles on the containing element seems like a better pattern anyway.
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.
@bitpshr I actually wouldn't mind this added to textinput/textarea too, if you feel like it
font-style: italic; | ||
cursor: default; | ||
.clear:focus { | ||
border-color: var(--color-highlight); |
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 know I'm being super nitpicky (😔), but the border isn't the most beautiful of styles. Maybe Scott would have some ideas?
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. I will call this out to Scott during his sweep.
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 could do with prettier clear button focus styles, but I also think it'd be good for Scott to review all styles in action after the theme PRs are in. Either way, I'm fine with you merging this now 👍
Type: feature
The following has been addressed in the PR:
Description:
This PR adds an initial theme for the ComboBox component. Note that this work was based off @smhigley's TextInput theme PR.