Start is not Left! about proposal-string-left-right-trim

[ljharb]

This has already been decided. trimLeft and trimRight are in Annex B for legacy reasons, and trimStart and trimEnd are the proper names. The same logic applied to padStart and padEnd.

The start of the string is index 0, and the end is index length - 1. "Left" and "right" are problematic because they refer to display, and JS-the-language does not concern itself with display - for example, Unicode Byte Order Markers are not treated specially.

[hax]

@ljharb I just realize that my problem is I never know trimLeft/trimRight already implemented in all browsers. My fault, thank you.

[hax]

I'm curious that why padLeft/padRight/contains not in Annex B if 'trimLeft/trimRight` will.

[ljharb]

@hax there is no padLeft, or padRight, or contains - those things simply don't exist and never have (although they all almost did). There is padStart, padEnd, and includes.

[hax]

@ljharb I remember padLeft/padRight/contains are names in the old draft and many polyfill old versions use these names. Maybe padLeft/padRight never exist in engines, but at least contains existed in FF 17~39, Chrome 30~39 (under flag), Node 0.12.x (with --harmony), and I happened meet a bug in a Node.js project related to it.

[ljharb]

Annex B is only for legacy compat; something that never existed without a flag never needs to exist without one.

People using polyfills of nonstandard features are taking a risk, and they need to be responsible to update them when the standard changes - otherwise they're just mutating builtins, which is a horrific practice for the web.

[hax]

@ljharb But string.prototype.contains existed in FF 17~39 without flag.

[ljharb]

Sure. But to be a web compat issue, it had to exist in the majority of browsers at least. Existing in only one browser doesn't matter at all, as any code that relied on it was already broken for the rest.