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

只不过，折腾几天下来也没能扔掉多少东西。而更是像自己整理代码一样，陷入想要完成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：

数据追踪

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

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

编写指南

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

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

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

特性支持

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

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

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

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

编写基础

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

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

对大部分前端来说，这就好比用惯了 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的预期。

待整理杂项

题外话

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

双向文本(bidirectionality, bidi)

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

书写模式构成

枚举所有书写模式

垂直文本

垂直的问题

RTL

RTL站点

参考站点

样式复写

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

提权类

dir属性提权

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

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

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

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

伪类

RTL支持

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

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

对称美学

CSS Logical Properties and Values Level 1

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

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

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

熟悉宜家的人应该知道，宜家之前有一段时间是没有APP可用的(现在又上架了新APP)。不知出于什么原因，宜家在某个阶段砍掉了APP并选择了web。并且在长期没有线上销售模式的情况下，最终还是在上海第一次推出了线上实验性的渠道，并且新做了上海站的页面——虽然老站点是传统的页面(和新站并存)，但是新上线的上海实验站却是全响应式的设计，除了单格的滑动展示在PC环境显得效率低下，整体效果已经相当可用，甚至在表格响应式方面灵活应用了属性伪元素样式的高级技巧。

不过，实验性的上海站最终有不知出于什么原因下线雪藏了，宜家线上购买功能被搬进了它的老站点，从此又开始了好几年的PC端与H5端分离的状态。时隔多年，又又又不知啥原因，近期的老站点彻底改版成了响应式页面，这让我突然有些激动——因为我一度以为多年前上海站的尝试是一次失败的范例，而就现在来看，可能当时的环境因素(浏览器等)，数据因素(当时新老站点数据差距还是非常大的)等等，都或多或少的影响了站点设计决策。

从简陋APP到重构APP，到下架APP，再到上线响应式线上购物新站点，再到下线响应式站点并将购物功能做进旧系统页面，最后来到当前，将旧系统页面彻底改版成了响应式，并又重新上架了新APP，宜家的这一连串动作着实有些匪夷所思。就目前来说还不能断定响应式是否适合宜家，但宜家全球站点统一更换了设计从某种角度讲，很可能还是要依靠曾经的上海站点数据效果。

如今全球范围内的疫情影响，而几年前已经布局了线上渠道的宜家这次也只能继续加码，甚至可以说正是因为之前线上销售的尝试，缓解了这次疫情冲击。而这样敏感的节点上更新页面设计毫无疑问，体现了一种自信和破釜沉舟的信念。所以反过来再来看当年的上海站，也许是一次成功的数据积累。

我和响应式有着相当深的缘分，当时负责的项目在同时要兼容IE７的情况下全站点达到全平台响应，而前端页面的时间仅为１周多点。那之后也写了一些响应式相关博文，并看着各种平台的页面设计在传统和响应式之间来回摇摆，很多年过去了，我还是坚信响应式的价值，坚信单一页面容量的持续缩减和轻量化。

如今，宜家再度做出了响应式站点，将一个我曾经认为的失败案例拉了回来，着实有些感慨。而不管之后宜家再做出什么骚操作，我也会持续关注并尽可能记录下来。毕竟，也算是宜家半个粉丝了:)

style-loader是webpack的常用插件，作用是将CSS注入进DOM。正因其注入CSS是根据所处运行环境决定，所以如果页面中存在iframe的话，那么就会存在样式注入点与期望不同的情况。由于页面代码可能无法调整执行环境，而样式也无法再不同文档环境相互影响，所以有必要调整注入点。根据情况的不同，运行于父窗口向子iframe注入样式，以及运行于子iframe反过来向父窗口注入，甚至是多层嵌套iframe的情况等都可能遇到(至少我都遇到了)。

在保证同源的大前提下，好在大部分的样式注入库都提供了挂载点变更的配置（比如更早前自己遇到的JSS的修改注入点），甚至是运行时方法，style-loader也不例外，提供了相关配置insert： https://github.com/webpack-contrib/style-loader#insert。由于是所用于打包流程所以也只有配置可用。

module.exports = {
  module: {
    rules: [
      {
        test: /\.css$/i,
        use: [
          {
            loader: 'style-loader',
            options: {
              insert: 'body',
            },
          },
          'css-loader',
        ],
      },
    ],
  },
};

虽然文档并没有展示对insert配置一个function的例子和说明，但insert确实支持`{String|Function}`。既然没有特别说明清楚，那么可以查看一下其源代码确认使用方式，关键代码(insertStyleElement)：

if (typeof options.insert === 'function') {
    options.insert(style);
  } else {
    const target = getTarget(options.insert || 'head');

    if (!target) {
      throw new Error(
        "Couldn't find a style target. This probably means that the value for the 'insert' parameter is invalid."
      );
    }

    target.appendChild(style);
  }

由此可见如果配置了一个function回调，那么运行时就会优先执行方法，并传入已经生成好的style元素，所以，在这个回调里只需要简单的获取到相应的窗体即可。这一配置相当灵活和强大，可以在多层嵌套的iframe里精确指定注入点：

{
  test: /\.css$/i,
  exclude: /src/,
  use: [
    {
      loader: 'style-loader',
      options: {
        insert: function(style) {
          // find iframe document here, parent or children
          var head = window.parent.parent.document.querySelector('head');
          head.appendChild(style);
        },
      }
    },
    'css-loader'
  ]
}

虽然大部分问题已经迎刃而解，遗憾的是，我自己遇到过的诸多问题并没有这么简单的被全部解决。回到之前的各种场景的问题，同窗体如果只是要改变注入点位置，那么指定insert的target就可以了，但如果牵扯到到iframe，那么还会催生出好几种情况需要继续处理。

其一，父窗体往子iframe注入，虽然通过上面代码中的insert回调可以准确注入，但往往遇到注入时子窗体还没有写入DOM，出现在用前端渲染iframe的情况，此时加载代码已经准备注入样式，而iframe却还没有就位。我没能找到非常顺的处理方式，由于自己是在做iframe开发环境时遇到的，所以就变通了一下，将样式注入在一个临时区域中，然后在iframe中通过MutationObserver来将样式的变动同步过来。

其二，insert的配置必须用es5的写法，由于通常并不编译配置文件，而webpack的这个配置是直接将方法打包进运行代码里的，所以会保持代码原样。所以如果写作箭头函数，将会在低版本浏览器遇报错。

其三，与iframe打交道，时刻要注意注入的范围和影响面，通过使用exclude，include等配置，只控制所需的最小样式。

做完这一茬，基本style-loader与iframe的问题就告一段了。在实际项目中，和iframe纠缠在一起的，往往还有react-dom，还有requirejs等等，大部分都牵扯一个挂载点(注入点)问题，解决这些问题需要时刻清晰的意识到代码在哪里运行，到底是哪个window对象。当然为了保住发际线，还是不要和iframe牵扯过多为妙:)