26256 2014-07-02 22:21:51 +0000 API: TextEncoder encode()'s 'stream' option appears useless 2014-07-11 09:08:26 +0000 1 1 1 Unclassified WHATWG Encoding unspecified PC Linux RESOLVED FIXED P2 normal Unsorted 1 jsbell annevk hsivonen jshin mike www-international sideshowbarker+encodingspec oldest_to_newest 108664 0 jsbell 2014-07-02 22:21:51 +0000 Given that: (a) the input to encode() is defined as a ScalarValueString (i.e. no incomplete surrogate pairs), and (b) encode() only supports UTF-8/UTF-16, which do not maintain any encoder state across input tokens ...then it does not appear that the 'stream' option has any meaningful behavior for encode(). Am I missing something? 108673 1 annevk 2014-07-03 05:39:09 +0000 I was thinking http://encoding.spec.whatwg.org/#big5 but it seems only the decoder can emit two code points. I think you might be correct, yes. I guess if we drop it there's no real harm, right? 108760 2 jsbell 2014-07-07 16:45:33 +0000 CC: henri, jshin Unless someone sees how we can write a test for it, we should probably drop it. (As background: this made sense when we had stateful encodings - i.e. non-UTF encodings, or when the input was not a ScalarValueString and UTF-16 code units could be split across DOMStrings.) 108854 3 annevk 2014-07-11 09:08:26 +0000 https://github.com/whatwg/encoding/commit/f3af63ae02898a3ecb85b6c300a8b8b06acfc30c