feat: Add keep_at_rules option

[kamilzych]

Rel #265 (comment)

[codspeed-hq]

CodSpeed Performance Report

Merging #485 will not alter performance

_{Comparing kamilzych:feat/keep-at-rules (fdfd7c8) with master (bd04285)}

Summary

✅ 6 untouched benchmarks

[codecov]

Codecov Report

Attention: Patch coverage is 99.24812% with 1 line in your changes missing coverage. Please review.

Project coverage is 89.05%. Comparing base (d0ee769) to head (fdfd7c8).
Report is 31 commits behind head on master.

Files with missing lines	Patch %	Lines
css-inline/src/html/serializer.rs	97.36%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #485      +/-   ##
==========================================
+ Coverage   88.05%   89.05%   +0.99%     
==========================================
  Files          18       18              
  Lines        1993     2037      +44     
==========================================
+ Hits         1755     1814      +59     
+ Misses        238      223      -15     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Stranger6667]

Great start! Definitely on the right track :) I left a few comments

[Stranger6667]

I am not 100% sure about this one, even though it is a sound approach.

The first thought that I have is that the least surprising thing would be to keep @ rules in their original places, instead of pushing everything into a single node. This won't work for external stylesheets, so we need to store them somewhere anyway.

On the other hand, this approach is better for performance, and probably it would not be super surprising for the user anyway if we put everything under one <style> tag.

So, in the end, I am leaning towards this approach.

A few other notes:

1. We can reduce the performance hit of checking each node name by having two versions of serialize - the first one will work as before this PR. The new one will check for head and once it is found, it will switch to the other version of serialize that won't check the tag name. At the top level we check if at_rules are present and then call one of these two versions - I think it should minimize the impact as head is usually in the very beginning of the nodes vector.
2. Are there cases when head is not present? Maybe in HTML fragments? see inline_fragment

[Stranger6667]

btw, if the user chose to keep style tags - I think we can only extract @ rule from link, as the old style tags will be around anyway

[kamilzych]

That's something I had no time to look closer into yet

[Stranger6667]

Given the current benchmark results, the performance hit is negligible, so we can skip this. For fragments, likely we can't really do it, as there is no regular HTML structure generally. Maybe we can return an error when the user sets an option to keep at rules, but uses inline_fragment?

[Stranger6667]

Hi @kamilzych

Let me know if you need any assistance or if you plan to continue working on this PR. I'd be happy to help or take over in case if you don't plan to continue this PR.

[kamilzych]

@Stranger6667 Hi! Apologies for lack of activity, I simply had no time, life happened ¯\_(ツ)_/¯

I've just pushed a commit which addresses some of your comments. I'd love to finish the whole PR but I'm not sure when I have enough time to move this forward.
That said, if you have time to take it over, I'm absolutely fine with it. If you don't, I'll do my best to finish it ASAP and in such case I'd appreciate a review of the mentioned commit and perhaps some guidance about the next steps 🙏

[Stranger6667]

Awesome! Thank you so much! :) I’ll be on vacation till the end of next week, but I’ll review the changes in any event :) Let’s see how it goes

[Stranger6667]

Amazing to see that we already have a working version! There are a few minor things left; there is no time pressure, so I'm just noting what is left to do, and maybe I'll push some changes to it in the next few evenings:

• Changelog entries for the main crate + bindings
• Update all readmes with the new option + usage example
• JS bindings
• Java bindings
• Python bindings
• C bindings
• Ruby bindings
• Error for inline_fragment + keep_at_rules?

[Stranger6667]

As for the next steps, I think most of them are about adding new config option to bindings, so they compile. This flag is the same as others in terms of behavior, so it should be more or less straightforward.

about the error, we can add an extra check to inline_fragment

[Stranger6667]

There is a small place above where this flag should be added too. The handle_boolean_flag function