吾乃笼中鸟、网中鱼，此一行如鱼入大海，鸟上青霄，不受笼网之羁绊也

刘备口中的羁绊，是束手束脚的贬义。日漫里的羁绊，却是相辅相成抑或是相反相成。现实里都存在，但对于创作者而言，刘皇叔诚不我欺也。思绪被打断乃是一种毒药，创作如是，代码如是。每当集中心力于一点，却还需要抽丝剥茧般撩断千头万绪之琐事，便如断线之筝，闪崩之堤，溃于无形。

饶是去年还画个逐帧短片，今年假期已经过半却一事无成，只能在工位上静思，于此也只能叹息感慨，当真是开了个不怎么好的头。

脑海中突然闪现了一个词——道标，一个我从某首歌里学到的看似普通的稀有词汇。循着模糊的记忆，总算在一个废旧的网易云账号里翻出了一首少人问津的歌：最後の道標。霜月はるか的歌声有些悲凉，并且，因为听的人少，歌词也没人给翻译，我便只能凭着蹩脚的日语听力，抓住一些歌词的碎片：天空，意义，生命，寻找......没有真正经历过苦难便很难想象某些词的分量，我也只能从苍凉的声音里感受希望的光亮——人生，当有道标。

每一年，承前启后的时候，用一句话总结过去的一年，然后再用一句话预告将来的一年，便是我的道标。并且对我来说，这不是最後の道標，反而是初始の道標。虽然有些晚了，但这初始的道标还是立下了：笼网之羁，庸碌无为；强身健体，以期不惑。

作为的代码工作者，很多年前就在键盘圈子里入绕了不少圈，从最早100多一把的国产垃圾青轴，到缓存烈焰枪XT茶轴，红轴，青轴，再到Filco 双模茶轴，Filco minila从茶轴，中间自己组了一把GH60，上高特青，然后又是捡垃圾拆樱桃茶轴换上，最后又是全部出掉，换回了Filco，一用就是快10年了。退圈以后就很少再关注，没想到再次进入视野的键圈早就发生了天翻地覆的变化。

各种结构的套件，和各种五花八门的轴体，对于一个早期只知道樱桃轴的键盘侠造成了无与伦比的混乱。但我还是逐渐习惯了各种迥异的名词逐渐理解了现在的版本状态——这可能要归功于身为一个键盘重度依赖者天生的好奇心，和对输入感受的必然追求。

然后我就下单了一把狼蛛的F75，199的版本。说实在的，拿到的第一感觉实在惊艳，要是拿10年前的标准来评判，各方面都很赞，而这居然只是当前产品里的平均水准，只能说这几年键圈卷的程度实在吓人。

现在的键盘相比以往要求的更多也更严格，不止要手感——声音，外观，材质，配列，可玩性等等都有要求，这造就了更多维度评判准则和更为严苛的竞争环境。对我来说仿佛就是跨了一个时代过来的。

之后买了Rainy75，对于这样的铝键盘，10年圈前是想也不敢想的（巨贵），但如今只要不到500，而且各方面都很平衡，再次让我感到震惊。然后149买了是首发的迈从的G75侧刻，回想起第一把买的国产机械键盘也是149，那时候的产品就是个钢板插了几个高特的青轴做工之粗糙，和当前的产品一比让我不禁唏嘘——这么一个小小的工业品进步，仿佛远超这些年半导体的发展。

这段时间看了不少键圈的视频，感觉最近一年的卷，也变慢了下来。各种信息的同步完成，也让我对各种新产品不再有新鲜感，但依旧还在不断地补充这几年错失的各种健圈有关的信息，也在不断地尝试各种没有试过的轴体，找些新鲜感：

可能这还是出于一个键盘重度用户的天生的好奇心。

兴趣使然。如若真是如此，吾心甚慰。

入坑机械键盘

对于整天敲着键盘混口饭吃的人来说，键盘的重要性比想象的要更为重要。5年前，这个领域还远不如现在这么活跃，但在过去的2015年则成了名副其实的机械键盘之年。然后我也是在去年正式入坑，赶上了这趟坑爹的流行列车。 不管怎么说，机械键盘还是很贵的，所以在没有尝试的情况下我也不会断然下手。第一次试的是同事的不知名国产品牌青轴，一上手就让我想起来自己初中时代奔腾2代那会的电脑打字课！不得不说人身体的记忆真的远强过头脑，就好象学会了骑自行车，50年不骑依然可以骑的很顺畅一样。当下就决定要买买买了。 然后第一把买了把国产青轴，策略和我买单反差不多，跳过中端，要么残副最低档配定焦，要么就上全副。策略其实还可…

