Opened 10 years ago
Last modified 5 years ago
#31006 new enhancement
Use classes instead of setting and directly animating background colors in JS
Reported by: | helen | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | minor | Version: | |
Component: | Administration | Keywords: | needs-patch |
Focuses: | ui, javascript | Cc: |
Description
Directly setting hex values in JS doesn't tell us much about what the color is being used for, whereas setting a class name is much more semantic. Also, jQuery UI can animate color changes when using addClass/removeClass/toggleClass/switchClass - no need to use .animate() directly and do things like getting background colors of surrounding elements.
This is very tightly related to #25060 and blocks it. I am working on it.
Attachments (1)
Change History (6)
#1
@
10 years ago
- Component changed from General to Administration
- Focuses administration removed
- Keywords has-patch added
- Type changed from enhancement to task (blessed)
This ticket was mentioned in Slack in #core by drew. View the logs.
10 years ago
#4
@
9 years ago
- Keywords needs-patch added; has-patch removed
- Milestone changed from 4.2 to Future Release
- Severity changed from normal to minor
- Type changed from task (blessed) to enhancement
I'm punting - this was exhausting to wrap my head around early on in the cycle, and it's near-impossible to get back into in the beta stage. It's not critical, but at least it is unblocked now. Anybody is free to pick this up if they want, highly suggest documenting possible approaches first before going all-in with a patch.
Here are my collected thoughts distilled:
- Use state-indicating classes for the colors and define the colors in CSS, e.g. "is-deleted" with a red color.
- Use a data attribute to define what class is applied during the transition period.
- Undecided whether we should handle color animation via jQuery UI (introducing that dependency in more places), or via CSS.
- Very few plugins are using the hex values directly in the current data attribute, so don't worry about retaining that color (back compat). Do not change the current data attribute's format, though - if it contains a colon, continue to split it the current way. New implementations should then not have any colon-separated values in data attributes. Showing a different color for the transition state is not severe breakage, so I am not worried about dropping it.
- Try to avoid doing a total refactor, as this is so old it's not realistic for it to last forever even if rewritten. But, if it requires it, then we should talk about that further so we don't bind ourselves into an API that we would kill off eventually.
@helen: Any update on progress with this?