1699606 - Clean up common.css platform-specific styles

Status: NEW

(Toolkit :: Themes, task, P3)

Description

[Tim Nguyen :ntim]

Lots of the common.css platform-specific styling are overrides for platform-specific toolkit styles. Now that proton is sharing quite a lot of few of these toolkit styles, it might be worth giving a pass and see what overrides can be cleaned up or shared (menulist is one that comes to mind).

Comment 1

[:Gijs (he/him)]

Mike, can you help me understand what could be done here and assign a point value? I had a quick look, and although there are similar menulist rules in the 3 platform-specific common.css sheets, they all differ slightly, and the point of this bug is not clear to me - that is, what exactly can be cleaned up / shared how? Are we trying to move styles to common.inc.css, or remove them altogether because they're redundant, or move them to toolkit (non-in-content) styling because we use them outside of in-content pages, and only the [native] ones should keep their existing "native" styling? I can't tell from comment #0.

Comment 2

[Mike Conley (:mconley) (:⚙️)]

I can't speak for ntim, but I can offer my own opinion on what to do here.

I think, ideally, we'd have one chunk of CSS to describe how form controls look in both the native and non-native modes. I guess it gets a little complicated when some documents want to style those form controls differently based on their contexts - like, potentially there are instances where documents are loaded in a window and we want them to look native, and other times they're loaded in content and we want them to look non-native? I guess that's when the ideal scenario falls over a little. Are there any remaining cases like that?

If not, then I think the solution is to have all of the non-native form control stylings converge and be shared in their inc.css files, and have the native stylings be defined inside of the platform-specific control.css files, have those CSS files be imported into the in-content pages, and then to remove the common.css styles for those controls.

Again, I think this falls over if any of those documents want to show non-native in one context, and native in another context.

I'd say, point-wise, this is an 8 - but I think most of that work is likely going to be at the beginning (scouting, looking for confounds) and ending (making small adjustments to all of the documents that might be impacted by any changes resulting from the de-duplication).

Does that help?