-
Notifications
You must be signed in to change notification settings - Fork 17
EQCSS is initiating others CSS files and lead to timeload issues #310
Comments
If you are certain you don't need to parse EQCSS styles from a CSS stylesheet you can add |
@tomhodgins Thank you for reacting to this, this is very kind! However, this does not help at all. How should I add a custom attribute to every loaded style of a Wordpress instance? I would need to instantiate EQCSS and tell him which file I need to process, or, at least, I would need an argument like Is there any planned update about this maybe? Thanks a lot. |
document.querySelectorAll('link, script, style')
.forEach(tag => tag.setAttribute('data-eqcss-read', true)) This JS code, after the Also, I believe the first time it loads may be the only time this XHR happens - after the browser knows the file has been loaded, the XHR goes to cached file, rather than making a new request for a file the browser knows it has already loaded.
No, especially no breaking changes. I have other element query plugins you can use if you want similar functionality but that functions in a different way, like jsincss-element-query which runs entirely from JS. |
Yes, you right.
I do not really like the JS script adding Regards. |
Thanks a lot for the input. Maybe we cannot do much about inserting anything automatically but we could for sure get some instructions for end users on how to have their theme implement the fix. |
The only real solution I see would be to be able to tell EQCSS to only parse styles that have a |
A breaking change like that to how styles are loaded would break all of the (hundreds of) sites using EQCSS presently, so such a drastic change to how the plugin works cannot be made at this point. If you can show me where you've used the element queries, and what features of EQCSS you need, I'm very confident we could switch it to another element query plugin that doesn't even have the capability for XHR-loading styles in the first place. There are plenty of other viable options, some that even perform better than EQCSS, but breaking EQCSS for all users to solve this problem isn't an option. |
I do not really understand why adding an option would be a breaking change. I'm not asking to change the whole default behavior, you can keep it unchanged. However, there are many ways to pass some options to EQCSS, to tell him how it should interact with the stylesheets. Like any other JS/jQuery plugin, you could allow us to pass some options array like below
Sure :) Thanks. You can view it live on http://demos.wp-customerarea.com/freelancers/customer-area/files/my-files/ |
Hi @tomhodgins , Hope you are fine. I saw that you recently updated EQCSS. I was wondering if you plan to add some options to only parse given files, instead of parsing every file except excluded ones? I temporarily fixed our issue by adding a JS script that adds a Best regards. |
I don't see this changing in EQCSS any time soon, the core parts of the EQCSS experience are that you can include it in any browser and all your styles are upgraded without any further work on your part, and that it suppports IE8, so even in a browser so old it doesn't have CSS media queries - you can have element queries and all these features with zero configuration just by including the JS files once. But the same experience that makes EQCSS flexible in some ways (many features, good support) limit it in other ways like you're pointing out. To change it would break all of the sites out there currently using it - so how can we pursue better performance and more flexibility without touching EQCSS? EQCSS has the features of about 20 individual plugins all rolled into one (it's big), so if you only need width-based element queries it can also be overkill. I have another plugin called jsincss which is simply a virtual stylesheet manager. It doesn't read your CSS at all, it just creates If you're looking for more performance, and IE8 support isn't a concern, I'd recommend having a look at jsincss + jsincss-element-query (modular, good performance) for replacing EQCSS (complete, good browser support). Just for an example, here is the same demo, one in EQCSS and one with jsincss + jsincss-element-query. Compare these in complexity, and performance: <div>Make me 500px+ wide</div>
<style>
@element div and (min-width: 500px) {
:self {
background: lime;
}
}
</style>
<script src=https://elementqueries.com/EQCSS.js></script> <div>Make me 500px+ wide</div>
<script type=module>
import jsincss from 'https://unpkg.com/jsincss/index.vanilla.js'
import element from 'https://unpkg.com/jsincss-element-query/index.vanilla.js'
jsincss(event => element('div', {minWidth: 500}, `
[--self] {
background: lime;
}
`))
</script> |
@tomhodgins Hi,
I'm sorry, but I don't understand why you keep saying that adding an option to a script would break anything. I'm not asking to change the default behavior, but any script can look on initialization for some optional variables that would change the behavior of the script. So, instead of scanning everything, on initialization, the script could scan instead only the given files. If those optional variables wouldn't be found, the script would keep running as before on other sites....
Thanks for the warning! Anyway, thank you for this script, for the time taken to answer my request, and for pointing out your others alternatives (I'll check them), This is appreciated. Regards. |
Where or how would you include something like this? It makes sense for plugins where you would have to do something like |
Just use an optional global variable like EQCSS_options, and if it's defined, read it and use it instead of parsing every Then it would just be up to the user to define their option array before your script is loaded.
|
Also see https://wp-customerarea.com/support/topic/the-pages-load-too-slowly/#post-319287
The text was updated successfully, but these errors were encountered: