<![CDATA[葵中剑]]>https://swordair.com/https://swordair.com/favicon.png<![CDATA[葵中剑]]>https://swordair.com/Ghost 3.42Fri, 23 Feb 2024 22:32:08 GMT60<![CDATA[葵中剑]]>尽管过年之前连日的阴雨,但好在开年这几日都阳光明媚,使得往日因为烦扰而久未沐浴阳光的自己,也能有闲暇坐在阳台享受片刻的温暖的宁静——仿佛是机械构件反射出来的那一束闪光,那是一种尴尬的奢侈。

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

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

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

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

]]>
https://swordair.com/white-elephant/62aafad075b5773a7ef7ebcbTue, 13 Feb 2024 06:36:43 GMT尽管过年之前连日的阴雨,但好在开年这几日都阳光明媚,使得往日因为烦扰而久未沐浴阳光的自己,也能有闲暇坐在阳台享受片刻的温暖的宁静——仿佛是机械构件反射出来的那一束闪光,那是一种尴尬的奢侈。

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

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

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

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

]]>
<![CDATA[葵中剑]]>原本就没有什么标题,于是就着正在听的NuwrayN的A Certain Truth。就如同长久不说英语一开口脑子里只有空白一般,写作也需要重新找个由头,静下心来慢慢开始一段心血来潮的某种真实。

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

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

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

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

]]>
https://swordair.com/a-certain-truth/654f0f7f230a7604175784fdSat, 11 Nov 2023 06:06:29 GMT原本就没有什么标题,于是就着正在听的NuwrayN的A Certain Truth。就如同长久不说英语一开口脑子里只有空白一般,写作也需要重新找个由头,静下心来慢慢开始一段心血来潮的某种真实。

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

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

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

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

]]>
<![CDATA[葵中剑]]>今天是休假日,早上阿里云打来了催促迁移的电话唤起了昏昏沉沉的我,才让我想起打开自己的博客看上一眼,结果整个2022年博文数为零,开博13年这种情况还是首次,着实感觉尴尬和感慨。挣扎着打开了电脑,虽然脑袋空空,但还是决定留下些什么,而开始倔强地敲起了键盘。

换做以往,不在时光中留下些什么内心必会感受到惶恐和焦躁,但自从成为UP主以来,几乎所有的闲暇都被视频制作吞噬,痕迹不再以文字或者图像而是升维成了视频的形式留存。而这两年也逐渐积累了1.5万的粉丝,有了坚持下去的正反馈,于是荒废了写作和思绪成文,沦落到2022直接就是一晃而过一般。

疫情3年,2022是最为特殊。上海静默,整整3个月在家办公,再到来的放开管控,身边一个个的阳了,也再一次让让自己清晰地意识到了自己的后知后觉,买菜也是,买药也是。疫情之下的人,就像今夏40+度酷热下,阳台上的多肉,有熬过去的,也有枯萎逝去的。然而时间缓缓流逝,唯观测者为之感慨耳。

这一年感受最多的一句话:机会是留给有准备的人的。有枯有荣,即便再狭小,也还是有抓住机会蓬勃向上的存在,一如阳台上的这盆“露西娜”石莲花。

只是人常不是不知需要准备,而是不知往何处准备。过去的圣诞和即将到来的元旦,我可能都还是在一如往常地做着木工雕刻,有时竟也有些分不清是自己喜欢还是为了更新视频。

]]>
https://swordair.com/writing-at-the-end-of-2022/63a91e7c230a7604175783bcMon, 26 Dec 2022 04:52:45 GMT

今天是休假日,早上阿里云打来了催促迁移的电话唤起了昏昏沉沉的我,才让我想起打开自己的博客看上一眼,结果整个2022年博文数为零,开博13年这种情况还是首次,着实感觉尴尬和感慨。挣扎着打开了电脑,虽然脑袋空空,但还是决定留下些什么,而开始倔强地敲起了键盘。

写在2022年的终末

换做以往,不在时光中留下些什么内心必会感受到惶恐和焦躁,但自从成为UP主以来,几乎所有的闲暇都被视频制作吞噬,痕迹不再以文字或者图像而是升维成了视频的形式留存。而这两年也逐渐积累了1.5万的粉丝,有了坚持下去的正反馈,于是荒废了写作和思绪成文,沦落到2022直接就是一晃而过一般。

疫情3年,2022是最为特殊。上海静默,整整3个月在家办公,再到来的放开管控,身边一个个的阳了,也再一次让让自己清晰地意识到了自己的后知后觉,买菜也是,买药也是。疫情之下的人,就像今夏40+度酷热下,阳台上的多肉,有熬过去的,也有枯萎逝去的。然而时间缓缓流逝,唯观测者为之感慨耳。

写在2022年的终末

这一年感受最多的一句话:机会是留给有准备的人的。有枯有荣,即便再狭小,也还是有抓住机会蓬勃向上的存在,一如阳台上的这盆“露西娜”石莲花。

写在2022年的终末

只是人常不是不知需要准备,而是不知往何处准备。过去的圣诞和即将到来的元旦,我可能都还是在一如往常地做着木工雕刻,有时竟也有些分不清是自己喜欢还是为了更新视频。昨夜2点拿出了AKG K701独自跟随着音符游荡,一曲YANNI的《If I Could Tell You》感触最是幽深,而立不立,不知近于不惑而复回首今夕,此间所行所思,有否惑之?

匆忙之间,慢下来,停下来,写写东西,整整思绪,果真算是一件美事。

]]>
<![CDATA[葵中剑]]>关于iPad mini的文章,上一篇还是在8年多以前的 iPad mini 简评,不得不让人感叹时间流逝。

