This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 26256 - API: TextEncoder encode()'s 'stream' option appears useless
Summary: API: TextEncoder encode()'s 'stream' option appears useless
Status: RESOLVED FIXED
Alias: None
Product: WHATWG
Classification: Unclassified
Component: Encoding (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 normal
Target Milestone: Unsorted
Assignee: Anne
QA Contact: sideshowbarker+encodingspec
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-07-02 22:21 UTC by Joshua Bell
Modified: 2014-07-11 09:08 UTC (History)
4 users (show)

See Also:

Attachments

Description Joshua Bell 2014-07-02 22:21:51 UTC 
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?
Comment 1 Anne 2014-07-03 05:39:09 UTC 
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?
Comment 2 Joshua Bell 2014-07-07 16:45:33 UTC 
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.)