葵中剑Sword Wang

只有这时候，才能从劳务的异化中解放出来，开始茫然，开始思考，和苦笑。不知道该干些什么，就又开始自顾自地整理起东西。也许是希望从这一步步的井然有序里找寻自我肯定线索，但也可能只是沉醉于这规律里的安定感，总之看着这些年满屋日渐增多的无用之物，内心深处又涌起一股断舍离的冲动。

只不过，折腾几天下来也没能扔掉多少东西。而更是像自己整理代码一样，陷入想要完成A但需要先完成BCD...的循环里。

我有一个癖好，扔掉什么之前，会拆开，并尽可能保留这件物品拆下的螺丝。可能自己总想着要留下些什么，就如同这个博客的文字，静静躺在角落里诉说着往昔。今天我拆了一个没用的吸尘器支架，结果内构里居然还有一个颇为精致的铝合金的铸造件——我动摇了，这该死的工业美感.....好吧，放起来，无用之物。

结果无用之物，还是越来越多。

今天下午又和往常一样来到了公司，坐下吃一个特价的汉堡配上便利店3块钱的可乐，隔壁会议室两个大爷正在一边吐槽一边刷洗着隔断的玻璃，中气十足的嗓音显得悠悠敲着键盘的我更加的孤僻。

平静极了，漠然若失，这种状态做什么事都事半功倍，但当我开始工作之前，却也不想浪费这样的静谧时刻——可能也只有这种时刻 ，才能想起写作，想起自己网上的最后的家园。无数词藻如流星般划过我的脑海，只留下欲言又止的踌躇，伴随着汗毛竖起的震颤，这究竟是怎样的一种有感而发？

接下来需要处理上周没能解决的代码问题，以及预先消解下周可能的麻烦。写代码本身其实是一件非常让人愉悦的事，让人头疼的往往只是场景所限的个人状态——琐碎的时间，烦躁的心境。所以周末写写代码本身也可以是种尴尬的消遣，但却也反衬出平日工作的无奈。

唯有遵从本心，才能在纷扰中不至于迷失。回到原点，才有修正错误方向的可能。但愿我还能时常回到这里，并在自言自语中重新固定好自己跳脱的灵魂。

前言

作为 1971 诞生的电子邮件(email)，在当前的互联网环境依然发挥着无可替代的作用。虽然国内使用的相对较少，人们更倾向于使用即时通讯消息，甚至即使倒退十几年，我们对短信的偏好也远胜于邮件，但在国外依旧是主流的信息交互方式，也因此保留了时至今日依旧是主流营销渠道之一的 EDM(Email Direct Marketing，电子邮件营销)。而 EDM 也是甚少与前端有关的邮件术语之一，大概仅仅只是因为邮件含有 HTML 的缘故吧。

基础知识

邮件与网页的不同

没有尝试写过邮件的开发可能误以为邮件和网页并无二致，但实际上邮件作为纯书面的数码载体，仅仅只支持一些最基础的 HTML。当然随着时代的进步，邮件客户端支持的各种特性也在越来越丰富，但就像当年 IE ６给前端留下的伤痕一样，邮件客户端的兼容性问题远比浏览器更为严重。根据接收邮件客户端的不同，不仅对 HTML 的支持度有很大的差距，相同客户端在不同系统平台的表现也是不同的，这就使得兼容性成为编写邮件的沉重负担。

在加上几个历史问题（Gmail 和 Outlook 的几次版本更新），造成了苦涩的结果：传统邮件几乎都由 table 标签编写而成。有一种瞬间回到 20 年前的感觉。不仅是 table，并且还大量使用了过时的 HTML 属性而非 CSS 样式。其目的就是提供最大的兼容性，以适应各种各样的繁多的客户端。

对于从不写邮件的前端而言，邮件只是普通 HTML 的观念是普遍的，且错误的。但反过来，长时间编写邮件，那么另一种错误观念也会比较普遍：邮件只能用 table 标签写。而事实上，邮件的编写是对于兼容客户端范围的一种平衡和取舍，这也是为什么，当我们打开邮件查看源码，会发现 95%以上的邮件由 table 编写，但依然还有像 codepen 这样完全不在乎兼容而使用 div 的例子的原因。

