-
-
Notifications
You must be signed in to change notification settings - Fork 436
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deprecate decorate*() JS functions #3043
Comments
I'd love to drop them :-) |
Previous discussion about Maybe instead of removing, we can add a config setting to enable / disable them? Something like a "legacy theme compatibility" switch? That way, you can disable to improve performance if needed. |
Thanks for referencing #1073 I hadn't found that one yet. This project requires PHP 7.3 which was released in december 2018. Meanwhile, the CSS discussed in this issue has been supported in Chrome since 2010 (https://caniuse.com/css-sel2). I just wanted to point that out, it seems like a huge difference between how frontend and backend code is viewed by some. To be brutally honest I don't have these functions on my own template anymore, so I'm good if it stays. |
@loekvangool I think the hesitation about removing it from the theme was that perhaps there is JS out there that finds nodes based on these classes and manipulates the DOM expecting these classes. If nothing else, I'd be happy to make a PR to implement the config in the admin, but I don't even use the default theme either so I wouldn't be able to give it a good testing. |
Just kill it with fire :) |
Yes that's clear, however we require PHP 7.3 which means all users need to go through their code to fix stuff that does not work anymore. It seems fair to declare a decent interval in which OM expects users to update their code? If you mean code that's part of OM that needs I just noticed that these functions are in |
Yes, that's fair that users should be expected to maintain their 3rd party modules and I'm certainly not against the removal of these functions -- especially in 20.x. Mainly I wanted to link the previous discussions about it and make sure everything was considered.
If we decide to go the route of a config option, we can set a JS variable like how I did in this PR: https://github.com/OpenMage/magento-lts/pull/2426/files#diff-1949685fb6f678895c467342c6ed455ed44726a6eb66f9dcb0ee9beb07088880 And then in the JS file check something like this at the top of the decorate functions. function decorateGeneric(elements, decorateParams)
{
if(window.NO_DECORATE)
return
// ... |
Im against adding config for acient js stuff like this. It just clutters the codebase. If somebody wants to make frontend in 2023 like it was 2010 then he is on his own. |
I also don't like configuration options, especially for this kind of stuff. ancient stuff needs to go and developers have to know that some work is needed when upgrading (like with every other kind of software) |
Then 🔥🔥🔥 it is |
Since #1073, I replaced all decorate functions with (to avoid function decorateList() {
console.warn('decorateList is deprecated');
} |
I have a PR for that if interested (the removed part of 1073). |
i'd even just function |
I think that, in 2023, we should rethink the decision of #1073 (comment) and drop this funcions in v21 |
Description (*)
JavaScript functions like
decorateTable()
are popular in the templates. Their purpose is to add CSS classesodd
,even
,first
,last
to HTML tables, lists, etc.This seems wildly outdated and requires browser repainting, leading to lower Web Vitals scores. CSS3 can easily target these entities without writing classes with JavaScript after initial page load.
Note: Even when there are no actual visual changes, Chrome still reports a repaint and deducts points. These functions should not be used.
The text was updated successfully, but these errors were encountered: