Keep `@media` query CSS for responsive

[lepture]

For example:

<style>
h1 {
  font-size: 14px;
}

@media only screen and (max-width: 620px) {
  h1 {
    font-size: 16px;
  }
}
</style>
<h1>Hello</h1>

Should be converted to:

<style>
@media only screen and (max-width: 620px) {
  h1 {
    font-size: 16px;
  }
}
</style>
<h1 style="font-size:14px">Hello</h1>

The media query is used for responsive emails.

[Stranger6667]

Would keeping style tags be enough? Or its required to remove non-@media entries from styles?

[lepture]

@Stranger6667 Keeping the style tag would work. But it could be better to remove the non-@media styles. Just like the example I provided above. If the style is too large and contains many unused code, removing them could make the email size smaller.

If keeping the @media query is hard to implement. I suggest using a data-css-inline="keep" on <style> element:

<style>
h1 {
  font-size: 14px;
}
</style>

<style data-css-inline="keep">
@media only screen and (max-width: 620px) {
  h1 {
    font-size: 16px;
  }
}
</style>
<h1>Hello</h1>

[Stranger6667]

Mostly notes for myself.

Filtering on the @-rules should not be complicated, so the final API might be a config option that will enable keeping such rules (maybe just any @-rules?) + we'll need to validate the config, e.g. to prevent the simultaneous use of keep_style_tags=false and this new option.

The implementation itself is a new parser that will drop all regular declarations (in cssparser::DeclarationParser) and just keep all declared ones (in cssparser::AtRuleParser) - this could be used at the very end, during the serialization phase. So, if the new config option is enabled, then take the style tag content, parse it with this new parser, and write the filtered styles to the output buffer.

[Stranger6667]

FYI @lepture

I've implemented data-css-inline="keep" and it will be available in 0.13.0. I'd keep this issue open, as it would be clearly beneficial to implement the CSS filtering

[kamilzych]

@Stranger6667 Hey 👋 Is this something you’re planning to work on anytime soon? I’d be happy to help with the implementation, maybe even create a PR draft, although I’m not exactly fluent in Rust. I’m currently using Juice in one of my projects, but I’ve run into some performance issues. Your library is significantly faster, and I’d love to switch over, but I’m just missing this one feature

[Stranger6667]

@kamilzych Hey :) Thank you for pinging!

I don't have plans to work on it right now, but I would be open to reviewing a PR.

The core idea would be to create a "filtering" CSS parser that will parse "style" content and will push all @media blocks to some buffer. Here I see two options:

1. Create separate buffers early and store "style" NodeId -> buffer mappings. When serialization happens, these buffers can be used to populate "style" content in the output HTML. The downside is that it will require a few more allocations (1 per style tag + hashmap)
2. Re-parse style content at serialization time and write filtered content directly to the output HTML.

If CSS is complex enough, then it would be better to have option 1 to avoid re-parsing (allocations will be much cheaper). For small and simple CSS blocks, it could be cheaper to re-parse. My inclination is to go with option 1 as I believe the majority of use cases will fall into that category.

For that, I think it will be better to create another parser struct with an output buffer and choose this parser instead of the default one if the corresponding config option is passed. Then this parser will have special handling for @media rules and will push them to a buffer.

Let me know if you'd like me to elaborate :)

[kamilzych]

@Stranger6667 Thanks so much for the quick reply and guidance! I’ll take a closer look at the codebase and see if I can figure out where I should even start 🌸

[Stranger6667]

I think a good place to start would be here.

The new parser would have buffer: String inside (and that vec of declarations too), and then most of the traits would be the same as those of the current parser, except for AtRuleParser. This one would need to check if the at-rule is @media and, if so, then push the whole block (prelude, etc) to self.buffer. See the docs for more methods. Generally, you can also use the existing exhaust function to skip to the end of the block, as we need to keep the content as is

[kamilzych]

@Stranger6667 Hey again! To be honest, my Rust knowledge is worse than I expected 😅 That said, I created a PR draft. Not even close to be finished (I left some TODOs for myself there) but I'd appreciate if you could skim through it and drop a line about the approach in my attempt.

[Stranger6667]

@kamilzych

Awesome! Thank you :) I am going to take a look at it soon!

[Stranger6667]

Implemented in #485

I am going to make a new release in the next couple of days