本篇的内容聚焦于传统 table 邮件的编写。

邮件的格式

以 QQ 邮件为例，选择显示邮箱原文，就可以看到邮件的原始代码数据。

Date: Sun, 25 Jul 2021 03:26:55 +0300 (MSK)
From: Codeforces@codeforces.com
To: xxx@xxx.com
Message-ID: <1350159521.634421.1627172815667.JavaMail.Codeforces@codeforces.com>
Subject: Codeforces Global Round 15 (Rated for Everybody, 50 Prize
 T-Shirts!)
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_634420_1282013202.1627172815667"

------=_Part_634420_1282013202.1627172815667
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



Attention! The round starts on Sunday, July, 25, 2021 14:35 (UTC).  Hello, =
iifksp.

Thanks XTX Markets, we are holding Codeforces Global Rounds.
.......

------=_Part_634420_1282013202.1627172815667
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<div style="float:right; margin:0 1em 1em 1em; text-align:center;max-width:50%;">
.......

邮件原文比较简单，主要的字段就是：发送方 from，收件人 to，标题 subject，纯文本内容 plain text，以及 html 内容。邮件通常需提供两份内容，一份为纯文本，另一份为 HTML。不同的邮件客户端会根据自己支持的情况，来展示相应的内容。这里的基础的纯文本在邮件的前部，是因为不希望给老旧客户端带来解析的压力。这点就能看出，邮件在兼容方面的思虑远高于特性支持。

实际使用中，我们看到很多技术类邮件都只有纯文本，即便现在几乎找不出人们常用的不支持 HTML 的邮件客户端，但作为基础信息传递的纯文本信息仍无处不在。而很多营销类邮件则反之，只提供了 HTML 的版本。

即便提供了 HTML 的版本，纯文本的部分也并非毫无用处，纯文本常被用来提取摘要信息，并且几乎所有的最佳实践都会提到，不含纯文本的邮件更容易进垃圾箱。

在 QQ 邮箱中，当选择使用 HTML 代码模式，贴入我们写好的 HTML 代码，那么发送的时候，系统会抽取其中的文本内容作为邮件的纯文本部分。但是，如果是我们自己通过代码创建发送管道，入参通常只有 HTML，发出去的邮件也仅只有 HTML。

关于更多格式细节，可以参看相关 RFC：

• The Content-Type Header Field
• The Content-Transfer-Encoding Header Field

数据追踪

邮件由于不能运行 js，所以所有的追踪都要依赖于链接跳转和图片加载。通过外联图片向服务器发起请求并携带参数。通过中转链接记录用户点击链接的行为。

在真实场景中，往往中转重定向存在好几层，这是需要警惕的问题。重定向过多不仅使得打开速度缓慢，更极大的加大了邮件的代码量。会遇到各种无法解决的问题，比如之后会提到的 Gmail 的尺寸限制。

编写指南

国内最早的邮件编写指南在我的印象里，应该是出自阿里的口碑网 UED 之手。约 12 年前那个还没有被之后雪藏而今又再拿出来的口碑网。我在 2011 年前后写的一些文章有很大部分受教于口碑 UED 的博文，不过不久口碑解散(虽然现在又复活)，文章在网上也未存任何痕迹。

后来因为工作关系又和邮件有了些交集，遇到最搞笑的是其他部门的人找了些网上的资料发给我看让我写个邮件，结果还是自己的文章，真就是自己教自己写邮件...可见，国内圈子之狭小，以及邮件相关文章之匮乏。

下面就循序渐进，讨论一些常用的和好用的邮件编写技巧。由于这部分过于琐碎，组织和编写需要拉长时间，发布本文后还会有持续的更新和整理。

特性支持

首先需要了解的是当前邮件客户端对 HTML 特性的普遍的支持情况。大体的情况可以查阅 caniuse.email 这个开源项目的总结，可以对特性支持有一个大概的印象。

背景图可以单独拿出来说一下，参看 邮件客户端背景图支持列表，这是由 emailonacid 总结的比较全的表格，涵盖了 100 种邮件客户端的背景支持情况。这么完整的表格恐怕也只有这类专业的邮件业务公司才能做出来，且更新日期也已经是 2 年以前。

