经过短暂的休息后，我们开始了新年冲刺。 与一年前一样，它将完全由Yandex在叶卡捷琳堡举行的大型FrontTalk会议的材料组成。 让我们从Yandex.Market的开发人员Anton Kastritsky的演讲开始。 Anton通过示例展示了如何组装接口以及如何组装接口，还谈到了文本，文本的设计，可访问性以及在现代Web应用程序上下文中的性能。
-我叫Anton，我是Yandex.Market合作伙伴界面团队的界面开发人员。 今天，我想谈谈网络上的排版。
在此之前，我想讲一个简短的故事，说明原来这个话题对我来说很有趣。
一旦我想到了一个事实，也许不是每个人都了解如何使用文本，字体以及在Web上显示。 也许我第一次想到它是在我想加入Yandex时。 我接受了采访，我有一个版面部分。 我喜欢布局，没什么复杂的，我喜欢。 有必要组成这个组件，我所做的一切都很棒。 在作业说明中写道，必须设置字体，其中有Arial，Helvetica。 嗯，没问题，我写的是无标题的Helvetica，Arial。 一切都是应有的。 但是面试官不同意说我写错了。 这让我感到困惑，我以为Yandex是一家大公司，可能他们对我有很多期望。 知道什么是系统字体，什么是安全字体。 我告诉他们它们是如何工作的，为什么我将所有内容都记下来。
面试官没有立即同意我的意见，但是结果是，我们了解到我们应该写Helvetica，Arial，而不是相反。 所以我去了Yandex。 我开始面试，发现了这个问题，并将其解决。 所以来找我们工作，这对我们很重要。
在继续排版之前，让我们先谈谈文字是什么。
文字内容
文字是一种工具，可以帮助我们告诉用户有关其下一步操作的信息。 互联网上很大一部分内容是文本。 尽管Instagram和YouTube之类的服务现在很流行，但人们仍然消耗大量多媒体内容，文本在Internet上也占据着巨大的空间，人们仍然在阅读它。 这很重要。
谁在有撰稿人或作家的公司工作，从事文本工作？ 差不多一半了。 谁想到了应用程序本身的文本？ 也一半。
有时碰巧是设计师为您提供了设计，然后您开始进行设计。 但是有一些不可预见的条件，您必须自己考虑一下文本。 几乎一切都哇。 在这种情况下，应该感到羞耻。 我给人的印象是，开发人员低估了撰稿人在公司中的作用，看不起他们并以某种方式提出。
一群坐在办公室里，非常熟练地模拟工作的艺术女士。 实际上并非如此。
撰稿人-像这个先知一样，试图向开发者女孩展示现实中的情况，她竭尽全力忽略他。
撰稿人的角色非常重要。 它们可以对产品产生直接影响，提供更和谐的解决方案，交互作用和机制。 阅读页面上的文本的人可以完全不同的方式感知您的产品。 他们的角色确实非常重要，应该经常倾听他们的声音，而不是像这个努力工作而不关注这位先知广播给她的女孩那样的女孩。 试着听听您的撰稿人，并随时向他们提问。
这不仅对您编写的内容很重要，而且对于一般而言也很重要。 我想展示一个真实的例子。 我们有一个组件，用户需要在其中添加电话号码。
包含设置的巨大页面，一切正常。 有一个标签，数字，“添加”按钮，用户单击它，然后出现电话输入。
成功输入电话号码后，他需要单击灰色的选中标记进行保存。
当我们开始进行UX测试时，我们了解到很少的用户甚至猜测有必要单击灰色按钮来保存电话号码。 我们做了什么？ 用户成功输入电话号码后，我们将复选标记涂成黄色，然后用户可以保存它。
我们进行了重复的UX测试。 还有更多的人想出了如何保存电话号码。
此时，在您看来，我们的用户在与我们的界面进行交互时遇到了一些问题，他们以某种方式使用了它们。
但是实际上，问题不在于用户，而在于我们，因为我们无法清楚地向他们确切传达我们从他们那里想要什么。 因此，今天该组件看起来有点不同：所有内容也都单击了按钮，但是现在它有了一个带有显式按钮“取消”和“保存”的弹出窗口。
成功输入电话号码后，“保存”按钮将亮起，用户可以独立决定是否要保存它。 如果他在弹出窗口外单击，则弹出窗口将消失，并且他尚未添加该数字。
由此我们可以得出结论：不要害怕写明显的东西。 我们开发人员在Internet上花费了大量时间，我们看到许多关于如何执行相同操作的GUI选项。 但是，并非我们所有的用户都有这种经验。 因此，让我们制作更简单，更直观的界面，使用户可以更轻松地自行解决。
展示架
让我们来谈谈一般的映射。 很容易猜到所有显示规则都是从印刷品中得出的。
取代我是开发人员非常重要，但我做不到。 我知道如何使其正常工作，并且一切正常时都可以正常工作。 因此，我不会谈论衬线或不同类型的字体。 我会的，但是以后。
互联网上有很多文本内容和服务，用户可以专门阅读某些内容。
在我看来，最便捷的服务之一是中型。 我想每个人都认识他，他们进来阅读新闻，尤其是有关前端的新闻。 该服务确实提供了易于阅读的内容。 但是，我将举一个我们都使用过的反例。
我不认识访问Wikipedia并乐于阅读任何内容的人。 在我看来，这不是一个可读的选项，尽管可以通过仅遵循两个或三个规则来解决。
首先是每行大约10个单词。
我们需要将文本内容的宽度限制为大约80个字符。 该规则可能类似于您的短毛猫的设置，因为代码的显示以及代码本身以及站点上的文本都是经过编写的，因此可以由个人（而不是计算机）轻松感知。
第二个是行距。 当您的线彼此之间太近时，用户已经开始难以理解这一点。
并让字体更大一些，以便于感知。 现在，Wikipedia正在采用一种已经明显易于理解的形式。
而且，如果屏幕空间对您非常重要，则可以添加连字符。
这可能无法始终正确处理俄语文本，但可以帮助节省几行。
不要忘记俄语中有很多拼写规则。 我们需要摆脱诸如挂断借口之类的事情，确保在必要时应该有大的连字符，等等。 像
Typographer这样
的工具可以帮助您。 只需在其中输入文字即可，仅此而已。
如果您有静态文本，则可以在构建应用程序时添加
babel插件以对其进行转换。 如果您的文本存储在外部存储器中，那么这样的
npm包可能会派上用场；使用它，您可以在将文本发送到客户端之前进行转换。
网络字体
我们怎么能在网络上使用不同的字体？
成人开发人员可能会记得，很长一段时间以来，如果我们想以某种方式改变页面上文本的外观，就必须添加不同的图像。 后来我们得到了一个字体标签。 今天，我们使用font-family属性，在该属性中，我们按照希望应用字体的顺序列出了字体本身。 如果浏览器突然找不到并无法识别它，它将在此列表上继续走，并使用以下内容。
今天，我们已经拥有大量的属性来转换文本的显示。
而且我不禁提到诸如可变字体之类的东西。
这有助于我们进一步改变界面的显示方式。 今天，支持已经足够了。
在过去的几年中，有关此技术的大量信息已在Internet上发布，我们现在不再赘述。
字型
有大量的字体。 但是我想从工程学的角度出发，将它们分为几种类型。
我认为，不仅阅读规格的每个人都知道，包装盒中的操作系统已预装了系统字体。 有用户独立安装的已安装字体。 以及可下载或Web字体，这就是用户通过转到您的应用程序下载的所有内容。
我不得不提到安全字体。 事实证明我们有他们吗？ 以前，我们不能指望用户使用该字体，因此，在2000年代初，Microsoft提供了从上个十年开始就出现在所有系统上的六种字体的列表，并且开发人员可以清楚地使用它们，知道这些字体已经在用户处出现，并且不必发送额外的请求。
在这里，我们看到了相同的Arial。 展望未来：有人已经知道Helvetica是macOS上的一种系统字体，已经存在了很多年。 因此，在我一开始提到的故事中，我说过我们应该记录Helvetica和Arial，而不是相反。
在那之后，我在各种资源上都注意到了这个记录，我想知道它是从哪里来的，结果证明人们会犯这样的基本错误。 毕竟，当我们刚开始学习CSS时，我们就会学习它。
当我意识到它来自像w3schools这样受人尊敬的资源时，我感到非常惊讶，向他们发送了错误报告，但是他们仍然没有解决它，嗯。
现在回到字体。 我们如何连接字体？ 我们有CSS和JavaScript。
我们可以声明一个自定义字体，并指定几种格式，浏览器将从中选择并下载它知道的第一个字体。
-WOFF2最好被所有现代浏览器压缩和支持。
-WOFF压缩效果稍差，但具有出色的支持。
-旧版IE仅需要EOT。 -TTF，它也有很好的支持，通过下载，我们可以将其安装在OS上。
-我认为不推荐使用SVG，今天仅支持一两个浏览器。
我们还有一个很酷的CSS函数，例如local，借助它的帮助，我们可以检查用户操作系统中是否存在该字体。 但是你真的不必依靠她。 即使字体具有相同的名称，也并不意味着它们是相同的字体。 因此，如果您使用它，请当心。
宣布字体后，请不要忘记指定一些备用，以防浏览器无法下载它。
我想很多人都知道我们可以为字体指定Unicode范围，并且在下载字体后，它将专门用于指定的字符。 例如，您只想显示此字体的英语文本或仅显示数字等。
它还使您可以大大减少我们发送给用户的流量。
在上面，我们可以将字体分为两个单独的文件，一个文件中只有拉丁字符，第二个文件是西里尔字母。 我们给它们指定了相同的字体系列名称，以便浏览器理解它们是单个字体的一部分。 现在，如果页面上只有西里尔字母，则用户将仅下载第二个文件，从而减少了用户下载的流量。
因此，进行子集并不是很困难，为此既有GUI工具也有CLI工具，找到它们并进行处理并不困难。
幻灯片中的链接： 第一 ， 第二 ， 第三 ， 第四
今天的支持相当不错。 不要害羞地使用它。
不要忘记伟大的谚语“七次测量-一次安息”，否则您会陷入一种相当不舒服的境地。
我们也可以使用JS下载字体，我们有一个FontFace API，它看起来非常相似。
我们声明一个新字体，将其加载，然后异步加载。 加载后，我们可以将其添加到页面中。
乍一看，除非您参与字体服务，否则这种方法似乎没有用。 但是到报告结尾，您可能会改变主意。
好吧，我们有一项服务，我们在其中添加了几种字体。 我们的用户来到我们的页面，并遇到了这样的图片。
怎么发生的？ HTML已经到达，样式已经加载，字体还没有到达，并且浏览器的行为可能会有所不同。 一些浏览器阻止了文本的呈现，似乎没有文本，但是实际上浏览器使用自己的透明字体绘制文本，因为它们需要知道文本在页面上占用了多少空间，以便所有缩进都是相似的。 加载字体后，将使用您的字体重新绘制文本并显示在浏览器中。
如果能在这种情况下统一浏览器的行为，那就太好了。 实际上，某些浏览器可以使用透明字体呈现文本，而其他浏览器则可以使用折叠字体。 为此，我们只有一行代码。
基本上，只有块或交换对您有用。 Block将使浏览器等待并使用透明字体呈现页面上的内容，因为您很有可能拥有一些非常漂亮的自定义字体，看起来像什么都不是。 因此，您不希望用户看到文本，因此请用户等待。 它不会永远等待，只有三秒钟，之后它将使用以下字体，并等待完全无穷大直到您到达。
或交换，当浏览器立即获取下一个折叠字体时，用它绘制内容，然后等待无限时间字体到达。
今天的支持非常好，已经可以使用了。 毕竟，CSS不是JS，如果浏览器突然不理解某些内容-没关系，它将忽略此规则并走得更远。 在这种情况下，我们得到的行为与以前相同。
太好了，我们提示了浏览器，现在几乎所有非旧版浏览器都具有相同的行为。
但是我们没有解决问题本身。 字体这么长怎么发生的？ 很久以前，当我还没有在Yandex中工作时，我做了一点着陆，没什么特别的，但是有很多照片和一些风格。
我遇到了这样一个问题，即字体在6-7秒内到达了字面上，这只是通过限制网络以加快3G速度，尽管第一个渲染图已经在某个地方显示了2.5秒，用户只是看着空白页。
蓝色HTML加载在顶部，然后是紫色样式。 我们的字体在哪里？
他在那 怎么发生的？ 我们需要澄清一点，即使我们在样式的开始就声明了字体，浏览器也只会在下载所有CSS，完全解析并看到页面上需要使用此字体绘制的文本之后，才发送请求。 。
如果我们能告诉浏览器，那就太好了：听着，我一定会使用这种字体，然后立即下载。
这样就可以了。 这称为字体加载。 我们可以在一行中告诉浏览器，在发送样式请求之前，我们需要下载此特定字体并发送请求。 现在，请求的瀑布看起来有所不同。
具有正确字体的文本与所有其他内容一起显示约3秒钟。 这不会加快我们的网站的速度，但是用户可以立即开始浏览此内容。 那很好。
链接预加载仅在相当现代的浏览器中才有效，并且主要与woff2一起使用是值得的，如果不是，则只需woff。 因为请求总是发送。
预加载的另一种良好做法：您只需指定浏览器可以理解的一个文件。 如果您开始在MDN上阅读有关内容，将会看到类似的内容。
这绝对不值得做，因为尽管浏览器仅使用一种格式，但是这是我们向每种格式发送大量请求的方式。 他们为什么在这里添加仅用于IE的eot格式，而该ot格式已不再开发，甚至不被Microsoft支持？ 他们不太可能告诉我们这一点。
类似的代码看起来应该更有可能。
初始化应用程序时，也许还有其他任务需要完成？ , , , , , .
— . JS, , , , , .
. , , . . Font style matcher, , CSS , , , , , , “”.
-? , , .
, . ? , , , Yandex Sans. , . , ? , , ?
«», -. , . ? , . .
, system-ui, , stage 2, , Windows, .
, , . , , . , github, Twitter, Medium. , .
, , , , bootstrap. .
, , accessibility, , , , .
? , - ?
, , -, , . , , .
,
axe pa11y , accessibility test runners, CI-. . pa11y .
- . , , ? .
, , . , color picker dev tools, Chromium- — .
, , , , . , , , , , , .
, , , .
.
, localStorage, . , , . , , , - , .
, : localStorage , key-value-, — . - , , .
— . head HTML- . , . , , bounce rate. , — , , .
, , . : , 200 , . — , . , — , , svg. , . svg CSS- .
, . . , , . — svg.
. , , . — : , , , . .
. , . . , . , , .
, , , . — , . 谢谢你