很早的某一天，我对 Facebook 聊天行为做了一些研究，当时就觉得它对各方面的处理极具美观，比如聊天框、图片的处理、引用的处理、头像、状态的变化等等。这打破了我对“聊天功能太容易了”的固有想法。正好最近在写一个相关的项目，我决定封装一个聊天展示组件，且专...

我确实对Facebook聊天行为做了一些研究。并且我觉得它对各方面的处理极具美观，比如聊天框、图片的处理、引用的处理、头像、状态的变化等。这打破了我“聊天功能太容易了”的固有想法。

以<input type="search /">为例，在安卓段展示正常，右下角是一个蓝白“搜索图标”。但iOS仍然遵循默认“换行”效果。以至于不少人会这么做：

我们通常会遇到这么一个场景：有几个基本功能一样的组件，但是他们之间又存在着足够的差异。这时候你就来到了一个岔路口：我是把他们“按部就班”地写成不同的组件呢？还是保留为一个“公共组件”，然后通过props传参进行不同功能之间的区分呢？

在笔者开发某个项目时突发奇想：如果实际需要11px的字体大小怎么办？这在Chrome中是实现不了的。关于字体，一开始想到的就是rem等非px单位。但是rem只是为了响应式适配，并不能突破这一限制。

微信小程序中关乎“授权”的，抛开各路“牛鬼蛇神”不谈，大体上也就两种：位置授权用户信息授权切记的是：在微信一直打着的“用户至上”的旗号下，几乎一切用户相关的应用都需要用户手动授权！所以必须要有提示的。位置授权昨天完成了微信小程序项目的最后一点内容，里面...

当然是会渲染，只不过不展示罢了 补充： 1.问题的出发点是 spa 单页面应用的话，可能所谓渲染更多是数据层面的，数据有没有渲染到标签里面去 2.出发点若与 spa 无关，那么的确看表象就知道没有渲染，页面要经过渲染再展示，渲染时忽略 head 头和 display：none