Feature Request: Refactor /me/ styles

[jjchrisdiehl]

What

It may be time to consider refactoring the styling for the updated /me/ profile section. Since the reskin, a handful of small styling bugs have either been introduced or persisted from the pre-reskin version (see pfOicC-jx-p2 and #98606 (comment)).

I noticed that the stylesheet, introduced in May 2024, doesn’t appear to follow a clear design philosophy. This may have been due to time constraints during the a4a reskin rollout. However, over time, the styles have grown more complex, making it increasingly difficult to maintain this page and its subsections. For example, the recent styling issues with the Billing History data views highlight this challenge.

A number of the changes in the stylesheet appear to have been added to override default core component styles, which while by themselves isn't much of an issue, it does add a bit of code debt over time. One example is our use of the Card component across various profile screens, where we override its top and bottom margins in the stylesheet instead of leveraging the built-in compact property. This runs into issues where some of the wildcard children of the parent main element have incongruent styling.

I think @jameskoster hinted at the importance of adhering to or enhancing core components in this comment.

I’m not sure about recent discussions among the Design teams regarding this, so I’ll tag @jasmussen for feedback or to pull in the correct people for this discussion.

Why

The goal would be to review and implement a structured /me/ design system that reduces code leaks to other sections of Calypso and also enhances the developer experience when interacting with this section of the codebase.

How

No response

[github-actions]

OpenAI suggested the following labels for this issue:

• [Feature Group] Appearance & Themes: The issue pertains to the styling of the /me/ profile section, which is directly related to the appearance of the user interface.
• [Feature] User & Account Settings (/me): The request is focused on the settings and configuration tools related to managing the users' accounts, particularly in the /me/ section.
• [Feature] Global Styles: The issue highlights the need for a structured design system which aligns with the functionality of Global Styles used across themes.

[jasmussen]

Great issue, I'd be keen to help, up to and including refactoring the stylesheet entirely, if that helps. Who can I pair with on some of the more react heavy parts?

A number of the changes in the stylesheet appear to have been added to override default core component styles, which while by themselves isn't much of an issue, it does add a bit of code debt over time. One example is our use of the Card component across various profile screens, where we override its top and bottom margins in the stylesheet instead of leveraging the built-in compact property. This runs into issues where some of the wildcard children of the parent main element have incongruent styling.

From my perspective, and the group I work with who has a core first perspective, this is at the heart of many of the issues we've discovered lately, and can really be summarized into the question: why do we override default core component styles at all? I don't mean that question in an accusatory way, but I'd like to specifically understand all the nuance here, so we can revisit this with clear eyes as part of the current effort. My instinct here, namely, is to not override anything at all, perhaps solely the accent color, and doing so only because the theme package does not yet exist.

How can I best help push this forward? And thank you for the ping!

[jameskoster]

@jasmussen Let's keep this section in mind for the forms & settings atelier. Do you think it's still worth prioritising this refactor if we believe most of these pages will eventually migrate to DataForms?

Another item we might consider looking into here is migrating the purchases table to DataViews.

[jasmussen]

Do you think it's still worth prioritising this refactor if we believe most of these pages will eventually migrate to DataForms?

A meta-goal I have for the moment, is to eliminate local CSS written to style things, as much as possible, and to instill a culture where this isn't something that is done. The correct fix is always to update the component itself, if need be, and there are only few exceptions, the accent color being a temporary one.

Migrating to DataForms seeme like it would certainly accomlish the same, so I'm here to support that fully.

Another item we might consider looking into here is migrating the purchases table to DataViews.

@tyxla do you have any thoughts here?

[tyxla]

Another item we might consider looking into here is migrating the purchases table to DataViews.

@tyxla do you have any thoughts here?

Well, some engineering team needs to spike this work - perhaps @Automattic/a8c-payments or @Automattic/florin have that in their short-term plans? In any case, cc @oskosk if this might need additional coordination.

As it's already done for the Billing History, I'd expect it should be easier of a feat - DataViews already support all the custom features, pagination, etc.

Note that the Billing History DataViews work is currently enabled only in some environments and is yet to be enabled in staging / production.

[sirbrillig]

Another item we might consider looking into here is migrating the purchases table to DataViews.

If believe @JessBoctor is planning to work on this. The project thread is here: pfOicC-hF-p2