styled-jsx: CSS `content` property no longer renders encoded characters

Do you want to request a feature or report a bug?

bug

What is the current behavior?

Old behavior now must be done through string-literal instead of standard string.

If the current behavior is a bug, please provide the steps to reproduce and possibly a minimal demo or testcase in the form of a Next.js app, CodeSandbox URL or similar

The following no longer works in NextJS 9.1.1 to render a encoded character:

<style jsx>{`
.whatever-class:after { content: "\\0025B6"; };
</style>

We now have to do:

.whatever-class:after { content: ${`"\\0025B6"`}; }

What is the expected behavior?

Standard way of rendering content should still work.

Environment (include versions)

OS: macOS Catalina
Browser: Chrome 77
styled-jsx (version): NextJS 9.1 bundled (styled-jsx@3.2.2)

Did this work in previous versions?

Yes

About this issue

Original URL
State: open
Created 5 years ago
Reactions: 1
Comments: 17 (1 by maintainers)

Commits related to this issue

修复 #589 css content unicode render error — committed to singleparty/styled-jsx by singleparty 4 years ago

Most upvoted comments

@giuseppeg https://github.com/zeit/styled-jsx/pull/577 was a fix for a component like this one:

const InlineCode = ({ color, children }) => (
  <code>
    {children}
    <style jsx>
      {`
        code {
          color: ${color ? color : '#bd10e0'};
        }
        code::before {
          content: '\`';
        }
        code::after {
          content: '\`';
        }
      `}
    </style>
  </code>
)

That component was broken because of this line:

content: '\`';

lfades on Nov 16, 2019

I’m experiencing the same issues with encoded chars in pseudo content, as with the OP i’m using Next (all the way up to 9.4.5-canary.10, using styled-jsx 3.3.0), and the only way I can get consistent behaviour across SSR/CSR/SSG is the OP’s string-literal solution of

.whatever-class:after { content: ${`"\ue815"`}; }

have tried all the other solutions and no matter how many slashes i add, there are bugs in at least one rendering approach.

Things I’ve tried are:

content: '\e815' - original approach, works for CSR but SSR/SSG (using flush()) the slash gets removed. Also if the char code starts \f the slash remains but then is treated as a line break in the returned string (in flush() when the string is extracted from the array) content: '\ue815' - approach suggested on here, fixes SSR but breaks CSR content: '\\e815' - approach suggested on here, fixes SSR but breaks CSR

daveskybet on Jun 24, 2020