Open xfq opened 5 months ago
bobbytung
commented
4 months ago On CLREQ's call 2024/5/29
I think when "Date" and "TimeDate" in vertical writing, It should be better to set numbers in input box for best i18n practices.
That is "2024/05/29" should be "二〇二四年五月二十九日", or "２０２４／５／２９".
I think it is applicable for Japanese, if we use "ja-u-ca-japanese", the date will be "令和6年5月29日". It will be better that 6 and 5 in fullwidth form and 29 in Tate-chu-yoko format.
xfq
commented
4 months ago 
realfish
commented
3 months ago 根据 2024-05-29 CLReq 例会讨论，拟新增人机交互控件相关的排版处理原则，并独立为新章节。
下文草拟章节目录及内容框架，以备后续讨论及内容完善。章节编号未定，暂以「X」代之。
X. 人机交互控件的排版处理（草拟）
文本输入控件可供用户输入任意文本内容。在控件内展示用户输入的中文内容或中、西文混排内容时，排版处理方式应遵循「3. 行内文字排版处理」一节所述的各项原则。
文本输入过程中的交互体验，应优先确保用户输入的连贯性和对当前正在输入字符的认知准确性。
Note
为保证文本输入过程中的交互体验，应审慎处理「3.1.6 标点符号的宽度调整」及「3.5 行内调整」，避免用户对「3.1.2 标点符号的字形、尺寸与字面分布」产生误解或困惑。
文本输入控件应支持「2.4 中文的文字书写方向」一节所述的直排与横排两种文字书写方向及相关排版原则。
单行文本输入控件可供用户输入任意不可换行的文字内容。
通常，单行文本输入控件中的文字排版不涉及换行处理，无需处理标点禁则（包括「3.1.4 行首行尾禁则」和「3.1.5 符号分离禁则」），或因标点禁则而造成的「3.5 行内调整」。
数字输入控件是一种特殊的单行文本输入控件，通常专供用户输入数字，并附带校验规则，以确保输入内容仅为数字。
在中文书写系统中，除阿拉伯数字外，汉字数字（一、二、三……）或大写汉字数字（壹、贰、叁……）也是常用的数字表记方式。其中，汉字数字常在法律文件或公文中用于表记具有法律效力的数值；大写汉字数字是某些法律文件或财务文件必需的数字表记方式。
Note
阿拉伯数字「0」，有「零」和「〇」两种汉字书写形式。在中国大陆地区，GB/T 15835—2011《出版物上数字用法》建议「一个数字用作计量时，其中『0』的汉字书写形式为『零』，用作编号时，『0』的汉字书写形式为『〇』」。
Note
数字输入控件的内容书记格式或控件交互模式，可能附带本地化处理。人机交互界面的开发者应根据实际场景控制本地化处理的地区偏好，兼顾控件所在上下文的地区偏好一致性和交互体验的包容性。
日期时间输入控件是一种特殊的单行文本输入控件，通常仅供用户输入特定格式的日期时间信息，并附带校验规则，以确保用户输入的内容为符合特定格式的日期时间信息。
中文日期书记有多种格式，包括但不限于：
Note
在农历纪年中，月份「一月」常记为「正月」，「十一月」常记为「冬月」，「十二月」常记为「腊月」；日期「一日」至「十日」通常记为「初一」至「初十」，日期「二十一日」至「二十九日」通常记为「廿一」至「廿九」。
直排的日期信息，应优先考虑使用汉字数字书记；如果使用阿拉伯数字书记年、月、日， 数字部分的排版可能会按需采用纵中横排。
Note
日期时间输入控件的内容书记格式或控件交互模式，可能附带本地化处理。人机交互界面的开发者应根据实际场景控制本地化处理的地区偏好，兼顾控件所在上下文的地区偏好一致性和交互体验的包容性。
密码输入控件是一种特殊的单行文本输入控件，用户输入的文字会被遮蔽，例如：不显示用户输入的内容，或将输入内容替换成无差别、无语义的符号。
Note
密码输入过程中，密文替代符号不应在造型或排列方式上表现出与密文内容直接相关的特征，包括特殊的中文排版属性等。
Note
如果密码输入控件所在的上下文为直排中文，应在字符输入过程中，提供与直排单行文本输入控件相似的交互体验，包括但不限于：替代符号的输入递进方向应为从上至下，输入光标（caret）应在垂直方向移动。
多行文本输入控件可供用户输入任意文字内容，并可包含换行控制符。
若因用户主动输入换行控制符，导致文字排版结果有悖于标点禁则（包括「3.1.4 行首行尾禁则」和「3.1.5 符号分离禁则」），应维持用户输入的原状。
单选（radio）和复选（checkbox）控件均为特殊的输入控件，控件本身通常为一个或一组可点击的图形化按钮。在人机交互界面中，某个单选或复选控件按钮，通常存在与其关联的图、文信息，以描述对应控件的语义或功能。
与单选或复选控件关联的文字信息，其中涉及的中文内容，或中、西文混排内容，其排版处理方式应遵循「3. 行内文字排版处理」一节所述的各项原则。
单选或复选控件的图形按钮本身，不涉及中文排版的书写方向问题。
与单选或复选控件关联的文字信息，通常应与其所在上下文的书写方向保持一致，故应支持「2.4 中文的文字书写方向」一节所述的直排与横排两种文字书写方向及相关排版原则。
文件选择器是一种特殊的输入控件，可允许用户选择一个或多个本地文件作为输入对象。
文件选择器在人机交互界面中附带的缺省文案及所选文件名的展示，可能涉及中文排版或中、西文混合排版，其排版处理方式应遵循「3. 行内文字排版处理」一节所述的各项原则。
如果文件选择器的文案展示不涉及换行处理，则无需处理标点禁则（包括「3.1.4 行首行尾禁则」和「3.1.5 符号分离禁则」），或因标点禁则而造成的「3.5 行内调整」。
Note
文件选择器附带的缺省文案，可能涉及本地化处理。人机交互界面的开发者应根据实际场景控制本地化处理的地区偏好，兼顾控件所在上下文的地区偏好一致性和交互体验的包容性。
文件选择器附带的缺省文案及所选文件名展示，其书写方向通常应与控件所在上下文的书写方向保持一致，故应支持「2.4 中文的文字书写方向」一节所述的直排与横排两种文字书写方向及相关排版原则。
按钮内部通常可展示任意非交互性的图、文内容，其中涉及的中文内容，或中、西文混排内容，其排版处理方式应遵循「3. 行内文字排版处理」一节所述的各项原则。
按钮内部的文字书写方向，通常应与其所在上下文的书写方向保持一致，故应支持「2.4 中文的文字书写方向」一节所述的直排与横排两种文字书写方向及相关排版原则。
选项菜单是由一组选项构成的控件，在人机交互界面中供用户选择其中的一项或多项，以触发后续交互。
选项本身可由任意非交互性的图、文内容构成，其中涉及的中文内容，或中、西文混排内容，其排版处理方式应遵循「3. 行内文字排版处理」一节所述的各项原则。
选项菜单内的文字书写方向，通常应与其所在上下文的书写方向保持一致，故应支持「2.4 中文的文字书写方向」一节所述的直排与横排两种文字书写方向及相关排版原则。
选项菜单内的各个选项之间，可能涉及排序先后。在人机交互界面中，用户通常以文本阅读顺序来推断选项的排序先后。因此，在直排中文内，默认先后顺序为从右至左；在横排中文内，默认先后顺序为从上至下。
在人机交互模式中，选项菜单可能须由其他控件激发或释放，因而常与其他控件组合使用，例如「X.4 按钮」。选项菜单及与其组合使用的其他控件，应在书写方向上保持一致。例如：直排选项菜单应与直排按钮组合使用，反之亦然。
Note
选项菜单及与其组合使用的其他控件之间，布局的相对位置关系并无绝对规定。人机交互界面的开发者应根据实际场景处理各控件的位置关系及交互动画的方向性，兼顾控件所在上下文的地区偏好一致性和交互体验的包容性。
eisoch
commented
3 months ago Note
在农历纪年中，月份「一月」通常记为「正月」；日期「一日」至「十日」通常记为「初一」至「初十」，日期「二十一日」至「二十九日」通常记为「廿一」至「廿九」。
Apple的日历app中把十一月写作冬月，十二月写作腊月，这也是常见的说法。
xfq
commented
3 months ago 为保证文本输入过程中的交互体验，应审慎处理「3.1.6 标点符号的宽度调整」及「3.5 行内调整」，避免用户对「3.1.2 标点符号的字形、尺寸与字面分布」产生误解或困惑。
这里是否需要举个可能产生误解或困惑的例子？
数字输入控件的内容书记格式或控件交互模式 日期时间输入控件的内容书记格式或控件交互模式
这里的「内容书记格式」指的是输入内容的格式？感觉有点晦涩。
另外，可以考虑加一些配图。（不过UX和UI设计风格一直在变化，配图可能过几年再看觉得比较老……）
realfish
commented
3 months ago 这里的「内容书记格式」指的是输入内容的格式？感觉有点晦涩。
如果考虑「所见即所得」的交互体验，其实用户输入的格式和 UI 渲染的格式，理论上可以保持一致。所以这里的「书记格式」主要就指信息本身的 representation。例如，同一个日期，可以有多种书记格式：
再比如数字书记格式也是类似的。虽然现状下，专供「大写汉字数字」的输入框极罕见，但我暂时的考虑是：站在用户交互和内容展示的需求方角度，应该可以假设「专供大写汉字数字」的输入交互是有可能被实现出来、并提供符合场景需要的用户体验。
P.S. 「书记格式」主要是为了区别于一个信息在口语表述、认知、书写上的差异。比如上面的四种日期书记格式，在认知上是同一个日期信息，可能用口语念出来也是同一种（都是「二、〇、二、四、年、六、月、二、十、日」），但书写上就有很大的字符或排版特性差异。
realfish
commented
2 months ago 结合 6 月 26 日例会讨论，计划对前文草案的结构做进一步简并：
下记修订后的草案。（注：草案侧重预先拟定本章的结构框架；细节内容比较简略及不稳定，仍有待进一步讨论、校对及补充。）
X. 人机交互控件的排版处理（草拟）
人机交互控件可能涉及图、文信息的展示，所需展示的内容主要来自两方面：控件自身的信息表达，以及控件对用户输入信息的展示。本文档侧重关注控件内文字信息展示相关的排版需求。
在人机交互控件内展示中文内容或中、西文混排内容时，排版处理方式应遵循「3. 行内文字排版处理」一节所述的各项原则。
控件内的文字书写方向，通常应与其所在上下文的书写方向保持一致，故应支持「2.4 中文的文字书写方向」一节所述的直排与横排两种文字书写方向及相关排版原则。
若控件中的文字排版不涉及换行处理，则无需处理标点禁则（包括「3.1.4 行首行尾禁则」和「3.1.5 符号分离禁则」），或因标点禁则而造成的「3.5 行内调整」。
若控件支持文本输入，则交互体验应优先确保用户输入的连贯性和对当前正在输入字符的认知准确性。
Note
为保证文本输入过程中的交互体验，应审慎处理「3.1.6 标点符号的宽度调整」及「3.5 行内调整」，避免用户对「3.1.2 标点符号的字形、尺寸与字面分布」产生误解或困惑。
Note
部分控件的内容书记格式、控件交互模式及缺省文案等，可能附带本地化处理，包括但不限于「X.2.2 数字输入控件」「X.2.3 日期时间输入控件」「X.4 文件选择器」。人机交互界面的开发者应根据实际场景控制本地化处理的地区偏好，兼顾控件所在上下文的地区偏好一致性和交互体验的包容性。
单行文本输入控件可供用户输入任意不可换行的文字内容。控件的文字排版，应遵循「X.1 人机交互控件排版通则」。
数字输入控件是一种特殊的单行文本输入控件，通常专供用户输入数字，并附带校验规则，以确保输入内容仅为数字。
在中文书写系统中，除阿拉伯数字外，汉字数字（一、二、三……）或大写汉字数字（壹、贰、叁……）也是常用的数字表记方式。其中，汉字数字常在法律文件或公文中用于表记具有法律效力的数值；大写汉字数字是某些法律文件或财务文件必需的数字表记方式。
Note
阿拉伯数字「0」，有「零」和「〇」两种汉字书写形式。在中国大陆地区，GB/T 15835—2011《出版物上数字用法》建议「一个数字用作计量时，其中『0』的汉字书写形式为『零』，用作编号时，『0』的汉字书写形式为『〇』」。
日期时间输入控件是一种特殊的单行文本输入控件，通常仅供用户输入特定格式的日期时间信息，并附带校验规则，以确保用户输入的内容为符合特定格式的日期时间信息。
中文日期书记有多种格式，包括但不限于：
Note
在农历纪年中，月份「一月」常记为「正月」，「十一月」常记为「冬月」，「十二月」常记为「腊月」；日期「一日」至「十日」通常记为「初一」至「初十」，日期「二十一日」至「二十九日」通常记为「廿一」至「廿九」。
直排的日期信息，应优先考虑使用汉字数字书记；如果使用阿拉伯数字书记年、月、日， 数字部分的排版可能会按需采用纵中横排。
密码输入控件是一种特殊的单行文本输入控件，用户输入的文字会被遮蔽，例如：不显示用户输入的内容，或将输入内容替换成无差别、无语义的符号。
Note
密码输入过程中，密文替代符号不应在造型或排列方式上表现出与密文内容直接相关的特征，包括特殊的中文排版属性等。
Note
如果密码输入控件所在的上下文为直排中文，应在字符输入过程中，提供与直排单行文本输入控件相似的交互体验，包括但不限于：替代符号的输入递进方向应为从上至下，输入光标（caret）应在垂直方向移动。
多行文本输入控件可供用户输入任意文字内容，并可包含换行控制符。
若因用户主动输入换行控制符，导致文字排版结果有悖于标点禁则（包括「3.1.4 行首行尾禁则」和「3.1.5 符号分离禁则」），应维持用户输入的原状。
单选（radio）和复选（checkbox）控件均为特殊的输入控件，控件本身通常为一个或一组可点击的图形化按钮。在人机交互界面中，某个单选或复选控件按钮，通常存在与其关联的图、文信息，以描述对应控件的语义或功能。
与单选或复选控件关联的文字信息，其中涉及的中文内容，或中、西文混排内容，其排版处理方式应遵循「X.1 人机交互控件排版通则」。
文件选择器是一种特殊的输入控件，可允许用户选择一个或多个本地文件作为输入对象。
文件选择器在人机交互界面中附带的缺省文案及所选文件名的展示，可能涉及中文排版或中、西文混合排版，其排版处理方式应遵循「X.1 人机交互控件排版通则」。
按钮内部通常可展示任意非交互性的图、文内容，其中涉及的中文内容，或中、西文混排内容，其排版处理方式应遵循「X.1 人机交互控件排版通则」。
选项菜单是由一组选项构成的控件，在人机交互界面中供用户选择其中的一项或多项，以触发后续交互。
选项本身可由任意非交互性的图、文内容构成，其中涉及的中文内容，或中、西文混排内容，其排版处理方式应遵循「X.1 人机交互控件排版通则」。
选项菜单内的各个选项之间，可能涉及排序先后。在人机交互界面中，用户通常以文本阅读顺序来推断选项的排序先后。因此，在直排中文内，默认先后顺序为从右至左；在横排中文内，默认先后顺序为从上至下。
在人机交互模式中，选项菜单可能须由其他控件激发或释放，因而常与其他控件组合使用，例如「X.5 按钮」。选项菜单及与其组合使用的其他控件，应在书写方向上保持一致。例如：直排选项菜单应与直排按钮组合使用，反之亦然。
Note
选项菜单及与其组合使用的其他控件之间，布局的相对位置关系并无绝对规定。人机交互界面的开发者应根据实际场景处理各控件的位置关系及交互动画的方向性，兼顾控件所在上下文的地区偏好一致性和交互体验的包容性。
xfq
commented
2 months ago 若控件中的文字排版不涉及换行处理，则无需处理标点禁则（包括「3.1.4 行首行尾禁则」和「3.1.5 符号分离禁则」），或因标点禁则而造成的「3.5 行内调整」。
这句话是不是不提也行？如果不涉及换行处理，好像也没办法处理标点禁则。
若控件支持文本输入，则交互体验应优先确保用户输入的连贯性和对当前正在输入字符的认知准确性。
这里的「用户输入的连贯性」指的是什么？类似于不打断用户输入时的「意识流」？
如果密码输入控件所在的上下文为直排中文，应在字符输入过程中，提供与直排单行文本输入控件相似的交互体验，包括但不限于：替代符号的输入递进方向应为从上至下，输入光标（caret）应在垂直方向移动。
输入光标的英语我们一般用cursor，不过caret也可以。
谢谢 @realfish ！
Do we need to write about the behavior of vertical form controls in clreq? Some examples:
Possibly wrong behavior: