update: supplement

docs/art/83vue-parsing-2.md

@@ -1520,7 +1520,7 @@ typeBinding = `({ type: inputType }).type`
 
 我们知道在 `AST` 中一个标签对应一个元素描述对象，所以从结果上看，`preTransformNode` 函数将一个 `input` 元素描述对象扩展为三个 `input` 标签的元素描述对象。但是由于扩展后的标签由 `v-if`、`v-else-if` 和 `v-else` 三个条件指令组成，我们在前面的分析中得知，对于使用了 `v-else-if` 和 `v-else` 指令的标签，其元素描述对象是会被添加到那个使用 `v-if` 指令的元素描述对象的 `el.ifConditions` 数组中的。所以虽然把一个 `input` 标签扩展成了三个，但实际上并不会影响 `AST` 的结构，并且从渲染结果上看，也是一致的。
 
-但为什么要将一个 `input` 标签扩展为三个呢？这里有一个重要因素，由于使用了绑定的 `type` 属性，所以该 `input` 标签的类型是不确定的，我们知道同样是 `input` 标签，但类型为 `checkbox` 的 `input` 标签与类型为 `radio` 的 `input` 标签的行为是不一样的。到代码生成的阶段大家会看到正是因为这里将 `input` 标签类型做了区分，才使得代码生成时能根据三种不同情况生成三种对应的代码，从而实现三种不同的功能。有的同学就会问了，这里不做区分可不可以？答案是可以的，但是假如这里不做区分，那么当你在代码生成时是不可能知道目标 `input` 元素的类型是什么的，为了保证实现所有类型 `input` 标签的功能可用，所以你必须保证生成的代码能完成所有类型标签的工作。换句话说你要么选择在编译阶段区分类型，要么就在运行时阶段区分类型。而 `Vue` 选择了在变异阶段就将类型区分开来，这么做的好处是运行时的代码在针对某种特定类型的 `input` 标签时所执行的代码是很单一职责的。当我们后面分析代码生成时你同样能够看到，在编译阶段区分类型使得代码编写更加容易。
+但为什么要将一个 `input` 标签扩展为三个呢？这里有一个重要因素，由于使用了绑定的 `type` 属性，所以该 `input` 标签的类型是不确定的，我们知道同样是 `input` 标签，但类型为 `checkbox` 的 `input` 标签与类型为 `radio` 的 `input` 标签的行为是不一样的。到代码生成的阶段大家会看到正是因为这里将 `input` 标签类型做了区分，才使得代码生成时能根据三种不同情况生成三种对应的代码，从而实现三种不同的功能。有的同学就会问了，这里不做区分可不可以？答案是可以，但是假如这里不做区分，那么当你在代码生成时是不可能知道目标 `input` 元素的类型是什么的，为了保证实现所有类型 `input` 标签的功能可用，所以你必须保证生成的代码能完成所有类型标签的工作。换句话说你要么选择在编译阶段区分类型，要么就在运行时阶段区分类型。而 `Vue` 选择了在编译阶段就将类型区分开来，这么做的好处是运行时的代码在针对某种特定类型的 `input` 标签时所执行的代码是很单一职责的。当我们后面分析代码生成时你同样能够看到，在编译阶段区分类型使得代码编写更加容易。如果从另外一个角度来讲，由于不同类型的 `input` 标签所绑定的事件未必相同，所以这也是在编译阶段区分 `input` 标签类型的一个重要因素。
 
 
 ## 文本节点的元素描述对象