Intent to Remove: Document.charset setter

66 views
Skip to first unread message

Philip Jägenstedt

unread,
May 18, 2015, 6:35:57 PM5/18/15
to blink-dev

Primary eng (and PM) emails

phi...@opera.com


Link to “Intent to Deprecate” thread

https://groups.google.com/a/chromium.org/d/msg/blink-dev/1bykHAUpEA0/1Rl1AZuaiS4J


The deprecation landed in M41:

https://codereview.chromium.org/768313004


Summary

Make Document.charset readonly. Currently, the setter influences the encoding used for form submissions and the fallback encoding for external scripts and stylesheets loaded after that point.


Motivation

Document.characterSet is the standard attribute, but everyone except Gecko also supports charset, which unlike characterSet can be set.


Document.charset (getter and setter) has ~3.5% usage so I filed a bug to standardize it instead of spending time trying to remove it:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27436


Anne's last comment is "I want to wait with adding .charset until at least the setter has disappeared. Removing that seems like a win for everyone. Then we can evaluate again."


Usage information from UseCounter

https://www.chromestatus.com/metrics/feature/timeline/popularity/427


Usage hasn't changed much since deprecation it's still ~0.01%.


Entry on chromestatus.com

None, just https://crbug.com/438392


Compatibility Risk

Forms may be posted and scripts/stylesheets loaded with the wrong encoding. (They would in Firefox as well, unless it's a non-Gecko code path.)


Judging by a quick grep of the 20150101 httparchive data, the most common way this is used is to set an encoding immediately before form submission. Some are conditional on IE sniffing and based on a Stack Overflow question I suspect that working around an old IE bug explains some of the usage. For per-form control over encoding, the accept-charset attribute is a suitable replacement.

Chris Harrelson

unread,
May 18, 2015, 7:43:14 PM5/18/15
to Philip Jägenstedt, blink-dev
LGTM1

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Dimitri Glazkov

unread,
May 18, 2015, 9:05:00 PM5/18/15
to Chris Harrelson, Philip Jägenstedt, blink-dev
LGTM2!

PhistucK

unread,
May 19, 2015, 2:37:24 AM5/19/15
to Philip Jägenstedt, blink-dev

​​
On Tue, May 19, 2015 at 1:35 AM, Philip Jägenstedt <phi...@opera.com> wrote:
​​

For per-form control over encoding, the accept-charset attribute is a suitable replacement.

​Internet Explorer 8 and below (and maybe later, I forget) does not really support accept-charset. It does not work as you expect. If it matters.

​

​Entry on chromestatus.com
None, just https://crbug.com/438392​

Please, create an entry in order to make sure this is announced in a beta blog post. 


☆PhistucK

TAMURA, Kent

unread,
May 19, 2015, 8:45:07 AM5/19/15
to Dimitri Glazkov, Chris Harrelson, Philip Jägenstedt, blink-dev
LGTM3.  Let's remove it and see if the removal breaks web sites.

--
TAMURA Kent
Software Engineer, Google


Paul Kinlan

unread,
May 19, 2015, 9:01:37 AM5/19/15
to TAMURA, Kent, Dimitri Glazkov, Chris Harrelson, Philip Jägenstedt, blink-dev
Can we also file an entry on Chromestatus.com to help us increase the visilbity of this change and to have a central place we can point people that is not just this list.

Thanks in advance.

Philip Jägenstedt

unread,
May 19, 2015, 2:23:35 PM5/19/15
to Paul Kinlan, TAMURA, Kent, Dimitri Glazkov, Chris Harrelson, blink-dev

Philip Jägenstedt

unread,
Sep 22, 2015, 4:02:38 AM9/22/15
to Paul Kinlan, TAMURA, Kent, Dimitri Glazkov, Chris Harrelson, blink-dev
This all worked out well, and Document.charset is now in the spec:
https://dom.spec.whatwg.org/#interface-document
Reply all
Reply to author
Forward
0 new messages