明确所编写的邮件的支持范围是一个非常重要的步骤。当然对于商业邮件，总希望能支持最多的客户端。这里最为重要的一个矛盾就出在“背景图”上。简要摘录一下 Outlook 的背景图支持：

虽然 Outlook，在 MacOS 上大部分版本支持背景图，但 Outlook Windows 直到 2019 版本都不支持，这令人大跌眼镜。所以通常的邮件编写，是不能有背景图的，除非考虑放弃一些客户端。像 Outlook 这种，在用户层可能使用并不多，但在老板和同事层却广为使用，给邮件编写造成了不小的麻烦。

编写基础

大部分情况下，我们都遵循现有 HTML 的编写法则，然后大刀阔斧地做出这些限制：

• 几乎由 table 标签搭建
• 样式全部为行内样式()，且视邮件客户端能力，很多行内样式也是不支持的
• 没有绝对定位，浮动等 web 常见排版
• 没有任何 JavaScript 功能
• 大量的旧有属性和早期私有属性的使用
• 低效的调试速度

然后再加上一些基础原则(已针对当前客户端情况做了删减)：

• 使用 td 作为内容的容器，少添加 p，div 等元素
• 在 td 上使用样式，而不是在 table 或 tr 上
• 如果有旧 html 属性和 css 样式作用相同，可以一起加上，比如 对于 img 标签 border="0" 和 style="border:0;"都可以加上
• 可以使用背景图，但只能渐进使用，纯色背景作为保底。所以不能在背景图中含有重要信息和暗示
• 图片指定宽高属性和 alt，因为邮件客户端很可能拦截图片，此时如果没有宽高和 alt，邮件本身将会错位
• 行内样式里，如果指定字体，则每一处叶子节点的 td 标签都需要指定
• line-height 只作用于文字。如作用于图片将使图片拼接存在间隙
• 间距高度最好用实体的 td 标签的高撑起来，不要使用垂直 margin 值

对大部分前端来说，这就好比用惯了 ES6，然后现在让他只用 ES5 一样难受，然后惊呼，怎么还会有这么古老的东西！

邮件的套路结构是 table 套 table，最常见到的结构套路就是一个 table 单元，并逐级嵌套：

<table align="center" width="100%" cellPadding="0" cellSpacing="0">
  <tr>
    <td>内容货继续套table</td>
    <td>内容货继续套table</td>
  </tr>
</table>

布局与响应式

由于邮件的宽度通常为 600 或者 640，加上技术限制，布局其实无外乎 2 列和 3 列两种。但再锁死了样式后，我们要么使用 table 的多列得到 2 列或者 3 列：

<table align="center" width="100%" cellPadding="0" cellSpacing="0">
  <tr>
    <td>第一列</td>
    <td>第二列</td>
    <td>第三列</td>
  </tr>
</table>

要么使用匪夷所思的古老 align 属性：

<table align="center" width="600" cellPadding="0" cellSpacing="0">
  <tr>
    <td>
      <table class="col" align="left" width="290" cellPadding="0" cellSpacing="0">
        <tr>
          <td>左边</td>
        </tr>
      </table>
      <table class="col" align="right" width="290" cellPadding="0" cellSpacing="0">
        <tr>
          <td>右边</td>
        </tr>
      </table>
    </td>
  </tr>
</table>

这两种方式存在一些差异，主要区别与对响应式的支持，以及间距的控制上。

邮件也可以作响应式。不是指做两块内容，然后通过 CSS 在不同宽度设备里做隐藏展示，而是和 Web 页面一样缩拉宽度和改变布局，但限于结构，只能简单的由多列变成一列。

在客户端支持响应式代码的前提下，比如 iOS 的默认客户端，将响应式代码写道 html 的 header 是有效的。针对上面代码的例子：

@media screen and (max-width: 700px) {
  .col{width: 100% !important;}
}

这会将两个列的宽度强制到 100%宽，使得每一列都独占一行。

而 3 列的响应式就更诡异，虽然向 iOS 的客户端支持响应式，但是如果将三个 td 放大到 100%是没有效果的，有趣的是，虽然对 td 无效，但对 th 有效。所以如果要做一个三列响应到单列的布局，需要像下面这样处理(这也可能随着客户端支持度的提高而变化)：

