Problem/Motivation
Often in design systems, it is possible to set multiple classes on one item and those classes are not exclusive. Example: a class to align the class, another one to put it in bold, another one to underline.
But currently as it is only possible to select one item per style, those classes needs to be declared in multiple styles which blotters the UI and add difficulty for the site builder to clearly see what is needed.
Proposed resolution
Be able to select multiple classes by either a multiple select or changing into checkboxes.
Issue fork ui_styles-3263526
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #3
grimreaperAfter discussion with @pdureau.
In a first time we will provide a checkbox instead of a select list when a style has only one option.
Comment #4
grimreaperComment #5
grimreaperDiscussed with @pdureau.
The problem with checkbox is that the plugin title is used directly has the checkbox label, and no more the value label.
No satisfying solution for the moment.
Comment #7
pdureau commentedLet's make this more declarative and generic.
Instead of just automatically detecting if style has just one option, we can add 2 keys in ui_styles plugins YMAL descriptions:
Widgets/types:
Without breaking the current YAML structure:
background_colors: type: color label: Background color options: bg-white: White bg-black: Black bg-gray: Gray margin_top: type: range label: Margin top options: mt-0: 0 mt-1: 1 mt-2: 2 mt-auto: Auto group: marginInspirations:
Comment #8
pdureau commentedComment #9
grimreaperSplitting other widgets and groups into separated issues.
Comment #10
pdureau commentedComment #11
sharique commentedNew widgets will be really helpful.
With new widget options, there is an overlay with layout options in certain scenarios, for example in case of layout paragraphs, we can add same setting either using UI Styles or layout options.
Comment #12
pdureau commentedHi Sharique, the widgets are only bringing improved UX for existing styling features.
Styles are still list of mutually exclusive options. Each option is still a CSS class.
We are not introducing other data types like booleans, integers...
So, if there is an overlap with Layout Options, it must be already the case. Do yo usee it?
Comment #13
sharique commentedI see overlap in case of layout paragraphs, because we are using extensively. And this is already in a way. Not sure about other scenarios.
Anyway we can revisit this later.
Comment #16
maboy commentedComment #17
thomas.frobieter@maboy Nice! Thrilled to use this. Does it make sense to review the status quo now?
Comment #18
pdureau commentedIn #3375884: Provide more options to drive the display of the UI style form vbouchet has proposed:
Why not... Maybe a new property like this one from Form API:
Let's credit him if we add this feature.
Comment #19
grimreaperReviewing.
Putting into needs work as of current review comments and also needs automated tests.
Comment #20
grimreaperTaking care of some review comments during rebase.
Comment #21
grimreaperI pushed some refactoring.
I did not had the time to fix coding standards and write tests yet, as there are still some stuff remaining.
Main part will be to update the CSS to work outside of Gin / Gin LB.
@maboy do you want to retake the issue? do you want to see it in pair programming?
Comment #23
grimreaperIntroduced a lot of tests and converted to PHP attribute discovery.
TODO:
- comment 18
- discuss about the @todo and question marks.
- update CSS to not rely on Gin
- update documentation, examples. Where? In readme? on drupal.org doc pages?
Comment #24
grimreaperAfter discussion with @maboy and @pdureau,
TODO:
- comment 18, @Grimreaper
- Fix the @todo and question marks. @Grimreaper
- take previewed_as hidden into account @Grimreaper
- update CSS to not rely on Gin @maboy
If Gin specific stuff will be needed when using Gin LB, let's see to make an issue and MR on Gin LB.
Comment #26
grimreaperComment #27
grimreaperUpdated TODO:
- one new review question to answer
- update CSS to not rely on Gin @maboy
Comment #28
grimreaperThanks @maboy for the new CSS. Looks pretty good!
The only thing I wonder now is in term of accessibility if the fake selects are ok. But I guess assistive technologies still see radios buttons.
With Claro:
With Gin and Gin LB:
Comment #29
grimreaperI have created an MR on #3426449: Update styles declaration to use UI Styles sources in WIP with a beginning of icons. This will ease the testing.
Comment #31
grimreaper@rajab suggested "Radio Image widget in core" during UI Suite monthly meeting.
Comment #32
grimreaper@Rajab Natshah
The only thing in core I found regarding a "radio image widget" in core is core/lib/Drupal/Core/Render/Element/ImageButton.php which is a submit button, so not what we search.
After a quick Google search, I found https://www.drupal.org/project/image_radios, is it what you had in mind?
Comment #33
grimreaperWith @pdureau we did other testing.
We tried to use the previewed_with also. It gives interesting results. Some previews are better, other are broken. See attached screenshots.
I put some todos in the MR to not forget stuff to explore, we are almost there but we are missing a mechanism to ensure we have nice previews.
Also potentially we will be able to have previews in the admin theme with #3453784: Stylesheet generator + CKE5 usage.
Comment #34
grimreaperNote to myself for later :)
/ui_styles/stylesheet.css?prefix=.ui-styles-source-select-plugin: { minified: true }+ re-adapt stylesheet.
Comment #35
grimreaper@pdureau, if you can give a look at the current state of this issue with testing on ui_suite_bootstrap in #3426449-8: Update styles declaration to use UI Styles sources please?
I will fix tests and coding standards once we will agree on the solution.
Comment #36
grimreaperComment #38
grimreaper