The Needs Review Queue Bot → tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".
Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.
Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.
- Status changed to Needs review
over 1 year ago 3:29am 11 April 2023 - 🇮🇳India gauravvvv Delhi, India
Patch #3, no longer applies as #18. I have re-rolled the patch. please review
- Status changed to Postponed: needs info
over 1 year ago 1:14am 12 April 2023 - 🇺🇸United States smustgrave
We have css in tabledrag.css for menu-item__link, are we 100% sure it's not used.
- Status changed to Needs review
over 1 year ago 2:39am 12 April 2023 - 🇮🇳India gauravvvv Delhi, India
We have css in tabledrag.css for menu-item__link, are we 100% sure it's not used.
.touchevents .draggable .menu-item__link { padding-top: var(--space-xs); padding-bottom: var(--space-xs); }
This CSS is applied to mobile devices, as the `.touchevents` class is available their only. But it doesn't have any effects on the element. As the parent element have property `vertical-align: middle;`. There is no need to align element by padding. I have added a screen recording for reference.
- Status changed to RTBC
over 1 year ago 1:27pm 12 April 2023 - Status changed to Needs work
over 1 year ago 3:59am 15 April 2023 The 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 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.
- last update
over 1 year ago 29,300 pass - Status changed to RTBC
over 1 year ago 4:32am 21 April 2023 - last update
over 1 year ago 29,300 pass - Status changed to Needs work
over 1 year ago 11:14am 21 April 2023 - 🇬🇧United Kingdom catch
#21 sounds good but if so shouldn't we also remove that CSS rule? Or at least open a follow-up.
- Status changed to Needs review
over 1 year ago 3:14am 24 April 2023 - 🇮🇳India gauravvvv Delhi, India
I have opened up a follow up issue for same.
📌 Removed unused CSS from tabledrag.css file Closed: duplicate - 🇮🇳India Santosh_Verma
#catch i have tested the comment #27 mentioned issue, ( https://www.drupal.org/project/drupal/issues/3355904 📌 Removed unused CSS from tabledrag.css file Closed: duplicate ).
Unused css removed after the MR,
for reference i am also adding the screenshot here.before
after
- Status changed to RTBC
over 1 year ago 7:49am 24 April 2023 - last update
over 1 year ago 29,303 pass - 🇮🇳India Santosh_Verma
Tested the comment #19
class removed from the element
before
after
- last update
over 1 year ago 29,302 pass - Status changed to Needs work
over 1 year ago 7:22pm 27 April 2023 - 🇺🇸United States bnjmnm Ann Arbor, MI
If you review this change with core's default styling (Stark), it looks like removing this class results in the label and tabledrag handle not being aligned. This would be a regression seen by sites not using Claro.
Because the issue was filed 9 years ago, there's a high likelihood that some sites have CSS expecting this class to be there. At the very least, the Stable 9 theme would need logic that keeps this class present so it maintains the "stable promise"
However, the image above also indicates that this class is not irrelevant. We could not remove it + all corresponding CSS. Refactoring would be needed, not just removal. At that point, there's a risk of disrupting existing sites to provide a class with a slightly better name, so I'm not sure how much incentive there is to make this change vs the disruptions it might cause + adding the Stable9 layer.
(if there's a decision to go ahead with this, there are comments in the code referencing this class that were not part of the patch. If we're removing something, all artifacts of it should be removed)