表单里看得见的文字不全是回答：GitHub提示、预填与字段身份

GitHub的form schema文档把表单定义为请求用户输入的一组元素。每个元素有类型、属性和约束等资料；某些键的值本身还是一组键值对。这个层次使“这是什么元素”和“它显示哪段文字”成为两项信息。textarea是多行文本字段，input是单行字段；它们属于类型。label、description等则描述元素怎样被说明，并不是与单行、多行并列的另一类输入方式。[1]

markdown元素尤其能说明显示与提交的区别。它用于给用户提供额外上下文，文档明确说其文字不会被提交。即便该元素也用value保存要显示的内容，这个value仍处在markdown的属性语境中。只看到某个元素含有value，不能抹去元素类型，便把所有显示出来的value都写成用户已经提交的答案。[1]

对文本输入，label简短说明期望用户提供什么，description则再提供上下文或引导，两者都会显示。placeholder位于空字段中，value则是预先填入字段的文字。这四项面对同一个字段，却分别承担题目、补充说明、空白时提示和预填内容的职责。空字段里的浅色提示不是一个已经填写的值，题目出现在字段旁边也不意味着题目自身就是该字段的回答。[1]

文档中的Operating System示例同时保留label、description、placeholder与value，正因为它们能够并存。示例性的系统名称可以帮助说明所需信息，而预填文字另有自己的属性。对表单资料的转述，逐项保留这些身份，比把所有文字合成“系统字段内容”更准确；后者无法说明一段话是在问用户、提示用户，还是已经作为预填文字放入输入区域。[1]

字段的id又处于另一层。除markdown外，id是元素标识，必须在表单定义中唯一；如果提供，它还是URL查询参数预填时使用的规范字段标识。label承担可见说明，id承担定义中的识别关系。二者可能让人想到同一个问题，却没有被文档规定为同一段文字；仅抄可见题目，并没有因此保留原定义中用于识别字段的id。[1]

下拉框把选项内容与预选位置分开。options是用户可选的字符串数组，不能为空，而且各个选择必须不同；multiple说明是否允许选择多个选项。default记录的是预选项在options中的索引，不是另加在清单外的一段默认答案。因此，一个默认索引需要联系它所指向的选项清单理解；只有位置资料而没有清单内容，仍不能知道预选文字是什么。[1]

复选框则有整组和单项两层。整组可以有label、description与options，每个option还保留自己的、会显示出来的label。组标签解释这一组问题，选项标签标识组内某一个选择，这与把下拉框各项直接写成字符串数组不同。只统计界面上出现了多少个label，会把整组题目和可勾选的各项混在一起，丢失原schema实际保留的包含关系。[1]

以上限于该文明确标为public preview、可能变化的schema说明，未创建或提交表单、上传文件或设置仓库权限，也不据字段存在判断任何实际用户的回答。[1]

资料来源：
[1] [Syntax for GitHub's form schema](https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/syntax-for-githubs-form-schema?trk=public_post_comment-text)