[esnext] template string的缩进格式规定有问题 about spec

[hax]

我发现“3.3 模板字符串”有提到这点，建议和“2.2.1 缩进”重新组织一下，避免单独读一条产生误解。

[Justineo]

同意，另外 2.2.1 里的这个例子：

// good
function foo() {
    let bar = `Hello
        World`;
    console.log(bar);
}

这个作为 good case 不妥吧？我不能想象一个 Hello World 字符串中间要有换行和一串空格。事实上我觉得这个只有在写（空格不敏感的）源代码的时候才适合用多行的 template string。

[hax]

实际上，“空格不敏感”的源码是很少见的。如果一开始没有觉得空白有关系，后来踩坑就讨厌了。

[errorrik]

coding style或许应该规定尽量避免在template string中包含换行

如果这样肯定最清晰，但是实际应用中应该很难避免，比如稍微复杂的HTML结构。

var htmlStr = `
    <h2>${title}</h2>
    <p>${content}</p>
`;

如果单纯为了锁进好看，可以让模板字符串从第二行开始。这样字符串起始的空行又去不掉。这个\n也有可能会带来麻烦。

var htmlStr = `
    <h2>${title}</h2>
    <p>${content}</p>
`;

所以，我现在暂时也no idea。 @otakustay 你有没啥想法？

[hax]

这里恰恰是个问题：直接使用template string来写html是必须禁止的！！！

因为很容易搞出xss漏洞。（空白的问题倒是其次了。）

如果要用，必须写一个特别的处理函数。

var htmlStr = html`
    <h2>${title}</h2>
    <p>${content}</p>
`

但是即使如此仍然很难保证完全安全（比如写出了有问题的html，或是有人图方便绕过）。

[otakustay]

你要么禁止所有string写html，而不是禁止仅仅template string，但这在我厂现状下不现实就是了

在我看过的大量代码中，js中会换行的字符串多数是带缩进结构的css或html，这两者都是空格不敏感的

或者再广泛些说，会带换行的多数是另一个语言的源码，基本上都是空格不敏感的……

[hax]

@otakustay

然而html并非是空白不敏感的，增加的空白节点往往造成样式问题。
其他场合，比如css的例子，至少造成一个问题就是代码压缩上多了一点点冗余（尽管也没有什么大关系）。

我强调安全因素是因为，自己写普通的 string ，那是一个常量，不会引起安全问题，引起安全问题的是拼接内容不受控的变量。而template string把这件事情变得特别容易。

本来拼接字符串的麻烦，也是一个阻止写出不安全代码的屏障（尽管以不方便来阻止不安全，是狠不靠谱的），现在连这个屏障都没有了。

此外，明明知道拼接html的极大风险，虽然现在没法改变legacy代码，但是至少可以在新的特性的代码规范里禁止。所谓老人老办法，新人新办法。且学习新代码规范（或被工具挡住）正好是一个安全教育的机会。

安全，怎么样强调都不过分。

题外话，在上个月的QConShanghai上，一位黑客的演讲就列出了BAT等互联网一线公司的安全漏洞在这些年的演变过程。SQL注入漏洞逐年下降（除了坑爹的新浪），而XSS漏洞逐年上升（百度似乎尤甚）！

前端工程师真的要赶紧重视起来，不要到时候成为了整个技术栈上最大的漏洞！！！！！！！！！！

代码规范在其中至少必须要起到阻止事态进一步恶化的倾向吧！！！！！

[otakustay]

小到团队的规范时，比如我的团队里，是会强制要求所有HTML走模板引擎的，这种事情在团队里有一个意识足够的人时，是自然而然的（没错我就是在喷那些乱来的团队，虽然3年前的我们也有这样那样直接写HTML的情况存在，但我们成长了）

但这并不等于我们有能力在全厂层面去控制这些，我没有这能力和这授权，@errorik 同样没有，所以我们放弃……

[errorrik]

禁止在template string里写html，甚至禁止string里写html。想想就好像陷入了人民战争的汪洋大海，哈哈

[hax]

我疑问的是：制定一份代码规范为什么要考虑这种授权？代码规范的制定是上限，代码规范的实施是下限。制定代码规范的人难道还要为最终代码的bug负责吗？明显多虑了。

