Open josho opened 1 year ago
It appears that inline-css@3
(uses cheerio@0.22.x under the hood) works with this just fine. Didn't have time to dig into it, would be nice to use latest version... But maybe this workaround will save someones time
htmlparser2 doesn't make difference btw
Using this in my workflow for generating emails. Works wonderfully except when there's template code that conditionally renders DOM. My hunch is cheerio trips up because the template code confuses the DOM generation, and inline-css returns back the cheerio HTML. This may be something for cheerio, but IMO it's a crucial feature.
Example excerpt being run through inline-css. The templating language here is Liquid and has been added to the compile options as
codeBlocks: { LIQ: { start: '{%', end: '%}' }}
, along with EJS & HBS.The resulting code is:
You can tell by the rearrangement of that Liquid
if
to before the table that it's trying to make syntactically valid HTML out of the control flow around the TR.Potentially, a flag to use htmlparser2 in inline-css' cheerio call may have a more "relaxed" approach and work. Haven't tested it manually. Otherwise, some ability to preserve the
style
to each DOM node while rejecting the generated HTML may work.Appreciate the consideration!