Giter Club home page Giter Club logo

Comments (5)

Stranger6667 avatar Stranger6667 commented on September 3, 2024

Thank you for reporting this!

I ran the test you provided (btw, thank you for writing a failing test case!):

failures:

---- do_not_remove_conditional_comments stdout ----
thread 'do_not_remove_conditional_comments' panicked at 'assertion failed: `(left == right)`
  left: `"<html><head></head><!--[if mso]>Hello outlook<![endif]--><!--[if !mso]><!--><body><h1>Hello not outlook</h1><!--<![endif]--></body></html>"`,
 right: `"<html><head></head><!--[if mso]>Hello outlook<![endif]--><!--[if !mso]><!--><h1>Hello not outlook</h1><!--<![endif]--></html>"`', tests/test_inlining.rs:136:5

So, the only difference here is the "body" tag, the conditional tags in the input example are children of the "html" element and are preserved. However, the body start/end tags are unconditionally added to the tree and it mangles the original tree structure. I assume that the html5ever crate (which is used under the hood in kuchiki) considers this case as an invalid tree and add "body" start/end tags to the tree during serialization or during the initial parsing.

I don't remember exactly, but I observed similar behavior in Python's lxml library and it might come from some part of the HTML spec, e.g. in this example there are no "html" or "body" tags, but the parsing result appears to have them anyway, I'll dig some more into this direction, but my current assumption is that this is the default parser behavior, which is probably described somewhere here

Also, if there is a body tag, then the final output stays the same (please, correct me if it is a valid case at all):

<html>
   <head></head>
   <body>
      <!--[if mso]>Hello outlook<![endif]--><!--[if !mso]><!-->
      <h1>Hello not outlook</h1>
      <!--<![endif]-->
   </body>
</html>

Let me know what do you think :) Is it common to have these comments as children of the "html" element? Or is it more likely to have them inside head / body?

from css-inline.

cheapsteak avatar cheapsteak commented on September 3, 2024

oops! yes you're right my test was flawed

I was experimenting with swapping out juice with css-inline-wasm and found quite a few sections in the file i was testing with were being removed, I thought the conditional comments were the culprit but you're right that definitely isn't why

I'll see if I can isolate what is causing the issue then :)

from css-inline.

Stranger6667 avatar Stranger6667 commented on September 3, 2024

I'd be happy to know if css-inline-wasm fits your needs and if we can improve it :)

I'll see if I can isolate what is causing the issue then :)

Let me know if I can help you with that somehow :)

from css-inline.

cheapsteak avatar cheapsteak commented on September 3, 2024

Was pure user error 😅

In part of my attempt to swap out juice with css-inline-wasm, I accidentally removed mjml's default skeleton wrapper (html/head/body stuff)
Since kuchiki (unbeknownst to me at the time) added the necessary html/head/body tags to make the html valid again, I didn't realize that error and mistook this as css-inliner or kuchiki stripping things out
Adding back the default skeleton fixed everything!

Apologies again and thanks as always for your patient guidance 🙇

(also btw it looks like removing the http feature/dependency cuts the wasm file down to 850447 bytes (down from 1491585) which is fairly significant)

from css-inline.

Stranger6667 avatar Stranger6667 commented on September 3, 2024

Thank you for the details! :)

Apologies again and thanks as always for your patient guidance

You are very welcome! :)

(also btw it looks like removing the http feature/dependency cuts the wasm file down to 850447 bytes (down from 1491585) which is fairly significant)

I created #66 to track options for size reduction. I am not sure about the performance cost though, we can continue the discussion there - I am keen to know how much performance those tricks will cost and what we can actually tune more

from css-inline.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.