Follow-up to #1342054: [META] Clean up templates and CSS

Problem/Motivation

  1. Bartik's template files need to be assessed and cleaned up of redundant markup, bad formatting and ID's.
  2. Bartik's CSS files need to follow Drupal's CSS Coding Standards.

Proposed resolution

For this issue we take "secondary-menu.css" within Bartik in css/components/secondary-menu.css plus any template file associated with the CSS and clean them up.

Remaining tasks

  • Write a patch containing as much as the above as possible.
  • Post a patch with screenshots.
  • Visual review of a patch - check the secondary menu visually with and without patch applied. Take screenshots.
  • Code review of a patch - check the code follows coding standards, suggest improvements if needed in a comment.
  • Produce a new patch with improvements if needed.

User interface changes

None

API changes

None

Data model changes

None

Beta phase evaluation

Reference: https://www.drupal.org/core/beta-changes
Issue category Task because it is refactoring CSS and templates in Bartik
Issue priority Not critical because Bartik functions fine we are just doing cleanup tasks
Unfrozen changes Unfrozen because it only changes CSS and markup
Prioritized changes The main goal of this issue is usability of the Bartik's codebase
Disruption non-Disruptive as it is just changing markup and CSS

CommentFileSizeAuthor
#71 After patch BT.png59.31 KBAamir M
#71 Before patch BT.png70.37 KBAamir M
#70 Afetr patch code.png232.38 KBbebalachandra
#70 After Patch.png77.88 KBbebalachandra
#70 Before patch.png86.63 KBbebalachandra
#69 interdiff_65-68.txt1.46 KBsahil.goyal
#68 2502049-68.patch918 bytessahil.goyal
#67 After patch m BT.png151.44 KBAamir M
#67 After patch BT.png143.01 KBAamir M
#67 Before patch BT.png140.52 KBAamir M
#65 interdiff_62-65.txt453 bytespradhumanjain2311
#65 2502049-65.patch1.82 KBpradhumanjain2311
#62 2502049-62.patch1.82 KBShubham Chandra
#59 Applied Patch 2502049.png213.48 KBchetanbharambe
#59 After Patch 2502049 up.png347.75 KBchetanbharambe
#59 Before Patch 2502049 up.png360.45 KBchetanbharambe
#58 afterpatch.png59.6 KBAsha Nair
#58 applyingpatch.png65.28 KBAsha Nair
#57 2502049.57.patch2.45 KBSakthivel M
#56 After Patch 2502049.png413.21 KBchetanbharambe
#56 Before Patch 2502049.png401.43 KBchetanbharambe
#55 afterpatch.png81.11 KBRinku Jacob 13
#55 beforepatch.png83.68 KBRinku Jacob 13
#54 2502049.54.patch1.76 KBSakthivel M
#46 2502049-41.patch1.76 KBkaythay
#38 2502049-38_Replace_the_Secondary_menu_component_with_a_reusable_component_in_Bartik.patch2.4 KBdcrocks
#38 interdiff-2502049-35-38.txt1.25 KBdcrocks
#35 interdiff-2502049-34-35.txt466 bytesdcrocks
#35 interdiff-2502049-34-35.txt466 bytesdcrocks
#35 2502049-35_Replace_the_Secondary_menu_component_with_a_reusable_component_in_Bartik.patch2.3 KBdcrocks
#34 interdiff-2502049-27-34.txt377 bytesdcrocks
#34 2502049-34_Replace_the_Secondary_menu_component_with_a_reusable_component_in_Bartik.patch2.21 KBdcrocks
#29 menus.jpg81.53 KBdcrocks
#27 interdiff.txt2.37 KBHOG
#27 Replace_the_Secondary_menu_component_with_a_reusable_component_in_Bartik_2502049-27.patch2.22 KBHOG
#23 interdiff-2502049-14-22.txt514 bytesdcrocks
#22 secmenuall.jpg78.1 KBdcrocks
#22 2502049-22_Replace_the_Secondary_menu_component_with_a_reusable_component_in_Bartik.patch2.32 KBdcrocks
#18 everything logged out.jpg65.41 KBdcrocks
#18 everything logged in.jpg78.87 KBdcrocks
#17 secmenu-user-login-logged-out.jpg60.61 KBdcrocks
#17 secmenu-userlogin-loggedin.jpg81.84 KBdcrocks
#17 secmenu-anon.jpg53.97 KBdcrocks
#17 secmenu.jpg77.51 KBdcrocks
#17 interdiff-2502049-14-17.txt896 bytesdcrocks
#17 2502049-17_Replace_the_Secondary_menu_component_with_a_reusable_component_in_Bartik.patch2.3 KBdcrocks
#14 secmenu.jpg61.48 KBdcrocks
#14 interdiff-2502049-13-14.txt1.59 KBdcrocks
#14 2502049-14_Replace_the_Secondary_menu_component_with_a_reusable_component_in_Bartik.patch2.26 KBdcrocks
#13 2502049-13_Replace_the_Secondary_menu_component_with_a_reusable_component_in_Bartik.patch2.23 KBdcrocks
#8 secondary-links.png41 KBManjit.Singh
#8 rtl-secondary-links.png40.85 KBManjit.Singh
#8 ltr-secondary-links-mobile.png22.17 KBManjit.Singh
#8 rtl-secondary-links-mobile.png22.14 KBManjit.Singh
#7 2502049-7_Clean_up_the_Secondary_menu_component_in_Bartik.patch1.35 KBdcrocks
#4 new region sidebar second.jpg47.61 KBdcrocks
#4 new region secondary menu.jpg30.04 KBdcrocks
#4 old region sidebar second.jpg44.08 KBdcrocks
#4 old region secondary menu.jpg23.46 KBdcrocks
#4 2502049-4_Clean_up_the_Secondary menu_component_in_Bartik.patch995 bytesdcrocks

Issue fork drupal-2502049

Command icon 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:

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

emma.maria’s picture

From looking at the secondary-menu.css file I see that we need to include the same refactoring solution that we will add to the Primary menu issue #2502045: Replace the "Primary menu" component with a reusable component in Bartik., which will consider the following...

We should not name CSS selectors based on the location the component is sat within. If someone wants to move/reuse the Secondary menu they can't. Also this method can cause really long over specific selectors that we can improve.

Therefore we need to come up with a solution to be able to apply styles using a resuable component class such as .secondary-menu or .secondary-menu--block (name to be decided based on the component it is added to) instead.

We also need the usual clean up of comment formatting within the CSS file also.

Anonymous’s picture

Assigned: Unassigned »

I want try to fix it.

Anonymous’s picture

Assigned: » Unassigned

I've looked at this and it seems we need to change menus logic to separate it from region context. May be we need to make separate templates for primary secondary menu - but I don't imagine how will drupal know which menu is it. Can you help me with some advice please.

dcrocks’s picture

This looks like it might be a start, but it definitely needs review. There are differences, but these are based on code in the region component css(sidebars.css in this case) that perhaps shouldn't be there

dcrocks’s picture

Even if this patch is acceptable, it might not be possible to do it until other bartik css components are cleaned up. All the region components have a lot of stuff that shouldn't be there. Region components should be for layout and region specific styling but there seems to be a lot of very targeted styling for other components.

dcrocks’s picture

dcrocks’s picture

Manjit.Singh’s picture

Status: Needs review » Reviewed & tested by the community
FileSize
22.14 KB
22.17 KB
40.85 KB
41 KB

Tested Secondary links manually after applying patch.
Please check screenshots of mobile and Desktop.

emma.maria’s picture

Status: Reviewed & tested by the community » Needs review

Setting back to Needs Review as the patch needs a code review also.

emma.maria’s picture

Title: Clean up the "Secondary menu" component in Bartik. » Replace the "Secondary menu" component with a reusable component in Bartik.

@dcrocks thanks for the patch!

This issue is very similar to #2502045: Replace the "Primary menu" component with a reusable component in Bartik. so I repeat my comment from there.

The issue we need to solve here is to not rely on the region markup or limit the styles to one particular instance of menu. We want any menu added to this region to have the "secondary navigation" styles. The default provided menu in the region should also not look the same wherever it's placed, the styles should default to basic menu list styling elsewhere.

Therefore we need to add a reusable component class to menu blocks when they are added to the currently named "Secondary menu" region and amend the current CSS to use that class.

emma.maria’s picture

Issue summary: View changes
emma.maria’s picture

Status: Needs review » Needs work
dcrocks’s picture

Restart here in same style as #2502045: Replace the "Primary menu" component with a reusable component in Bartik. plus small spaceing change so contextual link wouldn't hide last menu item.

dcrocks’s picture

Here is another go. I made these changes:
Modified region--secondary-menu.html.twig as suggested by @laurii
added code to make the title of any block in the secondary menu region hidden

It appears to me that hiding block labels is the design choice for all of the header regions but this may have undesirable results, depending on the block. See attached.

dcrocks’s picture

Two things to note:
1) No content displayed in secondary menu region when logged out, ie, as anonymous user. So it would be unwise to put the user login form in the secondary menu region.
2) There is no code in secondary-menu.css that affects forms, except for block label, so they should display as usual.

dcrocks’s picture

Take back some of my comments. Forms do or do not display properly with respect to being logged out vs logged in.

dcrocks’s picture

Made some small changes and I think menus display without block labels but everything else still do. Also added images to show differences logged in vs logged out. Still more tweaks needed.

dcrocks’s picture

I'd like to see if I'm using the right assumptions for the secondary menu region:

1) All menu blocks have horizontal display and are aligned right (rtl).
2) All other blocks are aligned left (rtl).
3) All labels and text for (a) elements have (near) white color.
4) Block labels are not displayed for menu blocks but are for all others.

I have 2 images that show what it looks like to have most blocks in the secondary menu region. I would like some comment before I make the final changes based on those assumptions.

dcrocks’s picture

Just a question. What is the purpose of the colors.css file? It isn't the sole proprietor of 'color:' statements and contains a hodgepoge of code that would make more sense to be with the components actually affected. It doesn't really save that many bytes by combining similar statements in one place but does add the load of an additional file. What component does this file actually correspond too?

dcrocks’s picture

Issue summary: View changes
dcrocks’s picture

Looking at #10 again, I have probably done too much. If that is so, I can supply a menu only patch(#14?) and not worry about other blocks being placed in the secondary menu region.

dcrocks’s picture

This is a slightly tweaked version of #14 that only affects menus that might be placed in the secondary menu region. The image shows if user account, main menu, tools menu, and footer menu were all in the secondary menu region.

dcrocks’s picture

FileSize
514 bytes

Here is diff as well

emma.maria’s picture

Hi @dcrocks I posted a reply to your same question about colors.css here.

emma.maria’s picture

Status: Needs review » Needs work

Thanks @dcrocks for working on this issue.

I applied the patch in #22 and found no visual regressions.

The Twig template looks great apart from the extra line space at the bottom of the file.

