-
Notifications
You must be signed in to change notification settings - Fork 0
Style SchemaEditor #404
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
Style SchemaEditor #404
Conversation
|
Nice! Two ideas for improvment, not nececerily in this PR:
|
|
Looks great. I'm still reviewing, but my first thought is we should add a max-width on the outer container (or on inputs). The UI feels a bit weird when it is wide (e.g. at 1920x1080 where full screen is still common, bigger screens get worse). The toggle switch in particular bothers me. I know clicking the label toggles it, but the visual element is all the way on the far right. This is not a problem with a checkbox where it's right next to the label. In Vector 2022 it looks good, but in Vector, Chameleon and Medik the width can be problematic. For example, compare Special:Search (max-width on container) and Special:Preferences (max-width on inputs). |
| @@ -14,14 +14,14 @@ | |||
| {{ $i18n( 'neowiki-edit-summary-help-text-subject' ).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.
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'll follow up on this.
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.
Minor thoughts:
EditSummarydoes not sound like it's a component with actions.- It's being used on
SubjectEditorDialog,SchemaEditorDialogandEditSchemaPage. Right now it's probably fine since they all mostly look and act the same, but if we end up passing in a bunch of cusomtizations, then maybe there is only a superficial similarity that should not really be extracted.
| <template> | ||
| <div class="number-attributes"> | ||
| <!-- cdx-field class is used for spacing --> | ||
| <div class="number-attributes cdx-field"> |
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 it's just a margin, can't we rather add a custom common class like attributes-editor? Or maybe even add it once in PropertyDefinitionEditor. It feels like a hack to repurpose a class meant for something else.
| {{ $i18n( 'neowiki-schema-editor-new-property' ).text() }} | ||
| </template> | ||
| </CdxCard> | ||
| <CdxMenu |
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.
Initially I did not use CdxMenu because my understanding was that it's supposed to be used in a specific way - as part of something that triggers a dropdown.
For example: :expanded="true" and the drop shadow point to the intention of it being a floating and hideable component.
I guess it's fine if it works. But I'm not sure at what point repurposing components in unintented ways might be a problem.

Closes: #391, #388
Key changes:
SchemaEditoraccording to Figma specDialogFootercomponent intoEditSummaryto be more genericEditSummarycomponent for edit summary inSchemaEditorCdxMenufor property listCdxToggleSwitchfor boolean values instead ofCdxCheckboxglobal.scssRecording.2025-05-14.200126.mp4