Refactor garbled class names in Vue components #287
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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} \{
inpackages/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.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.
I guess we should survey how many people use custom css to guage how much of an impact renaming the classes would have.
The biggest impact is on us renaming all the shit which I find completely unnecessary.
Fair. We should come up with a new naming scheme for new components, but leave the old names untouched for now.
(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.