<table align="center" width="100%" cellPadding="0" cellSpacing="0">
  <tr>
    <th class="col" width="33%">第一列</td>
    <th class="col" width="33%">第二列</td>
    <th class="col" width="33%">第三列</td>
  </tr>
</table>

@media screen and (max-width: 700px) {
  .col{width: 100% !important;}
}

在多数情况下，我都会建议需求方不要做邮件的响应式，而是让客户端直接缩放邮件本体。这种情况下，尽量缩小邮件的宽度会很有帮助，比如 600 就比 640 要合理，缩小后字体不至于太小。

响应式所耗费的测试和编写时间，是非常多的。而在稳定度上取决于编写者的经验，所以未必能加强用户体验。

测试与调试

邮件的测试调试都是相对较为麻烦的，多种客户端，加上多种平台，再加上邮件原文是编码过的，我们只能发邮件然后才能查看最终效果，比浏览器是要麻烦多了。当然邮件的结构相对简单，但如果一个修改需要查看 10 多个客户端效果，也是够累人了，所以经验多一些速度也会快很多。

我们可以通过大部分邮箱服务商提供的代码发送功能测试我们的 html 编写结果。

当然也可以用自己的发送管道发出邮件。比如 Nodejs 可以用 Nodemailer 来构建并发送测试邮件。在其构造方法里也清晰的展现了邮件信息的几个要素：

let info = await transporter.sendMail({
    from: '"Fred Foo 👻" <foo@example.com>', // sender address
    to: "bar@example.com, baz@example.com", // list of receivers
    subject: "Hello ✔", // Subject line
    text: "Hello world?", // plain text body
    html: "<b>Hello world?</b>", // html body
  });

标题摘要空白

如果如先前所说，在发送邮件是仅包含 HTML 内容，那么邮件的摘要部分很可能出现意想不到的内容，比如页头的导航条和 logo。

如果不能补上纯文本，那解决方案就是在 HTML 页头之前再插入一段不可见的摘要内容：

<div style="display: none; font-size: 1px; line-height: 1; max-height: 0; max-width: 0; opactity: 0; overflow: hidden;">纯文本邮件摘要内容</div>

并且为了避免摘要太短而让客户端依旧截取到了正文不希望出现在摘要中的内容，惯例上还会填充这样的空白字符：

 ‌ ‌ ‌ ‌
 ‌ ‌ ‌ ‌
.......

Gmail 102K 问题

Gmail 作为市场占有大户，每个举动都影响深远。Gmail 存在一个最大邮件内容的限制，大小为 102K，这个大小是指邮件原文的内容部分，并不包含外联的图片。超出这个大小的内容，将无法在 Gmail 单屏里完整展示，部分内容会被作截断处理，然后提供访问所有内容的链接跳转————这，无疑会极大的影响邮件的展示效果和点击。

102K 说小也不小，但含有多重重定向数据追踪的链接是非常长的，如果页面充斥链接，或者平铺很多产品，或者嵌套过多层级的标签，都会轻而易举地超过这个界限，最关键的是还没有什么解决方法。如果不想受到截断影响，就只能在邮件原文里优化和平衡。

邮件与 TypeScript

虽然现在绝大部分前端代码推荐使用 TypeScrtipt，但邮件编写还是建议使用 js。并不是用不了，而是当使用 ts 后会出现很多类型缺失的提示，而这些废弃的属性或者写法，则根本没有与之对应的 ts 类型文件。为了拯救开发者颇为值钱的头发，请不要头铁尝试用 ts 写邮件，这是通往地狱的快速通道。

关于网易邮箱

国内不重视邮件，致使像网易邮箱这种占有很大市场份额的客户端，对响应式代码的支持度都非常糟糕，而同样的问题在QQ邮箱中就不存在。比如，网易会非常粗暴地在邮件的media query代码前加上自己的类名 .netease_mail_readhtml 进行样式限制，使得原本设计的响应式失效：

.netease_mail_readhtml .hotel-card-list-responsive-edm{width:100% !important;}
.netease_mail_readhtml @media only screen and (min-width: 640px) {  
    .hotel-card-list-responsive-edm{width:640px !important;}
.netease_mail_readhtml }
.netease_mail_readhtml @media only screen and (max-width: 500px) {  
    .trip-mail-fluid {width: 100% !important;}
.netease_mail_readhtml }

