Corrected file name from create-subtheme.sh to create_subtheme.sh
The patch failed to apply.
Hi @finnsky
I wanted to push the code changes but facing some issues while rebasing the branch with 1.x. Will try again tomorrow.
Regarding the change you requested which needs globally: .toolbar-button { font-family: var(--admin-toolbar-font-family); }, for .toolbar-button class, the font family is already set. Also, the top bar and admin toolbar fall under different divs, so we have to explicitly set the font family to top bar.
AkshayAdhav → created an issue.
Ok @finnsky. Let me check again.
Added Inter as font family for top bar.
Before:
After:
AkshayAdhav → made their first commit to this issue’s fork.
smustgrave → credited AkshayAdhav → .
Yes @finnsky, @shweta__sharma is correct.
Just by removing @nest there won't be any change in the compiled .css file.
@shweta__sharma - can you please add before and after screenshots?
Hi @shweta__sharma
Thanks for working on this issue. Just FYI it was tagged for novice meaning saved for new users, that's why I have created multiple issues.
Based on your post history, I think you're good to work on non-novice issues.
It also needs before and after screenshots.
AkshayAdhav → created an issue.
AkshayAdhav → created an issue.
AkshayAdhav → created an issue.
AkshayAdhav → created an issue.
AkshayAdhav → created an issue.
AkshayAdhav → created an issue.
AkshayAdhav → created an issue.
AkshayAdhav → created an issue.
AkshayAdhav → created an issue.
AkshayAdhav → created an issue.
AkshayAdhav → created an issue.
AkshayAdhav → created an issue.
ckrina → credited AkshayAdhav → .
AkshayAdhav → created an issue.
AkshayAdhav → created an issue.
@smustgrave attaching the screenshots with the latest changes.
Damn... Then we need to create child tickets for each refactor related issue tickets.
@finnsky I think we should make @nest related changes while refactoring only.
But I guess most of us are missing this point, so we can create new issues if required.
Hi @Gauravvvv
We should not include @nest. That's why I have removed it in my previous commit.
You can check this link for reference.
Hi @finnsky
I have made the required changes for file formatting as well as tried to use variables wherever possible. Apart from properties where values are in decimals.
Also, I have kept the padding-bottom property as it is as per the comment on top of it.
.filterable-option .form-item.form-type-checkbox {
padding-block: calc(var(--space-xs) / 2);
/* This selector is aggressive because Claro's reset for .form-items is aggressive. */
padding-bottom: calc(var(--space-xs) / 2);
padding-inline-start: calc(var(--space-xs) / 2);
}
Oh ok. No problem. I thought you were one of the maintainers.
Let me take a look into it again.
@ckrina
I tested this change on Firefox in Ubuntu. It worked fine on my end.
@BramDriesen I guess you missed adding credits to the people involved.
Hi @shweta__sharma
The issue you have mentioned is about vertical displacement along with the issue of the button's text length.
As this particular issue was closed with wrong property values, it was adding left margin instead of right margin. You can check the screenshots attached in my comment
#45
📌
Refactor Claro's dropbutton stylesheet
Needs review
.
Creating a patch file instead of raising an MR as I am getting issues while creating a new branch from 11.x branch.
In 10.2.x version the code for .form-actions .dropbutton-wrapper was:
.form-actions .dropbutton-wrapper,
.field-actions .dropbutton-wrapper {
margin: var(--space-xs) var(--space-m) var(--space-xs) 0;
}
With this code, the dropdown had proper alignment.
In 11.x version it has been changed to:
.form-actions .dropbutton-wrapper,
.field-actions .dropbutton-wrapper {
margin-block: var(--space-xs);
margin-inline: var(--space-m) 0;
}
And now it's breaking the dropdown alignment.
Steps to reproduce it:
- Install the contrib module
Workbench Moderation →
- Now after enabling the module edit any content type inside the structure and enable the moderation from the Manage moderation tab.
- Now create new content of the respective content type and now you can see the issue.
AkshayAdhav → made their first commit to this issue’s fork.
@smustgrave yes, there is no difference in the compiled CSS file, that's why it's not showing up in the git diff.
Looks good to me.
Could not work on it. So removing the tag ClaroContributionDay2023
Working on this issue as a part of Claro Contribution Day.
AkshayAdhav → changed the visibility of the branch 3332743-claro-views-ui-refactor to hidden.
Made required changes. Removed @nest from the code as per guidelines mentioned here.
Please find attached images for before and after of both LTR and RTL language patterns.
Working on this issue as a part of Claro Contribution Day.
I tried with recent 2-3 patches along with MR from @ameymudras. I can say that it's not fixing the issue for nested paragraphs.
I can think of 2 solutions:
- If we need to fix this issue in Claro theme: increase the available area of the content edit form (i.e.
layout-region--node-main) and make it 100%, so that paragraphs can accommodate properly in it. The reason is that nested paragraphs are being placed in<table>tag. These table tags have a width of 100% and which is overflowing outside the available area. - As in most places
<table>creates such overflow issues. It will be great to change the structure of nested paragraphs by using other tags than the<table>tag. And restructure it. I know this is a very time-consuming solution that needs to be handled at the Paragraphs module level.
It's not related to CKEditor. So removing the CKEditor 5 issue from the related issue.
Yes, as @bjc2265 mentioned this issue is not reproducible in Claro. So changing the version to 9.1.x-dev as Claro was introduced in core after 9.2 version.
AkshayAdhav → made their first commit to this issue’s fork.
As per the updated IS, changed .tooltip to .toolbar-tooltip. Created separate branch and MR to avoid confusion.
AkshayAdhav → made their first commit to this issue’s fork.
AkshayAdhav → created an issue.
@saschaeggi Yes, it seems outdated. No issues were found in the latest version.
It's good to close.
Drupal 10:
Drupal 9:
Yes @saschaeggi, it seems like the help icon itself is removed in the latest update.