Skip to content
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

Document.defaultCharset #58

Closed
foolip opened this Issue Jul 23, 2015 · 9 comments

Comments

3 participants
@foolip
Copy link
Member

foolip commented Jul 23, 2015

IE, Blink and WebKit all have Document.defaultCharset and the usage in Chrome isn't low enough that it can be trivially removed:
https://www.chromestatus.com/metrics/feature/timeline/popularity/428

Can we specify this? The concept itself is already referenced as "an implementation-defined or user-specified default character encoding" in HTML's determining the character encoding, and assuming the side effects of that are observable, this wouldn't actually expose new information about users.

This should probably be blocked on Document.charset.

@foolip

This comment has been minimized.

Copy link
Member Author

foolip commented Jul 23, 2015

Note that much of the usage is probably in contexts will fallbacks where removal would do no harm at all, but this is a case where it's very hard to measure.

@annevk

This comment has been minimized.

Copy link
Member

annevk commented Oct 5, 2015

I'm somewhat hesitant to add this as @hsivonen has been working on a way to get rid of this entirely. By defaulting based on the TLD of the website and such. A default encoding that depends on the user's locale is rather terrible.

@foolip

This comment has been minimized.

Copy link
Member Author

foolip commented Oct 5, 2015

If the way the default encoding is determined changes, then presumably that should simply be reflected in this attribute.

@foolip

This comment has been minimized.

Copy link
Member Author

foolip commented Dec 7, 2015

@hsivonen, any thoughts on this? Do you think it would be harmful to expose the default encoding, merely useless, or something else?

@hsivonen

This comment has been minimized.

Copy link
Member

hsivonen commented Dec 7, 2015

I don't see legitimate use case for this. As a Web author, you should always use UTF-8 and declare that you are using UTF-8. At that point, what's the use case for knowing what the default would have been?

If someone tries to use it for something, what non-harmful uses it could have? I can think of a harmful use case: trying to guess what encoding to use for downloadable text files. (Correct way: Use UTF-8 BOM for downloadable text/plain and use Python, etc. -specific encoding declarations for downloadable scripts with #!.)

So I see this as useless and harmful if used, so I think we shouldn't spec this.

Can you tell if the Blink usage comes from "let's check everything" fingerprinting ad tech (not worth catering to)?

@foolip

This comment has been minimized.

Copy link
Member Author

foolip commented Dec 7, 2015

I don't know of any reason to use this API, my only concern is that it's supported in all engines except Gecko and usage is fairly high. Unfortunately, the use counter system can't answer interesting questions like "is this due to enumeration" or "is this always used with a fallback." I'll do a httparchive search to get some idea about how it's used in the wild.

@foolip

This comment has been minimized.

Copy link
Member Author

foolip commented Dec 8, 2015

I'm now attempting to deprecate and remove this in Blink.

@annevk

This comment has been minimized.

Copy link
Member

annevk commented Aug 16, 2016

It seems that was successful. \o/

@annevk annevk closed this Aug 16, 2016

@foolip

This comment has been minimized.

Copy link
Member Author

foolip commented Aug 16, 2016

Yep, I didn't hear about any fallout from that, sometimes it works out!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.