I noticed some improvements for the CSS.

  1. +++ b/core/themes/bartik/css/components/secondary-menu.css
    @@ -1,24 +1,33 @@
    +.secondary-menu .menu {
       text-align: right; /* LTR */
       font-size: 0.929em;
    -  margin: 0 10px;
    +  margin: 0 23px;
       padding: 0;
     }
    

    Why was the margin changed to 23px? Also can it please be changed to 15px to be consistent with the layouts of all of the other regions.
    And can the margin please be moved to the .layout-secondary-menu selector, it is layout styles for the region.

  2.  

  3. +++ b/core/themes/bartik/css/components/secondary-menu.css
    @@ -1,24 +1,33 @@
    +.secondary-menu .menu-item {
       margin: 0;
       padding: 0;
       display: inline;
     }
    

    We can remove the margin: 0 it is already declared by .menu-item.

  4.  

  5. +++ b/core/themes/bartik/css/components/secondary-menu.css
    @@ -1,24 +1,33 @@
    +.secondary-menu .block > h2 {
    +  /* @extend .visually-hidden */
    +  position: absolute !important;
    +  clip: rect(1px, 1px, 1px, 1px);
    +  overflow: hidden;
    +  height: 1px;
    

    We shouldn't purposively hide things via theme CSS, please remove this code. The block title is also already hidden by the visually-hidden class also.

  6.  

  7. secondary-menu.css does not have a blank line at the end.
emma.maria’s picture

Issue tags: +Novice
HOG’s picture

Added changes to #22 patch.

dcrocks’s picture

@emma.maria

#1: I changed this because the contextual help icon floats on top of the menu, obscuring it from view.

#3: I thought that we needed to make it so any menu added to the secondary menu region would have the same appearance as the user account menu. Most other menus do not have the menu label turned off by default as the user account and main menu do.

dcrocks’s picture

FileSize
81.53 KB

This is what it looks like to add other menus(Tools, Main) to the secondary menu region in a current clone of 8.0.0. As you can see the block label for the Tools menu block is displayed on a separate line from the rest of the menu. This doesn't fit the styling for the secondary menu region(or the primary menu region). I thought from #10

We want any menu added to this region to have the "secondary navigation" styles

we needed to make them match style. There may be other, programmatic, ways than css to remove labels from menu blocks when in the secondary or primary menu regions and I will look for them if that is what you would prefer. But I would mention the "visually-hidden" css is used in other places in bartik.

emma.maria’s picture

#1: I changed this because the contextual help icon floats on top of the menu, obscuring it from view.

We shouldn't tackle that in this issue, this is a code cleanup issue only. This other issue handles that topic #2355501: Contextual link triggers cover too much of small contextual regions.

For

This doesn't fit the styling for the secondary menu region(or the primary menu region).

But I would mention the "visually-hidden" css is used in other places in bartik.

Yes it is used in other places in Bartik but we are actively trying to remove them amongst the clean up issues. The footer no longer has this behaviour, we haven't got to the header part of the site yet.

If the title shows for any further menu blocks added the user can toggle the display of the title through the UI which is expected behaviour for blocks.

dcrocks’s picture

Actually a user can toggle 'Display Title' on or off only thru the 'Place Block' forms. If a user simply 'moves' an existing block from one region to another, there is no option to change it. Might not be a big deal but still another UI mystery.

emma.maria’s picture

#31 erk that is not a not fun UI bug.

I am going to review the code in #27, thanks @HOG for the patch.

Bojhan’s picture

I discussed this with emma.

We should be supporting adding menu's to this region. We shouldn't special case block titles, or other block elements - as the primarily purpose is for menu's. The design doesn't support this.

dcrocks’s picture

dcrocks’s picture

dcrocks’s picture

This still applies and could use some attention.

dcrocks’s picture

emma.maria’s picture

Version: 8.0.x-dev » 8.1.x-dev

Yes this does needs attention :) However this work is now for the 8.1.x branch as this is an improvement to Bartik and not a bug, the patch still applies cleanly.

emma.maria’s picture

Version: 8.1.x-dev » 8.0.x-dev

I take that back I spoke to @davidhernandez. Anything that requires a change record should be 8.1 only everything else for Bartik can stay in 8.0.x.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

kaythay’s picture

Version: 8.5.x-dev » 8.6.x-dev
FileSize
1.76 KB

No changes made, just reroll.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Sakthivel M’s picture

Status: Needs review » Needs work
Issue tags: +Needs reroll
Sakthivel M’s picture

Status: Needs work » Needs review
FileSize
1.76 KB

#54 Please review the patch

Rinku Jacob 13’s picture

FileSize
83.68 KB
81.11 KB

patch#54 applied successfully for drupal 9.3.x-dev.but the menu is not visible as much as.Adding screen shot for the reference

chetanbharambe’s picture

Status: Needs review » Needs work
FileSize
401.43 KB
413.21 KB

Verified and tested patch #54.
Patch applied successfully but not working as expected.

Issue Description: Replace the "Secondary menu" component with a reusable component in Bartik

Actual Results:
# Secondary menu is not visible cleanly after applying the patch.
# Secondary menu aligned as vertically (should be aligned horizontally)

Please check the attached screenshot.
Moving to needs work.

Sakthivel M’s picture

Status: Needs work » Needs review
FileSize
2.45 KB

#57 Please review the patch

Asha Nair’s picture

FileSize
65.28 KB
59.6 KB

I have applied patch #57 for drupal 9.3.x-dev. But I can't see any changes.

chetanbharambe’s picture

Status: Needs review » Needs work
FileSize
360.45 KB
347.75 KB
213.48 KB

Hi @Sakthivel M,
Thanks for patch #57

The patch is applied successfully but not working as expected
Please check the comment mentioned in #56 (Actual Results)

Currently, As a user, I am not able to see any changes after applying patch #57
Please check the attached screenshots.

Moving to needs work.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Shubham Chandra’s picture

Issue tags: -Needs reroll
FileSize
1.82 KB

Rerolled patch against #57 in 9.5.x

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

reenaraghavan made their first commit to this issue’s fork.

pradhumanjain2311’s picture

Version: 10.1.x-dev » 9.5.x-dev
Status: Needs work » Needs review
FileSize
1.82 KB
453 bytes

Fix CS error by removing space.

Aamir M’s picture

Assigned: Unassigned » Aamir M
Aamir M’s picture

Assigned: Aamir M » Unassigned
Status: Needs review » Needs work
FileSize
140.52 KB
143.01 KB
151.44 KB

Patch #65 was applied successfully but the Secondary menu is not visible properly after applying the patch.
Even when you hover the mouse over a link (i.e My account or Log out) then the link is not properly visible.

Screenshots are attached for reference
Hence moved to needs work

sahil.goyal’s picture

Issue summary: View changes
Status: Needs work » Needs review
FileSize
918 bytes

Hi, Providing the updated patch as per considering the issue about Bartik's CSS files need to follow Drupal's standard. As well as per the #67 comment that Secondary menu is not visible properly after applying the patch it move the the left, color got detach and inline css left over. So here is the updated Patch.

sahil.goyal’s picture

FileSize
1.46 KB

Uploading the intradiff file as missed

bebalachandra’s picture

FileSize
86.63 KB
77.88 KB
232.38 KB

#68 patch applied successfully on Drupal 9.5. Issues stated in #67 resolved.
Keeping this issue in needs review for further discussions.
Adding screenshots for reference

Aamir M’s picture

Status: Needs review » Reviewed & tested by the community
FileSize
70.37 KB
59.31 KB

Patch #68 was applied successfully and also when the mouse hovers over the My Account/Logout link then it's properly visible

Screenshots are attached for the reference
Looks good to me
Hence moved to RTBC

bnjmnm’s picture

Status: Reviewed & tested by the community » Postponed (maintainer needs more info)
Issue tags: +Needs issue summary update
  1. +++ b/core/themes/bartik/css/components/secondary-menu.css
    @@ -1,19 +1,24 @@
    +.layout-secondary-menu {
    

    Where/when does the .layout-secondary-menu class appear?

  2. +++ b/core/themes/bartik/css/components/secondary-menu.css
    @@ -1,19 +1,24 @@
    +  margin: 0 15px;
    

    The issue summary states this is for cleaning up the CSS. This is changing the margin amount. Not clear what the intent is here. Perhaps it's evident by reading through all the comments, but an issue summary update would be preferable

In general it isn't clear how the reported issue translates into the patch that was RTBCd.

It's also worth acknowledging that Bartik is deprecated in 9.5. This is the last version of Drupal core it will appear in. If this isn't a bug fix it may not be worth addressing (the only bugs I can see are ones introduced by earlier iterations of the patch).

Feuerwagen’s picture

Project: Drupal core » Bartik
Version: 9.5.x-dev » 1.0.2
Component: Bartik theme » Code
Status: Postponed (maintainer needs more info) » Needs work
Issue tags: -frontend