所以如果网易邮箱也是目标客户端之一，那么需要斟酌是否需要做响应式设计，或者做好fallback的预期。

待整理杂项

• naver Web 存在最大宽度居中问题

题外话

我们的邮箱每天都充斥着垃圾邮件，邮件直接触达用户，所以邮件的发送必须受到严格的约束。

大量发送邮件，不仅仅让用户反感，降低营销信息的敏感度，更重要的是失去用户（退订）。

比如，京东的营销邮件频次约为三天一次。私以为是个不错的平衡。

注册B站很久，算是老二次元了。B站创作中心后台会直接显示注册的时长，我大概3700多天吧，10年多，差不多比我开始写博客略短一些。不过一旦上传视频，这个位置就会显示“成为up主的第xx天”，今天，对我来说就是“创作纪念日”。

视频：https://www.bilibili.com/video/BV1xK4y1p7UY/

为什么去年要定一个成为UP主的目标呢？思前想后，一句话：追赶时代的浪潮。

信息的升维已经从单纯的文字，到图文，到现在的广泛的视频传播，对于一个写了超过10年博客的人来说，这种感受是非常没落的。10年刚过，当年大家写的火热的独立博客现在却已所剩无几——有各种各样的因素，但大人，时代变了。并没有打算在视频上有所建树，甚至知道发的视频没人看，但我深以为，必须亲身去经历一番才好。从拍摄，灯光，视频处理，剪辑，发布，到互动，并了解整个运作，就像当年自己希望体验一下独立博客的过程一样。

而这次的过程，也确实受益匪浅。仿佛解锁了上帝视角，能看到更多幕后的东西。以前看视频是万万不会同时想着镜头啦，光线啦，都在什么位置，有什么人在幕后录制，片段间的衔接怎么处理的，等等。然而，才刚刚耗费精力自己从头开始创作一个视频，回过头再去看别人的视频，这些原本看不到的幕后已经自动的出现在了脑海里。对这个结果我已经很满意。

作为一个入门新手，经验匮乏是最严重的问题，即便在去年就已经有了些基本构想，但真正付诸实践还是遇到了很多麻烦。只是尝试，所以用手机做录像设备，但过程坎坷，好多素材在幕后那是真的录了好几遍......上手还因为进入录制阶段的僵硬表现回炉了n次，看似流畅的制作过程，其实因为各种问题，是各种过程段落拼接起来的。

视频剪辑的过程是最为顺利的，上手的用的是达芬奇，因为有一些PR的底子，边学边剪边调整，基本没什么磕碰。但即便如此，3分钟的视频我也是剪了快2个小时，主要软件刚上手，对这个速度自己还比较满意。

做完后，我用三台自己不同时期的电脑来渲染同一个工程，软件都是达芬奇17beta1，结果：

• Intel Xeon E3-1230 v2 + 32G DDR3 + GTX 660 Ti，成绩 7分15秒
• AMD Ryzen R5 2600 + 32G DDR4 + GTX1066，成绩 1分14秒
• Apple M1 Macbook Air 16G，成绩 24秒

这差距实在是很大。所以即使老Xeon在日常使用中依旧很强，但做这种视频剪辑的活还是力不从心的。然而，我整个过程其实都是在这台老Xeon上做的，这台8年前的电脑，在实时预览和剪辑1080p的时候都会卡卡的，只有这种时候，才能感受到时代的无情。

M1确实还是强，但笔记本屏幕太小，外接的话又觉得麻烦。所以自己亲身体验了并作出了选择：老机器+大屏幕 和 强无敌M1+小屏幕，我依然还是选择大屏幕！开机坐下，鼠标键盘双大屏齐备，点开软件就能开始工作的便利——那么，处理过程卡顿，渲染慢这些，毕竟3分钟的轻量工作，都忍了！

截止我写完这篇博文，视频的播放量是3000+，对于这次的初战成绩，给自己满分:)

之后总结了些棱角在团队里做了次分享，本文就是基于分享所摘录的一些内容。

双向文本(bidirectionality, bidi)

混合了两个方向的语言的单一文本块

书写模式构成

• 块朝向，writing-mode, vertical-align?
• 行朝向，direction(RTL, LTR)
• 字形朝向， text-orientation
• 字符序，unicode-bidi

枚举所有书写模式