即使考虑现状，也应在代码规范中指出问题，以及未来应该走向的方向。无法强制，至少可以推荐，引起重视。

[Justineo]

@hax 可能不知道，这个规范在公司内部是强制实施的，不符合规范不允许提交。

[errorrik]

xss是个严重的问题，我觉得规范可以强调这一点，否则一大波xss正在袭来。

禁止string里写html，这个限制还是比较重比较挑战习惯的，可以类比于写jquery不让用链式调用？所以我觉得这限制还是不能搞

[hax]

@Justineo 看我写的几点：

1. 禁止 template string 里写 html，并不会影响过去的代码。（除非已经有写这样的ES6+代码，然而反正制定的其他新规则他们也可能通不过，因此并没有什么特殊之处。）
2. 对老代码可以建议（出warning）而不是强制（出error）。

@errorrik 是坏习惯就应该挑战。jQuery的链式调用并不是坏习惯（当然也有一些小坑），因此这类比不成立。

再强调一次，安全问题是非常严重的问题。

Winter说过阿里的安全部来找他们吐槽XSS太多次，因此他们下定决心要根除拼接html的陋习，甚至因此决定要抛弃jQuery（因为jQuery提供了很多直接转字符串的方法）。

百度应该也有类似的安全部门，让他们去找反对这规范的人好好谈谈心罢。

[otakustay]

单纯禁止在template string里写HTML没有任何意义，我厂部分同学绕过规范的水平令人叹服，你说template string不行那就换string呗，所以这条写和不写没区别，那就不要放到规范里面来

@errorrik 把“[建议]不要使用JavaScript字符串拼接（包括template string）组装HTML”加到我们的章节里面吧？

[skyline0705]

但是碰到说string不行，template string不行，那我继续模板引擎拼装，并且实用的引擎并没有对可能造成xss的情形进行处理，其实照样能绕过去…囧rz我倒是觉得安全问题代码规范只能解决很少一部分，更多的还是需要各种安全检查…

当然"“[建议]不要使用JavaScript字符串拼接（包括template string）组装HTML"这条我是强烈同意的

[hax]

@otakustay “有人会绕过规范”导出“不如不要订这条规范”，我觉得这个逻辑是有问题的。
我们当然希望所有规范制定的约束是不会被break的，但是这毕竟是两个层次的问题。

写和不写一定是有区别的，它至少代表我们对于一个事情的态度。
如果你不写，就根本不存在“违反规范”。因此造成的安全性隐患，也很容易被归咎为代码规范缺乏足够的约束。

@skyline0705 模板引擎在防止XSS上虽然也不够完善，但程度是天壤之别的。安全性不是0和1，而是风险概率，如果从80%降低到20%，当然就应该引入。

[otakustay]

@hax 我们的态度会通过这样的一条表达出来：

[建议]不使用字符串拼接的方式生成HTML等带有转义风险的内容

在这个的基础上我不再添加“[强制]不使用template string拼接HTML”这样的规则，哪怕它们一个是建议一个是强制

@skyline0705 我坚持认为符合web使用的这个时代的模板引擎必须是默认HTML转义的，引擎的选择上也应该如此

[Justineo]

@hax 改成全部用 DOM 操作创建节点，文本内容全部写 textContent，这样是最安全的吧。模板引擎最终还是转换为 innerHTML 的吧，理论上还是没有前者安全。所以我觉得这还是一个折衷点选在哪里的问题。

[hax]

@Justineo
api的安全性正是如此。新的dom方法虽然方法名和jQuery一样（比如before，after），但都不是innerHTML。也就是所有DOM标准api里，只有innerHTML等几个legacy属性方法会有字符串直接转换到dom的能力。

然而template未必转换成innerHTML，也可能转换成全部dom操作，或转换成template元素+少量dom操作……但是这些并不决定安全与否，转成innerHTML也可以安全，转成dom操作也可能不安全。关键是模板的具体实现——分析出插值所在点的上下文并作出合理的转义。

之所以认为模板会更安全，不是因为现在的模板都做了合理转义，其实是没有几个模板做了合理转义。但是即使是不动脑筋的做基本HTML转义（替换<和"），也能杜绝90%的情况了。

[errorrik]

分析出插值所在点的上下文并作出合理的转义

我厂风格是编写模板的工程师确定当前上下文，并编写合理的转义。不过很可惜的是，很多工程师是完全不理的，妈蛋。

所以我们觉得选择默认HTML转义的模板引擎是合理的，正如 @hax 所说，能杜绝大多数情况了。

@otakustay

[建议]不使用字符串拼接的方式生成HTML等带有转义风险的内容

我觉得这个有点过严，原因是：

1. 明白人还是有的
2. 可能我的HTML只是静态HTML串呢

我建议是：

[建议] 使用字符串拼接的方式生成HTML，需要根据语境进行合理的转义。

另外，根据 @Justineo 所说，建议在浏览器环境->DOM部分增加：

** [建议] 文本内容通过 textContent 属性设置 **

以上两条，涉及JavaScript Style Guide文档，不涉及ESNext Style Guide文档。

大家觉得如何？

[Justineo]

可是 IE9+ 才支持 textContent，这么提不太好？

[errorrik]

可是 IE9+ 才支持 textContent，这么提不太好？

我就偷懒在上面随便一写，肯定要给出innerText方案的...

[errorrik]

我想了下，textContent兼容性的问题，解释清楚了太长，解释少了又不太好。而且确实存在兼容性问题，所以我建议这条不提了。毕竟[建议] 使用字符串拼接的方式生成HTML，需要根据语境进行合理的转义。已经是ok的了。

@Justineo @otakustay 你们觉得呢？

[errorrik]

另外，本issue有点跑题。@hax 提出的template string缩进格式的问题，依然无结论。聚焦下好了。

现在此条是建议，我觉得可以增加一些解释，当空行与空白字符敏感时，可以无视此条。不敏感时，为了代码可读性，应当遵守。

以上纯是个人的砖

[hax]

@errorrik 虽然说起来可以理解，但是这样的规则其实工具很难check。

[errorrik]

虽然说起来可以理解，但是这样的规则其实工具很难check。

@hax 指的哪条难check？空行与空白字符敏感还是需要根据语境进行合理的转义？

我觉得都难check，所以才都是建议。我们是有些方针，认为style guide：

1. 试图对编程风格、排版等作出约定，使不同的程序员能写出风格一致的程序；
2. 试图指出常见的编程陷阱，帮助程序员提高程序质量；
3. 试图指出晦涩罕用的语法，提醒程序员避免使用；
4. 试图给出编程实践的一些建议，以便于程序员改善自己的程序设计。

但是，强制的规则应该保证工具能check，建议的尽量，实在有用的条目，check不了也得写。

[otakustay]

规范能用工具自动化检测最好，但不能检测的规范并不是没有意义，我的建议如下：

[建议] 空格敏感时不使用带换行的template string

为避免破坏缩进的统一感，此类情况下使用多个template string或普通string进行连接运算

也可使用数组join生成字符串

// Bad
function greeting(name) {
    return `Hello, 
${name.firstName} ${name.lastName}`;
}

// Good
function greeting(name) {
    return 'Hello, \n'
        + `${name.firstName} ${name.lastName}`;
}

[hax]

我指的难以 check，是“是否空格敏感”本身。

比如 SQL 空格不敏感，SASS 空格敏感。但是工具得能认出这里是 SQL 还是 SASS。
何况还有 XML/HTML。大多数时候 XML/HTML 是空格不重要的（多个空白被折叠）。但是少数时候重要（http://www.w3.org/TR/xml/#sec-white-space ，以及有和无的差异导致可能多一些不希望有的空白节点）。

[errorrik]

我指的难以 check，是“是否空格敏感”本身。

是的，这事其实根本没法check。简单的例子，就算HTML片段看起来不敏感，css里加上个white-space:pre就不是那回事了。

所以，我的提议是，[建议] 使用多行字符串时遵循缩进原则。当空行与空白字符敏感时，可以无视此条。

如果大家还有其它提议（比如删除、修改描述、增加其它条目等），可以提出，咱们投票。