那时我搭配初代mini使用的还是一部机龄10年的诺基亚6230i。后来很多年以后,那台初代mini因为实在跑不动应用,最后二手出掉,之后几年我一直都很想买mini新款,只是最终还是先买了当年牙膏挤爆的iPad Pro 2018。不过mini一直都是我心目中最好的移动电子阅读设备。

9月的苹果发布会上,iPad mini6居然就这么轻描淡写地发布了!

iPad Pro一样的外观设计,type c,磁吸Apple Pencil 2,293克,A15!没有高刷意料之中,只有Pro有高刷mini不可能配备,一切看起来都那么的完美,除了价格!3799RMB才64G起步,还没有128G可选,下一档直接4999 256G!该死的库克!

但我等了太久,看了下自己的iPad Pro 2018 64G其实也只用了一半多点,我这种看书看漫画为主的使用方式,看起来64G也足足够用。16号预售当天就果断下单64G,我已经期待着这样一本随身的电子小书太久了。

9月24日当天上午我就拿到了mini6,兴奋的心情一如当年拿到初代mini的时候。兴高采烈地使用了半天,不得不感叹这尺寸真的是太合适了。

]]>
https://swordair.com/ipad-mini-6-and-jelly-effect/61458f5ebba32c02ea64c0b0Mon, 04 Oct 2021 14:37:29 GMT

关于iPad mini的文章,上一篇还是在8年多以前的 iPad mini 简评,不得不让人感叹时间流逝。

那时我搭配初代mini使用的还是一部机龄10年的诺基亚6230i。后来很多年以后,那台初代mini因为实在跑不动应用,最后二手出掉,之后几年我一直都很想买mini新款,只是最终还是先买了当年牙膏挤爆的iPad Pro 2018。不过mini一直都是我心目中最好的移动电子阅读设备。

9月的苹果发布会上,iPad mini6居然就这么轻描淡写地发布了!

iPad Pro一样的外观设计,type c,磁吸Apple Pencil 2,293克,A15!没有高刷意料之中,只有Pro有高刷mini不可能配备,一切看起来都那么的完美,除了价格!3799RMB才64G起步,还没有128G可选,下一档直接4999 256G!该死的库克!

但我等了太久,看了下自己的iPad Pro 2018 64G其实也只用了一半多点,我这种看书看漫画为主的使用方式,看起来64G也足足够用。16号预售当天就果断下单64G,我已经期待着这样一本随身的电子小书太久了。

iPad mini6与果冻效应

9月24日当天上午我就拿到了mini6,兴奋的心情一如当年拿到初代mini的时候。兴高采烈地使用了半天,不得不感叹这尺寸真的是太合适了。不到300克的重量,适当的边框握持感,强劲的性能......但问题也随之而来。

对于长期使用iPad Pro并习惯了120Hz刷新率的自己来说,mini 6的60Hz的刷新率还是太低了,这种不适比自己预想的要更为明显。刷新率低导致了2个严重的问题:

  1. 果冻效应
  2. 手写笔的高延迟

特别是第一个果冻效益,当天就已经再网上闹的沸沸扬扬,称之为“果冻屏”。但我试了下自己的Pro发现也有这种现象,只是高刷下不明显,所以并非屏幕问题。回想起自己电脑屏幕竖起来用也有类似的效果,加上查看了各种资料和评论,得知mini6这次竟将屏幕的刷新方向改为了横向!一个小巧的电子阅读设备,居然推荐横向使用...?

这段时间里,逛B站经常就可以看到各种各样的杂音,比如说“自己的mini6没果冻效应”的,我只能说,只是他们的眼睛不敏感或者滑动方式没能触发而已。这种杂音会导致人们误以为只是自己的设备“有问题”,是品控问题,导致来回换货折腾却不会有期望的结果。对于不适应mini6这种屏幕的情况,建议还是退了直接了当。

另一个可能确实是品控问题的情况是水波纹,但我的机器上没有明显的感知。当我搞清楚所有的mini6都是这样设计的之后,我果断选择了退货——我万万没想到,自己这辈子的第一次的苹果退货,竟然是自己最喜欢的苹果产品。

iPad mini6与果冻效应

这是个硬件设计问题,应该是无解的。后续也很难再设计去修改屏幕的装配位置。mini6小巧竖向的使用场景,较低的刷新率,横向的刷新方式,叠加放大了果冻效应到了一种普通人都能感到的厌烦的程度,且维持当前设计不变的情况下,恐怕唯有高刷可破。

9月28日,EMS的师傅来取走了mini6,他看了看包装,说了句:“又是这个东西”...... 看来退mini6的真的非常非常多。我目送着师傅离开,想了想安卓平板,似乎还真就没有同尺寸的可以替代的产品,有些惆怅,却,也无可奈何。

]]>
<![CDATA[葵中剑]]>此文是我作为团队分享所作。

前言

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

基础知识

邮件与网页的不同

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

在加上几个历史问题(Gmail 和 Outlook 的几次版本更新)

]]>
https://swordair.com/email-front-end-development-guide/60f7df2ebba32c02ea64c05eThu, 23 Sep 2021 09:52:56 GMT此文是我作为团队分享所作。

前言

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

基础知识

邮件与网页的不同

没有尝试写过邮件的开发可能误以为邮件和网页并无二致,但实际上邮件作为纯书面的数码载体,仅仅只支持一些最基础的 HTML。当然随着时代的进步,邮件客户端支持的各种特性也在越来越丰富,但就像当年 IE 6给前端留下的伤痕一样,邮件客户端的兼容性问题远比浏览器更为严重。根据接收邮件客户端的不同,不仅对 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 的背景图支持:

