The relevant spec is actually https://drafts.csswg.org/css-syntax/#determine-the-fallback-encoding which is a bit different from the CSS2.1 version in terms of how it handles BOM and UTF-16.  But in either case, the encoding of the document itself will be used in both situations before the UTF-8 fallback.  So how this testcase works depends on the encoding the browser ends up using for the HTML file.

Ok, I check it and this test case didn't use the default value from the function.
But if I open dev tools it will, because of another bug with loading of CSS in dev tools (I fixing it here https://codereview.chromium.org/2912973002/).

Are you opening the file from an HTTP server or local file? If so, probably the same as issue 550426 (w/o BOM or sniffing, documents loaded are loaded as windows-1252), i.e. working as intended.

Also, try logging document.characterSet after loading the page to see what encoding was used for the document.

I open local file and document.characterSet contains windows-1252. And this is the reason of incorrect encoding.

But when I open dev tools document.characterSet contains <null>. So, for file used default encoding.

I have no access to issue 550426 and can't say anything about it.

Ah, sorry about issue 550426 - should be visible now. (It just had automatic view restrictions applied since a googler filed it.)

Can you clarify what you mean by "when I open dev tools document.characterSet contains <null>" and the bug you're trying to fix in https://codereview.chromium.org/2912973002/ ?

When I open dev tools, a special code to load CSS fired. And this way of loading didn't use HTML file encoding. So CSS encoding stays not
set (<null>) and used default one(windows-1252).
This isn't what I expect.

Can you clarify where this appears in devtools?

When I load the page I see: ●test
Loading the CSS file on its own as UTF-8: content: '●';
In the devtools Source tab I see: content: '●';

(Although the  shows up as a red circle - see attached image)

Thanks for your patience here; I want to make sure we treat the bug accurately.

Deleted: css encoding.png 17.8 KB

	css encoding.png 17.8 KB View Download

Ok, I finally figure out how it can be reproduced.
I attach fixed test files. Need to open test-css-circle.html with a browser.
After that open dev tools and go to Sources > external.css. You will see content: '●';
But in any other place will be ●.
Page refresh fixes it.

Deleted: test-css-circel.html 168 bytes

test-css-circel.html 168 bytes View Download

Deleted: external.css 34 bytes

external.css 34 bytes View Download

Cool, thanks for the update. I see '●test' as the page content with the latest repro, and '●' (but with a red circle for some reason) in Sources > external.css

Aside: the red circle is a devtools representation of control code \x8F in the C1 range which is not remapped to a non-control character by windows-1252. Other C0 and C1 control codes not given special meaning by Chrome are displayed similarly in some devtools UI (e.g. input editor in the console.) Note that the appearance typically switches to an outlined box or the glyph for the replacement character in other contexts (e.g. history lines in the console.)

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot