I've formatted it with comments in the selector and broke the selector into newlines — and this is still valid CSS, as the amount of whitespace doesn't matter and comments can be almost anywhere! These two things make it much easier to figure out what's going on, and adapt it in the future, if Google decides to change their widgets.
While it is more generic, it can specifically target parts on the page better, as the widgets do not change every rebuild... and this should therefore make the selectors much more robust.
Obviously, a lot of selectors would use a lot of the same targeting (like everything up to the primary selector list for inbox, starred, snoozed, etc.), so building selector strings from pieces would make sense too.
Anyway, I'm suggesting this to reduce the amount of cat-and-mouse chasing the extension would have to do in the future.
Thanks Garrett, appreciate the feedback! :)
This makes perfect sense. The only thing I'd need to investigate is how likely it is that the DOM structure would change (e.g. as part of the UI is loaded dynamically).
Hi all! Thanks! This extension is quite neat. (I'm using it in Firefox.)
In https://github.com/kallepersson/inboxtheme/blob/master/src/nodes.js & https://github.com/kallepersson/inboxtheme/blob/master/in.css, I see selectors are usually class-based. The obvious problem is that the class and ID names are generated each time GMail is rebuilt.
I suggest using selectors based on the DOM hierarchy instead.
For example, here's one to target the Inbox label:
I've formatted it with comments in the selector and broke the selector into newlines — and this is still valid CSS, as the amount of whitespace doesn't matter and comments can be almost anywhere! These two things make it much easier to figure out what's going on, and adapt it in the future, if Google decides to change their widgets.
While it is more generic, it can specifically target parts on the page better, as the widgets do not change every rebuild... and this should therefore make the selectors much more robust.
Obviously, a lot of selectors would use a lot of the same targeting (like everything up to the primary selector list for inbox, starred, snoozed, etc.), so building selector strings from pieces would make sense too.
Anyway, I'm suggesting this to reduce the amount of cat-and-mouse chasing the extension would have to do in the future.