Refactor garbled class names in Vue components #287

Closed
opened 2022-12-14 22:03:19 +00:00 by pixeldesu · 5 comments
Owner

This is incredibly low priority, but something that both @Johann150 and I already complained about in Misskey to syuilo directly, without ever receiving a clear answer as to why a huge chunk of class names gets manually garbled.

A lot of the styles are scoped, so they can't be overwritten easily anyway (unless you involve a lot of !important).

Just looks cleaner and is easier maintable + still somewhat easier customizable.


The files relevant for this are usually Vue components, considering that's where most of the style definitions live.

I won't make a tracking checklist (for now) because it would probably blow up Gitea, but you can search for all garbled class names using a tool of your choice that supports regex searching.

\.[a-z]{8} \{ in packages/client/src/**/*.vue should return all class definitions.


In most cases, the custom styling is component-specific already, so you can either name the class like the component, or .[component]-container for wrapping elements, etc.

Don't think there have been clear guidelines on CSS naming before, and everything is better than a .asdjhkas class.

This is incredibly low priority, but something that both @Johann150 and I already complained about in Misskey to syuilo directly, without ever receiving a clear answer as to why a huge chunk of class names gets manually garbled. A lot of the styles are scoped, so they can't be overwritten easily anyway (unless you involve a lot of `!important`). Just looks cleaner and is easier maintable + still somewhat easier customizable. ---- The files relevant for this are usually Vue components, considering that's where most of the style definitions live. I won't make a tracking checklist (for now) because it would probably blow up Gitea, but you can search for all garbled class names using a tool of your choice that supports regex searching. `\.[a-z]{8} \{` in `packages/client/src/**/*.vue` should return all class definitions. ---- In most cases, the custom styling is component-specific already, so you can either name the class like the component, or `.[component]-container` for wrapping elements, etc. Don't think there have been clear guidelines on CSS naming before, and everything is better than a `.asdjhkas` class.
pixeldesu added this to the (deleted) project 2022-12-14 22:03:19 +00:00
Owner

A concern I have is that this would break user styles since we "officially" allow users to add their own custom CSS.

While I think we should not use such class names for new things, I don't think there is a point in malproving the existing class names, both of my concern above and because of - as you already pointed out - the work necessary.

A concern I have is that this would break user styles since we "officially" allow users to add their own custom CSS. While I think we should not use such class names for new things, I don't think there is a point in malproving the existing class names, both of my concern above and because of - as you already pointed out - the work necessary.
Owner

I guess we should survey how many people use custom css to guage how much of an impact renaming the classes would have.

I guess we should survey how many people use custom css to guage how much of an impact renaming the classes would have.
Owner

The biggest impact is on us renaming all the shit which I find completely unnecessary.

The biggest impact is on us renaming all the shit which I find completely unnecessary.
Owner

Fair. We should come up with a new naming scheme for new components, but leave the old names untouched for now.

Fair. We should come up with a new naming scheme for new components, but leave the old names untouched for now.
pixeldesu removed this from the (deleted) project 2022-12-14 23:44:47 +00:00
Author
Owner

(Gitea cleared my comment after removing the issue from the project ;_; )

I think we can close the issue then. It's too much work for too little benefit, considering the possibility of breaking custom CSS/userstyles.

If it is required in the future (I don't think so even) we can have a conversation about naming schemes for components. We can probably just do that on IRC if the time comes (of adding some new components) or open a discussion issue for it.

_(Gitea cleared my comment after removing the issue from the project ;\_; )_ I think we can close the issue then. It's too much work for too little benefit, considering the possibility of breaking custom CSS/userstyles. If it is required in the future (I don't think so even) we can have a conversation about naming schemes for components. We can probably just do that on IRC if the time comes (of adding some new components) or open a discussion issue for it.
Sign in to join this conversation.
No labels
feature
fix
upkeep
No milestone
No project
No assignees
3 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: FoundKeyGang/FoundKey#287
No description provided.