Is there a way to prevent optimizers removing the "min-width" HTML tag?

[enventa]

When using css-element-queries on a WordPress installation that uses an optimizer plugin (Autoptimize), the custom "min_width" attribute added to the targeted DOM element gets removed.

This is also true for other optimizers. I know the feature that is causing the attribute to be removed is one called "Inline and Defer CSS?".

I just wanted to confirm whether that attribute is set via Javascript. If so, which file is responsible for that?

To avoid issues with that kind of plugins/functionalities, would be an option for you to consider to use valid HTML attributes, like "data-"? Would that make sense?

Thanks!
Vitolo

[marcj]

You mean your CSS rules like .widget-name[min-width~="400px"] h2 { are rewritten/removed?
And this is not the case when you use rules like that .widget-name[data-min-width~="400px"] h2 {?

The attributes min-width are set via Javascript https://github.com/marcj/css-element-queries/blob/master/src/ElementQueries.js#L153-L161

[fabasoft-michael-stedry]

I have also encountered a similar situation where the attributes like min-width are not valid HTML and it would be nice to to use the data- attributes. To this end I have created a PR #273 with this implemented and would like to have it included in the library, if correctly implemented.

[enventa]

Sorry @marcj I didn't see you answer!

the thing is that plugins/tools like Autoptimize and WP Rocket provide an option to "Optimize CSS Delivery" based on Google PageSpeed Insights (WP Rocket's explanation here). Not sure why nor when, that option either prevents your JS to add the min-width="400px" or removes it after being added. It does NOT remove any CSS rule. It does remove the HTML attribute added by your JS.

Maybe, an option to avoid this issue would be, like @fabasoft-michael-stedry suggests, to use a data attribute. However, now I think that no matter what kind of HTML attribute/tag you use, if it is added by your JS it wouldn't work either.

I don't know how your plugin works internally, but is kind of counterintuitive it to be a "CSS option" the one causing issues if the min-width attribute is added via JS.

[fabasoft-michael-stedry]

The attributes such as min-width are simply not valid according to the HTML specification. Custom attributes should be prefixed with data- as stated in the HTML spec. That is most probably what the problem is with all the tools complaining about the attributes or directly removing them. Also if your site or web app needs to be standards compliant, these issues become major/critical for you.

Please look at my PR and check if it is implemented according to your coding guidelines and whether I have not misunderstood your intent somewhere. I have just updated the tests and documentation so that you can more easilly merge that.

[enventa]

Any update about this, @marcj?

Not sure now if the "min-width" HTML tag is removed always we use a CDN, but I'm positive that when we use one, we need to exclude CSS files from being served by the CDN. So this issue could very well be related with #284.

[marcj]

CDN is a critical detail here. Setting non-standardized attributes is no problem in all browsers. If the CSS is untouched and the rules are still there, then it means the JS can not read the CSS rules due whatever reasons. For CDN it's mostly because of incorrectly configured CORS headers.

[enventa]

@marcj I'm closing this ticket as "min-width" tag is actually not removed. As you pointed out, the actual issue is that CSS files are being served by a CDN. Due to cross-origin security measures held by browsers, your JS is not allowed to read those CSS files -despite JS and CSS files being served from the same CDN/domain, HTML/browser lives in website domain, so there is a domain mismatch. So "min-width" is never set.

As stated in my answer here, I've found two workarounds:

1. Exclude CSS files from being served by the CDN
2. Include element-queries related-CSS into a <style></style> block in your tag.