8000 Deferring Unicode code point literal expansion · Issue #4085 · sass/sass · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Deferring Unicode code point literal expansion #4085

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
tlhackque opened this issue May 28, 2025 · 1 comment
Closed

Deferring Unicode code point literal expansion #4085

tlhackque opened this issue May 28, 2025 · 1 comment

Comments

@tlhackque
Copy link

Given the following in t.scss (extracted from a migration from plain css to scss):

th::before {
    content: "\0021c6 "; /* left over right arrow */
}

Running saas gives:

 sass --version
1.89.0
sass --no-source-map --no-error-css t.scss
@charset "UTF-8"; (or style compressed provides a BOM)
th::before {
  content: "â"; /* left over right arrow */
}

Note that the content after processing doesn't appear to be "left over right arrow". On a terminal window, it's an 'a' circumflex - or if in UTF-8 mode, a blank square as PuTTy doesn't have a graphic for it); in the browser's development tools, it was the three-byte sequence: ⇆, which indicated that was not interpreted as UTF-8. I have a utf-8 locale.

So there are two issues:

  • A terminal emulator or editor may not have the ability to display all of UTF-8. (Does anything?)
  • http servers need to serve UTF-8 instead of basic ASCII (previously the browser expanded the literal)

Apache httpd doesn't use the BOM, but can be configured to force Content-Type text/css;charset=utf-8 - which wasn't obvious when transitioning from css to .scss as there are only a few non-ASCII characters used.

Expanding the literals does save a few bytes. But it makes debugging more difficult, since the compiled result doesn't match the input - even if the webserver is persuaded to send the charset tag. (e.g. search for \0021c6 in your editor, or grep...)

Request: It would be helpful if there was a way to tell saas not to expand Unicode literals and simply pass them on to the output for the browser (or whatever) to expand. If there is, I couldn't find it.
@nex3
Copy link
Contributor
nex3 commented May 29, 2025 •
edited
Loading

Duplicate of sass/dart-sass#568.

Note that Sass is emitting unambiguously correct output here—the presence of @charset "UTF-8" or a byte-order mark forces the CSS parser to interpret the document as UTF-8 regardless of any headers (per spec), and as far as I've ever been able to determine all modern browsers implement this correctly. If your web server is stripping a BOM from the document before serving, that seems like an issue with that server.

@nex3 nex3 closed this as completed May 29, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@nex3 @tlhackque
0