Background="image.png"
Outlook 2003
Outlook 2007
x
Outlook 2010
x
Outlook 2011 (OS X)
Outlook 2013
x
Outlook 2016 macOS
Outlook 2016 (Windows 7)
x
Outlook 2019 (Windows 10)
x

虽然 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>
    

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

    &nbsp;&zwnj;&nbsp;&zwnj;&nbsp;&zwnj;&nbsp;&zwnj;
    &nbsp;&zwnj;&nbsp;&zwnj;&nbsp;&zwnj;&nbsp;&zwnj;
    .......
    

    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 存在最大宽度居中问题
  • 题外话

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

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

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

    ]]>
    <![CDATA[葵中剑]]>今天我给B站投稿了第一个自己的视频,如此便很快的完成了去年给自己订立的目标之一:成为一名UP主。然后就回来博客写一点整个过程的感受,怎么说呢,终于能够非常真切地体会很多UP主鸽鸽的心思了,哈哈哈。

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

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

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

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

    ]]>
    https://swordair.com/become-an-uploader/601648fbbba32c02ea64bee2Sun, 31 Jan 2021 15:45:22 GMT今天我给B站投稿了第一个自己的视频,如此便很快的完成了去年给自己订立的目标之一:成为一名UP主。然后就回来博客写一点整个过程的感受,怎么说呢,终于能够非常真切地体会很多UP主鸽鸽的心思了,哈哈哈。

    注册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+,对于这次的初战成绩,给自己满分:)

    ]]>
    <![CDATA[葵中剑]]>11日那场发布会在凌晨3点,虽然自己是个除了iPad外几乎不买苹果产品的人,但每一次的苹果发布会却从来都不会错过,这次虽然比往常还要晚一小时,但确实迄今为止最期待的一场发布会了——Apple Silicon,苹果转向自研处理器,直到看完发布会,我们才得以知道M1的真名。虽然每次都看,但真正让我掏钱的产品却很少,我一度以为自己看发布会就是为了吐槽苹果。但这次却很不一样,说是历史的一个转折点都不为过,也许许多年以后我们再次回顾,我们才能更深刻地意识到,确实是苹果引领了RSIC的旗帜。

    当年,不论学术界如何偏向RSIC,Intel依旧依靠市场打败了RSIC。高傲如苹果也不得不在市场面前放弃PowerPC,转投Intel。如今M1发布,Mac全面转向ARM,PowerPC算是死的瞑目了。发布会自然是各种牛逼吹上天,一改多年百分之多少的提升说辞,都是几倍几倍的来。我激动地慢慢喝了几口热水,经历历史的转折点需要足够的感知。

    发售当天我就打算掏钱了,上一次这样还是在改款iPad Pro的时候。但毕竟作为一个新物种,我对拿捏配置显得非常没有把握。于是就出现了多次订购又取消的纠结。一开始订的Macbook Pro 16G 512G,但几天后看到国外评测,Air与Pro无性能差距,且10分钟压测也不降频,随即取消订单,换成Air 16G 256G,转念一想还是加硬盘吧,又取消,

    ]]>
    https://swordair.com/apple-m1-macbook-air/5fc24e289acc7011f02e5f76Sat, 05 Dec 2020 05:52:21 GMT

    11日那场发布会在凌晨3点,虽然自己是个除了iPad外几乎不买苹果产品的人,但每一次的苹果发布会却从来都不会错过,这次虽然比往常还要晚一小时,但确实迄今为止最期待的一场发布会了——Apple Silicon,苹果转向自研处理器,直到看完发布会,我们才得以知道M1的真名。虽然每次都看,但真正让我掏钱的产品却很少,我一度以为自己看发布会就是为了吐槽苹果。但这次却很不一样,说是历史的一个转折点都不为过,也许许多年以后我们再次回顾,我们才能更深刻地意识到,确实是苹果引领了RSIC的旗帜。

    当年,不论学术界如何偏向RSIC,Intel依旧依靠市场打败了RSIC。高傲如苹果也不得不在市场面前放弃PowerPC,转投Intel。如今M1发布,Mac全面转向ARM,PowerPC算是死的瞑目了。发布会自然是各种牛逼吹上天,一改多年百分之多少的提升说辞,都是几倍几倍的来。我激动地慢慢喝了几口热水,经历历史的转折点需要足够的感知。

    发售当天我就打算掏钱了,上一次这样还是在改款iPad Pro的时候。但毕竟作为一个新物种,我对拿捏配置显得非常没有把握。于是就出现了多次订购又取消的纠结。一开始订的Macbook Pro 16G 512G,但几天后看到国外评测,Air与Pro无性能差距,且10分钟压测也不降频,随即取消订单,换成Air 16G 256G,转念一想还是加硬盘吧,又取消,最终选了丐版Macbook Air 16G 512G。因为是丐版GPU砍成7核,便宜了300RMB。然后就是漫长的等待,整整3周时间。

    Apple M1 Macbook Air

    等待的时候,一直关注isapplesiliconready,上面会列一些当前M1芯片支持的原生软件。下决定买也是因为前端工具的适配情况比较理想。

    换成Air还是正确的,性能一致的情况下,Air比Pro便宜2000RMB,Air是无风扇的,意味着没有噪音和灰尘,并且Air有实体F1-12键,比华而不实的touch bar强到不知道哪里去了,另外Air也更轻。而损失的只是100nit亮度,约2小时续航。所以写代码选Air更合理。

    12月伊始,终于拿到了机器,就迫不及待捣鼓起来,先是装上了原生的Node 15.3.0,VSCode Exploration和Chrome,快,真的快,原生应用的流畅度用起来非常舒服。但公司项目需要用到低版本node,所以又加上Rosetta2,用Rosetta2启动一个项目,比当前在用的台式2018款iMac 4核i5版要快一倍以上,这还是在Rosetta2下的表现。

    可能和一台老机器比速度有点不公平,事实上也确实如此,启动编译速度还和硬盘内存有很大关系,所以我又换成了家里的R5 2600 32G DDR4 3200 SN750 500G的主机对比,基本拉平了SSD的差距,并且6核12线程的R2600绝对算得上是主流台机的性能,结果:

    1. node原生运行情况下,比对比平台要快一倍。
    2. node原生运行则要比在Rosetta2下运行快28%。

    这样的性能实在让人震惊,看来发布会上的数倍相比于低压处理器的提升确实不是说说的。现在的M1是可以正面刚桌面端CPU的。

    Apple M1 Macbook Air

    这几天使用,这台M1 Air真的让人爱不释手。几乎没有发热,没有噪音,系统极度流畅,跑项目也快了非常多,改进的剪刀脚比蝶式高到不知道到哪里去了,还有令人满意的续航,开盖即用的快速响应,M1 Macbook Air几乎是一台完美的笔记本,或者说接近随身笔记本的完美形态。当然,也并不完美。目前的软件生态还有问题,前端关键应用还差一个docker。接口太少,外接显示器太少,模具太旧,屏幕大黑边,前摄只有720p...但这些也确实瑕不掩瑜,至少当前它满足了我对第一代ARM桌面电脑的所有期待。这让人更加期待接下来的M2。

    问题记录:

    1. 外接扩展坞时,容易耗电过快,我在使用中也发现这个情况。使用Type C转DP线时,没有发现明显掉电。
    2. 网上部分用户反映Air放在桌面上不平,按压四角会有晃动。我这台没遇到。
    ]]>
    <![CDATA[葵中剑]]>去年年底的时候,突然收到Web中文兴趣小组的订阅邮件,说的是,W3C发布了CSS书写模式第三版正是推荐标准,支持多种语言的书写模式。于是就去简单读了下 CSS Writing Modes Level 3,以及与之相关的万维网联盟(W3C)为多种国际语言的书写模式夯实基础。除了再一次感受到竖排文本的标准的姗姗来迟,回忆起自己10年前解决竖排文本的各种诡异手段,更多的还是对标准的发布而感到的喜悦——只是这么许多年,对竖排文本的偏爱和执念也仅存之一二。

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

    双向文本(bidirectionality, bidi)

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

    书写模式构成

  • 块朝向,writing-mode, vertical-align?
  • 行朝向,direction(RTL, LTR)
  • 字形朝向, text-orientation
  • 字符序,unicode-bidi
  • 枚举所有书写模式

  • 拉丁语系(eg. EN, ES):块从上到下,行从左到右
  • 阿拉伯语系(eg.
  • ]]>
    https://swordair.com/css-write-mode-and-rtl-site/5f825ba99acc7011f02e5b49Mon, 23 Nov 2020 14:47:04 GMT去年年底的时候,突然收到Web中文兴趣小组的订阅邮件,说的是,W3C发布了CSS书写模式第三版正是推荐标准,支持多种语言的书写模式。于是就去简单读了下 CSS Writing Modes Level 3,以及与之相关的万维网联盟(W3C)为多种国际语言的书写模式夯实基础。除了再一次感受到竖排文本的标准的姗姗来迟,回忆起自己10年前解决竖排文本的各种诡异手段,更多的还是对标准的发布而感到的喜悦——只是这么许多年,对竖排文本的偏爱和执念也仅存之一二。

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

    双向文本(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 竖排的最新进展,发现作者也已经更新了文章的内容,这里向这位依旧在更新页面的作者致敬。

    ]]>
    <![CDATA[葵中剑]]>自小对文具就有特别的偏爱,其中对uedbet手机app下载又有些额外的嗜好。在如今这个越来越不需要用笔的时代里,原本不那么明显的收集愿望反而蠢蠢欲动。除了以前收集了一些外,我几乎是在最近的一个月里把“想要”的uedbet手机app下载都收了一遍,还好烧uedbet手机app下载总体还算是比较勤俭的爱好。但,为什么是uedbet手机app下载,而不是钢笔之类的?可能和童年的印象有关,但即使是如今,我也觉得只有uedbet手机app下载,将绘画和机械的美感完整的体现了出来

    买的大部分是施德楼,派通,百乐,白金,主要也都是金属制。使用上塑料也没有什么不同,自己整个初中用的都是派通的fiesta,稳定性和质量都非常好,坏了的一支都没有,都是掉了的。但机械感还是得金属才能体现出来,特别是近几年书写需求急剧下降,笔厂也不得不开始走小众化道路。

    黄色的那支LAMY自动铅应该是十多年前买的,我依稀记得付完一笔对当时的自己而言是难以想象的巨款后,对一起下电梯的友人心血来潮地笑称:我要画漫画。那以后,我再也没有提起漫画,直到我30岁以后,一颗木头心突然就转向了漫画家的理想,所以睹物思往,难免感慨。还有就是蓝色的925-35全套是在很久以前特价时凑齐的,其它的则基本都是近期买的,感觉一下了却了一件憾事——特别是其中的施德楼925-85。

    年轻的时候,因为925-85很贵没舍得买,等年纪大了,才发现这货居然已经停产多年,只有二手价格更是上了天。好在万能淘宝找到一家在卖全网最后的库存,

    ]]>
    https://swordair.com/automatic-pencil-collection/5fba2d919acc7011f02e5d96Sun, 22 Nov 2020 13:00:08 GMT

    自小对文具就有特别的偏爱,其中对uedbet手机app下载又有些额外的嗜好。在如今这个越来越不需要用笔的时代里,原本不那么明显的收集愿望反而蠢蠢欲动。除了以前收集了一些外,我几乎是在最近的一个月里把“想要”的uedbet手机app下载都收了一遍,还好烧uedbet手机app下载总体还算是比较勤俭的爱好。但,为什么是uedbet手机app下载,而不是钢笔之类的?可能和童年的印象有关,但即使是如今,我也觉得只有uedbet手机app下载,将绘画和机械的美感完整的体现了出来

    uedbet手机app下载和收纳

    买的大部分是施德楼,派通,百乐,白金,主要也都是金属制。使用上塑料也没有什么不同,自己整个初中用的都是派通的fiesta,稳定性和质量都非常好,坏了的一支都没有,都是掉了的。但机械感还是得金属才能体现出来,特别是近几年书写需求急剧下降,笔厂也不得不开始走小众化道路。

    黄色的那支LAMY自动铅应该是十多年前买的,我依稀记得付完一笔对当时的自己而言是难以想象的巨款后,对一起下电梯的友人心血来潮地笑称:我要画漫画。那以后,我再也没有提起漫画,直到我30岁以后,一颗木头心突然就转向了漫画家的理想,所以睹物思往,难免感慨。还有就是蓝色的925-35全套是在很久以前特价时凑齐的,其它的则基本都是近期买的,感觉一下了却了一件憾事——特别是其中的施德楼925-85。

    uedbet手机app下载和收纳

    年轻的时候,因为925-85很贵没舍得买,等年纪大了,才发现这货居然已经停产多年,只有二手价格更是上了天。好在万能淘宝找到一家在卖全网最后的库存,虽然一支要200多,但说实在的已经是极为厚道的价格,就毫不犹豫入了,算是弥补内心的缺憾。当然就笔本身来说,设计是真的机械感十足,稳定性就实在一般般了。

    在一众的金属笔里,百乐的木杆笔真的是有点清新脱俗。加上自己原本就是木头控,这支百乐木杆就成了日常使用最频繁的uedbet手机app下载。虽然很少写字,并且提笔忘字率50%以上,但当真正拿笔写字那种刻在DNA里的酣畅感觉跃然纸上,内心还是充满了愉悦,这就是复古,这就是情怀吧。

    uedbet手机app下载和收纳

    说起笔的手感,那又是一种玄学。这些被精心设计出来的家伙,有的稳定低重心,适合作图,有的轻盈飘逸,适合书写,还有的结构复杂功能虽多感觉拉垮,像个玩具,但却又是机械感充足。对于我们这种收笔人而言,手感反倒是其次了。但终究要给出个高低,手感上我最喜欢的应该是派通的orenznero,也就是PP3003-A。

    当我有了这些笔之后,我的另一个收纳的强迫症就马上发作了。对于喜爱之物,需以理想的方式呈现——必须是整整齐齐。然后我找遍了这种渠道没有一个满足我需求的笔盒/笔袋/笔帘,不得已之下就又开始自找麻烦地准备自己做一个皮质的笔帘。

    uedbet手机app下载和收纳

    于是,拿出自己束之高阁很久的皮具工具,看着锈迹斑斑的菱斩,仿佛又是多年以前手工皮具的记忆复苏一般。技艺生疏,再加上选料和试做,整个制作流程就拖的很长。最终决定用疯马牛皮做帘体,用0.8mm的染色植鞣革来做内套。

    uedbet手机app下载和收纳

    也许还是因为年龄的关系,现在格外偏爱棕色系,无论是线材染料,还是外皮,都喜欢用咖啡色。为了制作这个笔帘,一开始买了好些廉价的皮料,但落差感一旦出现就很难抹平,只好改换更好的材料,最后制作物料被真正使用的部分很都轻易超过了150,总价更是要翻倍,现在想想我们这些个偶尔做做手工的人物料成本是出奇的高,算上人工成本,真是比起买来的这些笔都要昂贵了。

    uedbet手机app下载和收纳

    笔帘的设计很简单,但却很费工时。单边的定线11孔都是不连续的,没有走暗线的情况下,手工缝制只能每缝11孔就要重新穿线和结线,效率是真的低。当我缝完所有计划中的孔位,居然已经换了30次线!体现在时间上就是消耗了整整2个下午,手腕脖子还有点酸,拉线拉得手掌通红,不过倒是乐在其中。

    最终完成了收纳所有uedbet手机app下载的目标,整整齐齐最重要:)

    uedbet手机app下载和收纳

    卷起来,然后该束之高阁的,继续束之高阁。毫无疑问,平时我只使用其中的一支,绘画的时候会再多拿几支出来,对日渐少写字的时代来说,代表着机械与绘图美感的uedbet手机app下载注定成为比想象中更为情怀的模样。

    但毕竟,情怀,可以是廉价的,昂贵的,也可以是无价的。

    ]]>
    <![CDATA[葵中剑]]>秋天悄然而至,萧瑟秋风挽起缕缕思绪。昨天看了B站up主水无月的游戏王视频,突然就怀念起自己青春的种种过往——游戏王,当然是其中一个音符。而趁着最近学了点画的契机,突然就想来画一下游戏王标志性的青眼白龙Blue Eyes。

    在画之前,先是找出了多年来的卡牌回顾了一下。自己初次接触游戏王还是在初一,看着同学拿着卡牌凑一桌玩的火热的场面依旧记忆犹新,以至于后来到了高中还陆陆续续的买了很多卡牌。现在知道当时是没有中文正版的,但盗版卡牌也着实给年少添上了多笔色彩。尽管大学毕业后搬了很多次家,但这些卡牌却一直没有丢弃,直到现在拿出来一一清点,1105张,应该一张都没有少过。

    这些卡面的图像和文字,如同记忆刻蚀一般,每翻开一张,便会唤起朦胧的记忆残片。仿佛是观测着往日和同学面对面对战的场景,“My turn,多落!”,中二气息十足,不怎么感到羞耻,只有怀念的感觉带出淡淡的一抹微笑。

    印象里这么多年,我只画过黑魔导女孩,还不止画了一遍。人气高,画起来也比较简单,青眼白龙就难画好多,这次心血来潮就决定是你了,Blue Eyes!

    由于卡面里的青眼白龙不是很完整,所以在网上找了一张比较完整的展翅站姿。毕竟没有专业的绘画训练,而且又是好多年没有动手画漫画,总还是生疏的紧。好在前段时间刚上了几节素描兴趣课,正好拿画板来描摹一下。感觉素描课还是相当有用的,至少比起自己以前随便乱画,

    ]]>
    https://swordair.com/blue-eyes/5da9deb8813ee30244850e0eSun, 18 Oct 2020 15:38:04 GMT

    秋天悄然而至,萧瑟秋风挽起缕缕思绪。昨天看了B站up主水无月的游戏王视频,突然就怀念起自己青春的种种过往——游戏王,当然是其中一个音符。而趁着最近学了点画的契机,突然就想来画一下游戏王标志性的青眼白龙Blue Eyes。

    在画之前,先是找出了多年来的卡牌回顾了一下。自己初次接触游戏王还是在初一,看着同学拿着卡牌凑一桌玩的火热的场面依旧记忆犹新,以至于后来到了高中还陆陆续续的买了很多卡牌。现在知道当时是没有中文正版的,但盗版卡牌也着实给年少添上了多笔色彩。尽管大学毕业后搬了很多次家,但这些卡牌却一直没有丢弃,直到现在拿出来一一清点,1105张,应该一张都没有少过。

    绘制青眼白龙

    这些卡面的图像和文字,如同记忆刻蚀一般,每翻开一张,便会唤起朦胧的记忆残片。仿佛是观测着往日和同学面对面对战的场景,“My turn,多落!”,中二气息十足,不怎么感到羞耻,只有怀念的感觉带出淡淡的一抹微笑。

    印象里这么多年,我只画过黑魔导女孩,还不止画了一遍。人气高,画起来也比较简单,青眼白龙就难画好多,这次心血来潮就决定是你了,Blue Eyes!

    绘制青眼白龙

    由于卡面里的青眼白龙不是很完整,所以在网上找了一张比较完整的展翅站姿。毕竟没有专业的绘画训练,而且又是好多年没有动手画漫画,总还是生疏的紧。好在前段时间刚上了几节素描兴趣课,正好拿画板来描摹一下。感觉素描课还是相当有用的,至少比起自己以前随便乱画,至少在整体的“形”上面自己都有感觉有明显的进步,不是靠灵光一闪的运气和狂气,而是扎扎实实地运用着比例和轮廓。

    绘制青眼白龙

    线稿还是在桌面上完成的,拿出了好久没用的白金uedbet手机app下载——想起自己买了很多uedbet手机app下载打算画画,却愣是把笔当收藏品一般放盒子一放就是十几年,有点惭愧了。我觉得我从来没有画过这么细致吧,以前画画多半是粗组几笔了事,还是说年纪大了更能沉稳些的关系?

    绘制青眼白龙

    上阴影确实是相对漫长的工序,如果不是因为几节素描课,我想我不会对阴影有自发的正确的理解,这从以前自己的画里就能看出,因为对于不曾学过绘画的普通人来说,那些强行临摹的画幅总不免流露出僵硬。虽然画作本身也是临摹,但在对明暗交接线有了一定认识后,能更为准确的主观地去还原出一些质感。

    绘制青眼白龙

    上完阴影后,感觉还是挺像的吧:)。只是也许因为是太久不画画的缘故,感觉画完后也没有太多实感,仿佛这画不是我画出来的一般。我开始自问自己能画出这画吗,略微思考后给出的答案却是否定的——这因该就是好多年只偶尔画一下而造成的某种违和感吧。

    纵使因为半吊子而造成的缓慢进度,但我依旧真切地体会到了漫画家的辛苦。我们所看过的每一页每一格,可能在我们眼中只是1秒而已,但在漫画家手中可能还要好几小时甚至好几天,漫画创作无疑是一个相当有门槛的辛苦活。而对30岁后理想是成为漫画家的我而言,理想的遥不可及,才是最为真实的生活准则。

    抛开真实,对着理想咆哮,来吧,Blue Eyes!一直中二下去,却又是一种何等的奢求?

    ]]>
    <![CDATA[葵中剑]]>

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

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

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

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

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

    BGM: If

    ]]>
    https://swordair.com/pure-theme/5d9f3c59813ee30244850e0aFri, 09 Oct 2020 14:46:14 GMT

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

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

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

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

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

    BGM: If You Were Here / by NuwrayN

    ]]>
    <![CDATA[葵中剑]]>从去年年底开始,陆陆续续做了些木头的小件,到前段时间为止也已经完成了超过30件了。一方面是因为疫情整天呆在家里,另一方面也是热情上的一鼓作气。仍旧记得20岁后梦想成为一个木匠的,但30岁后梦已经彻底变了——想成为一个漫画家——显然梦想变得越发离谱,所以也就是做做小小木件聊以自慰。

    这期间柜子里也屯了相当多的各种各样的木料,随着和木头打更多的交道,对每种木材的品性也有了很多感想,不同木材之间的区别犹如云泥,而人与人的差距何尝不是如此...

    对于木头的痴迷再加上也确实想尝试一下不同的材料,所以纠结了半天还是去凑齐了世界上最有名的木材,所谓的世界四大名木:

  • 粉红象牙木 160
  • 愈创木 78
  • 檀香紫檀 83
  • 蛇纹木 38
  • 上面标注了6x4x1 cm规格的价格。当然由于不是在一家店里买到,所以价格其实并不能做简单比较,但还是能看出小小一片木头的昂贵。当然粉红象牙木无疑是最贵的,641规格即使在万能的淘宝也几乎很难买到。虽说物以稀为贵,但木种的高低贵贱其实还是木材自身决定的,细腻,沉重,稳定,色泽,等等。当年愈创木大量用于造船,是实用木材,但如今沦落成稀有木材。

    这里说的四大名木指世界范围,所以其中亚洲排的上号的也就只有檀香紫檀(小叶紫檀)了。虽然是公认的四大,但蛇纹木无论是稀有度还是木材本身,我都觉得有些拉跨了。

    ]]>
    https://swordair.com/trivial-talk-about-wood/5eef5f2967c0ed3da98e593fSun, 21 Jun 2020 14:13:31 GMT

    从去年年底开始,陆陆续续做了些木头的小件,到前段时间为止也已经完成了超过30件了。一方面是因为疫情整天呆在家里,另一方面也是热情上的一鼓作气。仍旧记得20岁后梦想成为一个木匠的,但30岁后梦已经彻底变了——想成为一个漫画家——显然梦想变得越发离谱,所以也就是做做小小木件聊以自慰。

    木之碎语

    这期间柜子里也屯了相当多的各种各样的木料,随着和木头打更多的交道,对每种木材的品性也有了很多感想,不同木材之间的区别犹如云泥,而人与人的差距何尝不是如此...

    对于木头的痴迷再加上也确实想尝试一下不同的材料,所以纠结了半天还是去凑齐了世界上最有名的木材,所谓的世界四大名木:

  • 粉红象牙木 160
  • 愈创木 78
  • 檀香紫檀 83
  • 蛇纹木 38
  • 木之碎语

    上面标注了6x4x1 cm规格的价格。当然由于不是在一家店里买到,所以价格其实并不能做简单比较,但还是能看出小小一片木头的昂贵。当然粉红象牙木无疑是最贵的,641规格即使在万能的淘宝也几乎很难买到。虽说物以稀为贵,但木种的高低贵贱其实还是木材自身决定的,细腻,沉重,稳定,色泽,等等。当年愈创木大量用于造船,是实用木材,但如今沦落成稀有木材。

    这里说的四大名木指世界范围,所以其中亚洲排的上号的也就只有檀香紫檀(小叶紫檀)了。虽然是公认的四大,但蛇纹木无论是稀有度还是木材本身,我都觉得有些拉跨了。怎么说呢,蛇纹斑点的原木真的算不上好看,木质虽然坚硬但是油性却不高很容易开裂,嘛,我觉得我不喜欢蛇纹木的一个很大的理由就是自己在做一个蛇纹木戒指的时候,它直接裂开了!然后我也裂开了!

    木之碎语

    所以顶级木材里自己最喜欢的还是粉红象牙和愈创,至于国内吹上天的檀香紫檀,也没觉得有什么特别。论细腻不及粉象,论油性不及愈创,香气也没有什么特色,木材稳定性倒是不错。

    次一级木材里,最喜欢大叶紫檀,很喜欢大叶紫檀的香味,可以之前做戒指也崩了,木质太疏松了。然后紫光檀,绿檀都不错,质地坚硬香味独特。

    木之碎语

    经过了这段时间的爆发,可能要沉寂一段时间了。我把这些小件装进了胡桃木盒里,看着它们静静地躺着,那日夜打磨的记忆便浮现在眼前。毫无疑问,这些木器承载着这小半年的时光荏苒,有它们在,会让我自己也能无端地觉得——

    这段时间,并没有白过。

    BGM: You Are My Only Hope / Painless Destiny

    ]]>
    <![CDATA[葵中剑]]>我这种PC时代的遗留者,总是会不失时机地缅怀过往个人电脑给生命刻下的音符。从自己真正意义上的第一台电脑所配备的罗技G1键鼠套装开始算起来,什么手感握感重量云云,一开口就是个老罗技用户了。

    键鼠可能是陪伴个人最为长久的计算机配件,主机都换了好几代了,但键盘鼠标,特别是鼠标,通常会有长达十年的陪伴。当然,这有个前提就是要会自己更换鼠标微动并无限给它续命。早年G1一直用到修了多次微动(比如之前写的修复罗技G1鼠标的单击变双击问题以及更换鼠标微动),直到大屏更新G1的DPI再也跟不上潮流,才告别了战友。

    之后的很多年,换过罗技的诸多鼠标。自己因为手掌较小所以除了那些块头比较大的型号外,大部分罗技的鼠标都买来用过。可能初代的G1映像过于深刻了吧,后面类G1鼠标用的是最多的:G100,G Pro有线,G304。查了下过往记录,原来一时兴起还写过一片罗技G100s键鼠简评。实际上,电老虎G700,多按键的G300,造型诡异的G303,插值减配G402,首次感受不到延迟的G403无线,第二版RGB的G502都有用过一段时间,仔细一算不下十款了,更别提另外的MX系列了。

    但最终这么多鼠标送人的送人,咸鱼出掉的出掉,真正剩下的,也就只有G502和G304。所以当听说G502要出无线版的时候,真的是很期待的。结果,刚出的时候价格确实有些吓人(

    ]]>
    https://swordair.com/g502-wireless/5eaacc6c2ee3a17cbf21ad22Thu, 30 Apr 2020 14:17:23 GMT

    我这种PC时代的遗留者,总是会不失时机地缅怀过往个人电脑给生命刻下的音符。从自己真正意义上的第一台电脑所配备的罗技G1键鼠套装开始算起来,什么手感握感重量云云,一开口就是个老罗技用户了。

    键鼠可能是陪伴个人最为长久的计算机配件,主机都换了好几代了,但键盘鼠标,特别是鼠标,通常会有长达十年的陪伴。当然,这有个前提就是要会自己更换鼠标微动并无限给它续命。早年G1一直用到修了多次微动(比如之前写的修复罗技G1鼠标的单击变双击问题以及更换鼠标微动),直到大屏更新G1的DPI再也跟不上潮流,才告别了战友。

    之后的很多年,换过罗技的诸多鼠标。自己因为手掌较小所以除了那些块头比较大的型号外,大部分罗技的鼠标都买来用过。可能初代的G1映像过于深刻了吧,后面类G1鼠标用的是最多的:G100,G Pro有线,G304。查了下过往记录,原来一时兴起还写过一片罗技G100s键鼠简评。实际上,电老虎G700,多按键的G300,造型诡异的G303,插值减配G402,首次感受不到延迟的G403无线,第二版RGB的G502都有用过一段时间,仔细一算不下十款了,更别提另外的MX系列了。

    但最终这么多鼠标送人的送人,咸鱼出掉的出掉,真正剩下的,也就只有G502和G304。所以当听说G502要出无线版的时候,真的是很期待的。结果,刚出的时候价格确实有些吓人(),最近价格稳定了些所以就700RMB入了。

    罗技G502无线

    在我看来之前的G502只有两个缺点,有线,以及——过重,习武之人一说可不是随便说说的,G502的全金属滚轮重心靠前,使得甩动鼠标更加笨重。我自己的有线款也是自己更换掉了滚轮(G903的镂空金属滚轮可以直接换上去)才勉强达到舒适的重量。无线版G502在重量上真的做到了惊艳,自带电池的情况下居然比还比原有线版轻的多,部分得益于更轻的外壳,但我觉得无线版直接换用G903同款滚轮贡献最大。

    罗技G502无线

    目前的G502无线版堪称完美,但也多少存在瑕疵。比如续航比其G304来说还是显得太短了,约80小时可能只能用2周吧,但新引擎比起之前使用的G403无线的30个小时来说,进步还是很巨大的。另外我手上这台品控有点问题,左右按键手感不一致,右键非常绵软,和已有老款G502对比差距明显。现在讲究用下,反正微动早晚是要换掉的。

    虽然对在用的304有些不舍,但304按键数量确实有点捉襟见肘了。G502比G304多出来的拇指DPI按键和左键侧边G8和G7,通常被我设置成task view和左右虚拟桌面切换,并且这在Mac和Win10有相同的交互逻辑,所以对于在公司用Mac和在家用Win10的我而言,要无缝就得用相同的鼠标才行。

    罗技G502无线

    虽然微瑕,但就目前的使用感受来讲——我依旧愿意称其为最强。造型,握持感,功能设计,稳定性,在罗技阵营里无出其右。减轻了重量,无延迟感的无线,保留了原来G502所有的功能,堪称是罗技鼠标的集大成者。

    下次换鼠标又会是什么时候呢?也许是10年后吧。从初代G1以来,我感觉G502(有线换轮版和无线)是真正的终点鼠标,重新带来了当时G1带给我的满足感,尽管,我希望它仅仅只是一个里程碑。

    ]]>
    <![CDATA[葵中剑]]>没错,就是那个家具品牌宜家,看似和响应式页面设计毫不相干,但事实上IKEA却在官方站点上做了相当彻底的响应式——近期,宜家官网居然改版了,从之前的老站点换成了现在的全新设计的响应式页面,这不由的让我再次回想起这个从很多年前就一直在争论的问题:响应式真的有用吗?

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

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

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

    ]]>
    https://swordair.com/ikea-and-responsive-web-design/5e9459712ee3a17cbf21ac62Mon, 13 Apr 2020 13:09:48 GMT没错,就是那个家具品牌宜家,看似和响应式页面设计毫不相干,但事实上IKEA却在官方站点上做了相当彻底的响应式——近期,宜家官网居然改版了,从之前的老站点换成了现在的全新设计的响应式页面,这不由的让我再次回想起这个从很多年前就一直在争论的问题:响应式真的有用吗?

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

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

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

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

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

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

    ]]>
    <![CDATA[葵中剑]]>通常情况下其实遇不到style-loader与iframe纠缠的情况,不过由于自己所做项目的特殊性,所以不得不经常与iframe打些交道,并且往往遇到问题能参考的资料也非常有限。

    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}

    ]]>
    https://swordair.com/style-loader-and-iframe-problems/5e7af53b2ee3a17cbf21ab1dMon, 06 Apr 2020 08:25:55 GMT通常情况下其实遇不到style-loader与iframe纠缠的情况,不过由于自己所做项目的特殊性,所以不得不经常与iframe打些交道,并且往往遇到问题能参考的资料也非常有限。

    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牵扯过多为妙:)

    ]]>