-
Notifications
You must be signed in to change notification settings - Fork 351
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.
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
Add ASCII output support #568
Comments
This is something I could see adding as a command-line flag ( |
@nex3 will this command-line flag be ready when Ruby sass is deprecated? |
Ruby Sass has been deprecated for almost a year now. And no, there's no plan to tie this issue to its release cycle. It's marked as "help wanted", which means it's not a priority for the Sass team, but if an external user wanted to contribute a fix we'd help them land it. |
This comment has been minimized.
This comment has been minimized.
// @source - [@Stephn-R](https://github.com/sass/sass/issues/1395#issuecomment-57483844)
// @description converts 1 or more characters into a unicode
// @markup {scss}
// unicode("e655"); // "\e655"
@function unicode($str){
@return unquote("\"")+unquote(str-insert($str, "\\", 1))+unquote("\"")
} |
So, I'm trying to get a zero-width unicode character to work with SASS. It won't appear without a hex editor because of SASS reinterpreting that. On normal CSS, it's: div::before {
content: "\200B";
} But SASS will rewrite it as: div::before {
content: "";
} It's a little frustrating trying to debug with an invisible character since SASS wants to rewrite it. A flag would unfortunately be global to everything when it's somewhat of an edge case where you want raw/literal characters to be outputted as a string. I just have these few instances where it's better to not convert to Unicode. I can imagine there's a lot of other characters, both printable and non-printable, that would greatly benefit from not being rewritten as Unicode, such as: |
Finding this thread today because of an issue similar to @clshortfuse above. I learn that Dart Sass is converting my authored:
to:
…where the spaces written do seem to be no breaking spaces, but they are prone to rendering in the browser as:
No such problem with Libsass, but then Libsass fails at some other stuff. |
Here’s another example that erratically fails due to to the following authored Sass:
…ending up as:
See also this Twitter thread. |
@watershed As mentioned earlier in this thread, Sass emits a |
@nex3 -- I have not touched any settings of Angular CLI that (to my knowledge) would affect the inclusion or omission of |
@cbush06 Are you seeing a case where your CSS is being served with |
@nex3 -- After reading your posts earlier, I went and checked. What I discovered is the CSS generated for each angular component do have the |
I think the assumption that all CSS output by dart-sass will be loaded directly by a browser is not a given. For example, I was running into this problem because my compiled CSS files are loaded by GWT, which doesn't know about the
I think the newer versions of GWT that use GSS might not have this problem, but I can't move to that easily. Regardless of my specific situation, my point is that Sass output is used in many kinds of toolchains that aren't the browser. |
Sass targets the CSS specification. We'll make exceptions for browser behavior that's contrary to the spec only because browsers are the overwhelming majority of CSS consumers. Any other tool should follow the specification when consuming CSS, and if it doesn't it's pretty clearly a bug in that tool and not in Sass. |
@nex3 ,
Hence, when I followed what @jpcamara mentioned in the comment above, I have modified the fa-content and removed the slash ( \ ) symbol on the variables and the resulting output in the css is |
Would like to add to this discussion:
result of compilation: However, randomly the browser will not accept the encoding and will display the strange characters. I've added @charset "utf-8" to my SCSS, and to my index.html. It seems to happen maybe 1 in 50 reloads. The escaping function mentioned above seems to fix it but it seems hacky. |
Emphasis mine. Something in your stack is removing the @kdagnan I'll ask you the same thing I've asked everyone else in this thread: provide a working reproduction of this bug, including the specific browser version in which you're seeing the error. |
For webpack it can be fixed with css-unicode-loader |
@Yegorich555 , thanks for the suggestion. If not, any alternative? |
@jerryephicacy yes, I'm. |
@Yegorich555 , thanks so much for the idea. It works well! @nex3 , I have solved this with the css-unicode-loader package using webpack. |
Just to increase crosslink density... I suspect based on searching this has to do with Chrome(Chromium) caching and not having an explicit charset or BOM. Do anyone see this issue on other browsers? References:
In all cases, the suggestion seems to be to add the explicit encoding back, either with charset directive, response header or BOM. |
Hello @nex3 ! sorry for bringing up such an old thread. i just wanted to confirm: the and if not, |
This issue is open, which indicates that it is not supported but we would like to do it. |
I can confirm that this is still happening, and icons will intermittently render as
|
@nlozovan Does the CSS file you're serving to Chrome retain the |
Yes, it's stripped out for some reason. I ended up forcefully adding a charset declaration after the build. For now, I can't reproduce the error anymore, fonts are rendered correctly. I have a theory that, while Chrome is loading the CSS file from the cache, it will (sometimes) apply a wrong encoding. Yeah, it seems the planets aligned here in a wrong way somehow ;) |
If the |
This is to allow testing of the desired behavior, and it's a possible cause of an issue being discussed in Sass: sass/dart-sass#568 There are two call sites for CSSParserContext::Charset(), one for the regular parsing path, and one for parsing registered property values. Rather than touching both, just throw away the charset override when the feature is enabled. Bug: 1485525 Change-Id: I3da69b4156d6a84bcc8e0517c954a79b522a9ec9 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4846986 Commit-Queue: Philip Jägenstedt <foolip@chromium.org> Reviewed-by: Rune Lillesveen <futhark@chromium.org> Cr-Commit-Position: refs/heads/main@{#1200109}
I have landed a change in Chrome to make URL parsing in CSS spec compliant, by ignoring the encoding/charset of the stylesheet. This change is available in Chrome Canary 119.0.6025.0 and later and can be enabled by passing @nlozovan would you be able to test with Chrome Canary with this command line argument to see if it has an effect on the problem you're experiencing? |
@foolip here are some tests that I've made. Scenario: a CSS file will have
I've used Canary |
@nlozovan thank you for testing! It sounds like you get the error when opening Chrome from the command line both with and without |
@foolip Yes, I was making sure the session is over, the cache is enabled in both cases. Tested now one more time and I have the same results. The terminal is not throwing any errors, it's opening a brand-new session. That is really interesting. |
@nlozovan thanks for double check that. I also don't understand why you'd see a difference between starting Chrome Canary by clicking an icon and from the command line. To help me understand if the change I made behind a flag affects your case, can you share the relevant part of the stylesheet? I'm looking for non-ASCII characteres in URLs, which is what my change should affect. |
In case anyone else is running into this issue with Gulp, I've created a gulp plugin based on the webpack version. Hope that helps. |
These implementations are limited to only patch css
See: https://www.w3.org/International/questions/qa-escapes#cssescapes In general, I recommend not to copy paste code without actually understanding what it is doing. |
@ntkme Thank you 🙏🏼 taking the time to point out the issue in the code and providing an example where it fails. I'll incorporate your feedback into the next version of my plugin. |
If you don't really care about generating compressed output, you can probably just do: css.replace(/[^\0-\x7f]/gu, (match) => `\\${match.codePointAt(0).toString(16)} `)
// This would always add the space character to escape sequence, even when it's optional. If you really care about the output size and want to generate the smallest output possible: css.replace(/[^\0-\x7f][0-9a-fA-F \t\r\n\f]?/gu, (match) => {
const characters = [...match];
const codePoint = characters[0].codePointAt(0);
const escaped = `\\${codePoint.toString(16)}`;
return characters.length > 1
? codePoint > 0xfffff
? `${escaped}${characters[1]}` // escaped character is 6 letters in hex, space is not required
: `${escaped} ${characters[1]}` // otherwise add a space
: escaped; // next letter is safe and will not be parsed as escape sequence
}) |
I've been working on a product using libsass/sassc and have migrated it to Dart Sass. Presently, this product doesn't support UTF-8 characters in stylesheets.
It looks like Dart Sass only supports outputting as UTF-8, with dart-lang/sdk#11744 being the blocker given in the README for why there's no support for more encodings (UTF-16, etc). Dart does however appear to have an AsciiEncoder.
For the time being, we've added an extra step to CSS escape non-ASCII characters in generated stylesheets. (On a related note, we also remove the
@charset 'UTF-8';
atrule, both because it would be technically incorrect for an ASCII-encoded stylesheet, and because of #567.)This isn't trivial because of sourcemaps, so we're doing this step with a PostCSS plugin.
Would adding ASCII-encoded output support be in scope of Dart Sass? I'd imagine when Dart adds other encoders, having this ready would let other encodings be sibling output options alongside UTF-8 and ASCII.
The text was updated successfully, but these errors were encountered: