Problem/Motivation
The gin_toolbar module references the claro/claro.drupal.dialog library to handle the dialog styling.
However adding this dependency without the css/base/variables.css defined in claro/global-styling results in an inconsistent UI, because its claro/claro.jquery.ui dependency still references variables which are only defined in that file.
Steps to reproduce
1. Install gin_toolbar
2. Using a non-claro front end theme, add an element which uses an autocomplete form element (e.g. webform).
/core/themes/claro/css/components/jquery.ui/theme.css will be loaded, but the autocomplete styles will be broken because the variables within the following rules fail to resolve:
.ui-autocomplete {
color: var(--jui-dropdown-fg-color);
border: var(--input-border-size) solid var(--jui-dropdown-border-color);
border-top: 0;
border-radius: 0 0 var(--input-border-radius-size) var(--input-border-radius-size);
background: var(--jui-dropdown-bg-color);
box-shadow: 0 0.125rem 0.25rem var(--jui-dropdown-shadow-color);
}

Proposed resolution
The css/base/variables.css should be exposed as its own library definition, then have all the libraries which rely on it include it as a dependency.
That way individual components can be used without the global styles.
Remaining tasks
Provide MR
User interface changes
N/A
Introduced terminology
N/A
API changes
N/A
Data model changes
N/A
Release notes snippet
TBD
| Comment | File | Size | Author |
|---|
Issue fork drupal-3554220
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 #2
codebymikey commentedRan
grep -l 'var(--' . -R | sort | uniq | grep -v 'pcss'on the claro theme, and it shows the following files has having custom properties:So I've gone through the individual libraries and added the variables.css as a dependency.
Comment #5
codebymikey commentedComment #6
smustgrave commentedIsn't that a bug in gin_toolbar? That it allows you to use it on a non gin and in turn non claro theme.
Comment #7
codebymikey commentedGoing by the maintainer's comments in #3181937-10: Remove dialog libraries, it appears it's a part of the feature set the module tries to support.
I agree it's probably not best to mix and match theme libraries, but given that the toolbar is shown on both the frontend and backend, some users might prefer having the consistent editing experience when using the gin_toolbar.
Given that it seemed to work before #3253148: Remove IE from core's browserlist, remove non-essential CSS importing and recompile assets, I think declaring the dependency explicitly seems like a viable solution here as there's no easy way for contrib to enforce the inclusion of
variables.cssotherwise, and its inclusion shouldn't break anythingComment #8
smustgrave commentedAlright the change does make sense, and applying locally seems non disruptive. Maybe can land in 11.3 but definitely 11.4
Comment #9
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #10
codebymikey commentedNot sure why the bot flagged it as NW, but MR still applies.
Comment #11
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #12
codebymikey commentedDisabling the review bot.
Comment #13
smustgrave commentedRestoring previous status. I reverted back to 11.x as main was failing and since there's no php changes here I don't think phpcs would be failing.
Comment #15
longwaveBackported to 11.3.x as an eligible bug fix, I don't think this will be disruptive.
Committed and pushed 0d046164d88 to main and 9b17226b4c7 to 11.x and a2ac2dc8228 to 11.3.x. Thanks!