• 拉丁语系(eg. EN, ES)：块从上到下，行从左到右
• 阿拉伯语系(eg. AR, HE) ：块从上到下，行从右到左
• 汉语系(CN, JP)：同拉丁语系，块从右到左，行从上到下，字符向上
• 古典蒙古语系: 块从右到左，行从上到下

垂直文本

• 中文（为什么是从右往左）
• 日文
• 蒙古语（ 回鹘式 ）

垂直的问题

• 垂直书写 影响的不仅仅是布局，还有排版(比如标点符号需从水平转向垂直)
• 还影响form表单元素，图片，svg节点
• 影响overflow滚动
• 浏览器支持度，目前高度变化后重排

RTL

RTL站点

• 表现形式上，犹如左右镜像一般。
• 右上角是起始位置。所以重要的东西在右上角。

参考站点

• 联合国：局部重写，属性RTL
• AliExpress：Rtl.css 整体样式重写，包含大量的浮动，定位等
• Booking：局部样式重写，样式RTL
• 维基百科：整体样式，属性RTL，因单一页面样式极其固定

样式复写

• 提权类
• dir属性提权
• 伪类

冷知识：css选择器距离无关

提权类

• 无需考虑浏览器支持
• Booking body 相关 class：he lang_is_rtl rtl rtlcss，被用于后续css的复写提权
• 缺点：组件对环境依赖

dir属性提权

由于Html dir 属性设置是推荐做法（dir vs direction）

html[dir=rtl] .box {color: red;}

使用广泛且，对环境依赖较小

由于属性选择器不继承，所以我们需要更独立的方案：

伪类

• dir伪类
  • 完美的RTL样式复写形式
  • 支持性欠佳，仅Moz
  • .box:dir(rtl) { color: red; }
• lang伪类
  • 由于希伯来文几乎甚少在生活中使用，所以大多数站点而言，RTL几乎等同于阿拉伯语
  • .box:lang(ar), .box:lang(he) { color: red; }

RTL支持

少用或不用含有左右描述的绝对定位，浮动，并尽可能使用flex

justify-content: flex-start
text-align: left start

对称美学

CSS Logical Properties and Values Level 1

• W3C Working Draft, 27 August 2018
• 通过提供逻辑属性来控制布局，使编写同时适用于RTL与LTR的样式成为可能
• 例如 margin-inline-start

对于站点来说，隔离左右定位样式并单独提供而不是复写能有效提高效率。

但对于组件粒度来说，还是应该在组件自身内复写样式。

RTL Guidelines: https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/RTL_Guidelines

最后，我偶然翻出了收藏夹里2010年的一篇参考文章：网页 CJK 竖排的最新进展，发现作者也已经更新了文章的内容，这里向这位依旧在更新页面的作者致敬。

基于默认主题简单修改的grayliner一用就是6年，那从wordpress换成ghost还只有半年。这段时间心血来潮打算改一改，于是就有了这个比起grayliner更为简单的pure主题。

在原来的基础上，去掉所有的装饰，多作者模式，虽然外观相较之前没什么大的变动，事实上结构也确实相差无几，但样式几乎是推倒重组了一遍，去掉了相当多没什么用的代码。

去掉了锐利的割裂线，抄了一下Medium的寡淡阴影，去掉了多余的分享和作者页尾，首页放宽了页宽，而内页反而收窄。添上了ghost新版本的一些新的功能性类名，还有删去了看起来十分好看但加载明显延迟的网络字体，将fontawesome撤换成svg图标，重做了一下手机端的导航抽屉...不一而足，却也做了不少改动——这也使得原本计划的施工时间一拖再拖，终于在懒惰中沉沦，交出了一个半成品。

比如本来打算要自己重新绘制几个关键图标，最后则发现好久没画图标巨人提笔无形，最后用了satanor在iconfont上的neko里的三两个图标。本来打算精细计算字体层级，想设计规范一样好好规划一番，最终还是在时间耗尽后，仅仅只是微微调整了各个字号的层级。而这一切，都愈发背离曾经死扣细节的自己，但也并非没有所得，至少在整体性上有了更多的把握。

希望这个新主题，能伴随我的博客继续远行十载——毕竟到了2020年还在写独立博客的人真的不见几个了。或许这种休眠正是需要焕然一新的一个新的开始，而我也将其取名为pure，纯粹，回归初心，坚持前行。

BGM: If You Were Here / by NuwrayN