tc39 / proposal-string-left-right-trim

A proposal to the ECMAScript standard for including left and right trim of whitespace to strings

String.prototype.trimStart / String.prototype.trimEnd

ECMAScript proposal, specs, tests, and reference implementation for String.prototype.trimStart/trimEnd (plus trimLeft/trimRight).

Stage 4

This proposal is complete and already merged into ECMA262 specification. See the specification text here.

Rationale

ES5 standardized String.prototype.trim. All major engines have also implemented corresponding trimLeft and trimRight functions - without any standard specification. For consistency with padStart/padEnd we propose trimStart and trimEnd and trimLeft/trimRight as aliases required for web compatibility.

Specification

You can view the spec in ecmarkup or rendered as HTML.

Naming / Aliasing

For consistency with padStart/padEnd the standard functions will be trimStart and trimEnd, however for web compatilibity trimLeft will alias trimStart and trimRight will alias trimEnd. This means String.prototype.trimRight.name will change from "trimRight" to "trimEnd" in most engines. The spec author does not expect this to cause any breakage.

Test262 Coverage

PR open

Status of This Proposal

This initial proposal was drafted by @sebmarkbage and the updated spec was drafted by @evilpie with input from @ljharb.

This proposal is currently at stage 4 of the process.

Designated TC39 reviewers: Jordan Harband + Daniel Ehrenberg

Implementations

• V8, in Chrome 66+
• SpiderMonkey, in Firefox 61+
• JSC, in Safari 12+
• ChakraCore

proposal-string-left-right-trim's Issues

Start is not Left!

We should decide which is more important: compatibility or good design?

Left is not allways Start in multilingual text. This is my proposal:

	LTR	RTL
trimStart ==	trimLeft	trimRight
trimEnd ==	trimRigth	trimLeft

But understand it's not that easy to decide when dealing with bidirectional strings.

Reviews for stage 3 sign off

I reviewed the spec text and this is good for Stage 3.

I believe @spectranaut can confirm the same.

Please transfer repository to tc39

See tc39/proposals#44

Add trimStart/trimEnd

Per discussion around tc39/proposal-string-pad-start-end@35f1ef6 the committee decided it would be ideal to also provide trimStart and trimEnd - not necessarily in Annex B - so that the language's official naming conventions for strings trended towards start/end instead of left/right.

[Q] `String#{trimStart, trimEnd}` and `String#{trimLeft, trimRigth}` equality

Is it the same functions? If the same - which names they should have?

String.prototype.trimStart === String.prototype.trimLeft; // ???
String.prototype.trimStart.name; // ???
String.prototype.trimLeft.name; // ???

Advance to stage 4

Criteria taken from the TC39 process document minus those from previous stages:

• Test262 acceptance tests have been written for mainline usage scenarios, and merged

PR by @spectranaut: tc39/test262#1246

• Two compatible implementations which pass the acceptance tests

https://github.com/tc39/proposal-string-left-right-trim#implementations

• Significant in-the-field experience with shipping implementations, such as that provided by two independent VMs

https://github.com/tc39/proposal-string-left-right-trim#implementations

• A pull request has been sent to https://github.com/tc39/ecma262 with the integrated spec text

PR by @evilpie: tc39/ecma262#1275

• The ECMAScript editor has signed off on the pull request

Have we considered a paramater to the trimX() functions similar to C# usage.

In C# you can very handily use .TrimStart("?"), this will remove specifically a "?" if it is at the beginning. This can be incredibly useful for very common cases where you want to remove starting string characters such as dealing with query urls on the web.
JS eg:

var query = ...;
if(query.indexOf("?") === -1)
    query = query.slice(1);

C# eg:
var query = (...).TrimStart("?");

Not sure if this has already been considered, just been using it a lot lately in C# and thought to check if it could be used in JS.

Todo List

Just some stuff I think we should do before the next meeting

• Update readme
• Update markdown version to the new spec
• Add gh-pages with a rendered version of this proposal
• Close #3 and #4, they seem to be resolved with my new proposal
• Get this scheduled for the next meeting
• Rename this proposal for start/end?
• Add test262 test
• Open a pull request to ecma262

@ljharb Can you think of anything else?