用 JavaScript 实现 mailto:
这篇讲的是如何用 JavaScript 更灵活地控制 mailto 链接。尽管 mailto 作为 URL 不如从前流行，但它在 Web 应用中依然是触发邮件发送最简单直接的方式之一。文章指出，单纯使用 HTML 标签创建 mailto 链接虽常见，但结合 JavaScript 可以实现更多可能。 作者展示了如何通过一个简单的 JavaScript 函数来动态触发 mailto，这样做的好处之一是，能在一定程度上混淆邮箱地址，对抗自动化收集数据的网络爬虫。更重要的是，这为将邮件发送集成到更复杂的业务逻辑中打开了大门，例如在用户执行特定操作（如点击按钮）时才触发。 文章还深入讲解了如何为 mailto 链接添加参数，比如邮件主题和正文，并给出了一个可复用的 JavaScript 函数示例。这个函数会使用 `encodeURIComponent` 对用户输入进行编码，确保生成的 URL 格式正确且安全。作者也提醒，除了常用的 subject 和 body 参数，浏览器对其他邮件头（如 bcc、cc）的支持程度不一，需要谨慎使用。 总的来说，这篇文章把一个看似简单的技术点讲透了，从基础用法到用 JavaScript 增强的实用技巧，为开发者提供了让 mailto 链接更好服务于特定场景的具体思路。
理解SVG transform坐标变换
这篇讲的是HTML的CSS3 transform和SVG自带transform属性之间的差异，作者用了一个很生动的比喻——“谢霆锋和陈冠希的关系”——来说明两者既相似又复杂的联系。 核心差异在于坐标系统。HTML的transform默认相对于元素自身的中心点变换，而SVG的transform默认基于整个画布的左上角（0,0点）进行。这导致了旋转效果上巨大的不同：一个元素在HTML中可能围绕自身中心优雅地旋转，在SVG中却可能像坐过山车一样绕着画布原点大幅摆动。 作者也指出了SVG transform的一个关键优势：它的`rotate()`函数支持可选的[x, y]参数，允许我们手动指定旋转中心点。这完美解决了SVG坐标系带来的问题，让元素能像HTML中一样围绕自身中心旋转，同时避免了依赖可能在IE中不被支持的CSS `transform-origin`属性。此外，文章还澄清了语法细节，比如SVG transform的值不能带单位。 理解这些差异对于在网页中同时使用HTML和SVG图形至关重要，能帮助开发者精准控制元素的变换行为，避免不必要的渲染困惑。
大搜车前端开发模式：被动编译和主动编译
这篇讲的是大搜车前端团队如何根据业务发展，演进他们的开发构建模式。作者从团队规模扩大、业务复杂度提升的背景出发，坦诚原有“被动编译”模式开始力不从心。 所谓“被动编译”，核心是源码在被浏览器访问时才通过小型服务器（ads）动态编译，实现了零配置、环境统一和高度灵活的动态应用（如在线换肤）。但随着 AngularJS、React 和 ES6 的大规模使用，这种模式难以处理复杂的打包需求。 因此，团队引入了“主动编译”作为补充。他们选用 gulp 作为构建工具，用于处理较重的前端项目，在本地完成打包后再上传。重要的是，这并非颠覆，而是互补：重项目用 gulp 独立构建，普通页面仍沿用简单高效的被动编译。 文章不仅分享了技术选型的思考，也强调了引入新模式时的风险控制，例如统一项目模板、规范插件使用。这为面临类似技术栈演进与团队协作平衡问题的团队，提供了一个务实且可参考的架构调整思路。
写 CSS 时要避免的几个地方
这篇文章是一篇观点鲜明的“避坑指南”，作者从实践经验出发，犀利地指出了四个在编写CSS时常见的、需要避免的坏习惯。 作者开宗明义，认为CSS因其层叠和继承的特殊性，并不适合像JavaScript或HTML那样拆分成多个独立文件，因为样式的声明顺序至关重要。他将过度拆分CSS文件比作“把一块玻璃丢在水泥地板上”。其次，他强烈批评了在Sass中使用深度嵌套，认为这会让本就可能混乱的CSS扩展出第二个维度的混乱，甚至引用了开发者Hugo Giraudel那句著名的“Fucking. Stop. Nesting.”。在单位使用上，他反对使用像素（px）进行布局，尤其是响应式设计中，倡导使用rem/em等相对单位，以便通过调整根字体大小轻松实现整体缩放。最后，他针对“设备断点”的做法提出质疑，认为响应式设计应针对“内容”在何处呈现不佳来设置断点，而非针对苹果、安卓等具体设备的屏幕尺寸。 总体而言，作者旨在提醒开发者：CSS有其独特的运行逻辑，不应简单套用其他语言的组织方式或死板地针对特定设备设计。真正的“响应式”应当服务于内容本身，并尊重用户对字体大小的偏好设置。
秋月何时了，CSS3 border-radius知多少？
作者从万圣节的轻松话题切入，深入探讨了CSS3 `border-radius` 的进阶用法与底层机制。文章首先指出私有前缀已成过去式，随后重点剖析了百分比值的计算基准——它并非相对于 `width`/`height`，而是元素最终的占据尺寸（包含 `border` 和 `padding`）。因此，用 `border-radius: 50%` 可以轻松为正方形元素制作完美圆形头像。 更有趣的是对“大值特性”的对比实验：当给一个非正方形元素设置一个极大的固定值（如300px）和使用50%时，会产生完全不同的视觉效果——前者因半径过大被浏览器限制，形成“操场跑道”式的椭圆角，而后者则是标准的“马桶盖子”状。这揭示了固定值与百分比值在不同场景下的关键差异。 文章后半部分详细拆解了 `border-radius` 简写背后的八个值（水平与垂直半径），并通过交互式Demo直观展示了每个值如何共同控制每个角落的圆弧形状。对于想要超越基础用法、真正掌握CSS圆角机制的前端开发者来说，这篇内容提供了扎实的原理辨析和实用参考。
CSS深入理解vertical-align和line-height的基友关系
这篇技术文章用生动的方式剖析了CSS中vertical-align和line-height这两个属性的内在关联。作者从图片下方常出现的意外空白间隙问题出发，揭示了这一现象的根本原因：图片默认以基线对齐，而基线的位置由行高（line-height）决定，因此间隙实际上是两者共同作用的结果。 文章深入解释了vertical-align的百分比值并非基于字体大小，而是直接相对于line-height计算，这是两者存在紧密联系的核心证据之一。为帮助理解，作者提出了“幽灵空白节点”的概念，即在HTML5声明下，块状元素内部的内联元素行为，仿佛存在一个看不见的空白节点，其高度由line-height撑开，从而影响vertical-align的对齐计算。 基于此原理，文章指出了消除间隙的两种主要思路：一是通过display:block等方式使vertical-align失效；二是直接控制line-height的值。这种从具体问题入手，逐步拆解底层机制的讲解方式，为理解和解决CSS中复杂的垂直对齐问题提供了清晰的思路。
我的npm笔记
这篇文章整理得很实在，作者从日常使用Node.js的经验出发，把npm这个包管理工具的核心用法做了一次清爽的备忘。文章开篇点明了npm作为包管理器的核心功能，随即直面一个国内开发者常遇到的痛点：官方源访问缓慢或不稳定。 针对这个问题，作者给出了多种解决方案，包括临时指定淘宝镜像安装、全局配置国内镜像源、设置Linux别名，以及直接安装cnpm客户端。每种方法都附上了可直接复制的命令，非常实用。 文章的重点是“常用命令”部分，系统性地罗列了从安装、卸载、搜索到发布、配置管理等一系列高频操作命令。这些命令并非枯燥罗列，而是结合了版本指定、全局安装等实际场景，相当于一份简洁的npm速查手册。对于需要在日常开发中快速回顾或查找特定命令的开发者来说，这比冗长的官方文档要友好得多。整篇文章篇幅不长，但覆盖了从环境配置到日常操作的关键环节，读完就能上手。
为什么 IE 不支持（子）域名含有下划线
作者分享了一个让他“永远不会忘记”的调试经历：为什么在IE浏览器中，一旦（子）域名包含下划线，PHP的会话cookie就会完全失效，即使最新的IE11也不例外。 问题的根源追溯到一个2001年的安全补丁（MS01-055）。微软为修补早期漏洞，实施了非常严格的DNS名称校验，要求必须遵循早期的RFC标准（如RFC606/608）。而早期标准并未包含下划线这个字符，因此IE会拒绝设置任何域名部分含有下划线的Cookie。作者指出，微软在此可能混淆了“主机名”与更广义的“域名”概念，因为RFC2181已表明DNS协议本身对标签字符没有限制，但微软的严格校验成为了IE独有的“遗留问题”。 由于这是浏览器端的强制策略，对于开发者而言，唯一的解决方案就是在域名命名中主动避免使用下划线。作者最后抛出了一个观点：在坚持看似“正确”的标准与适应已经普遍接受的实践之间，浏览器厂商该如何选择？
-webkit-border-radius圆角属性
这篇文章聚焦于 CSS 中的 `-webkit-border-radius` 圆角属性，详细拆解了其语法、参数和实际应用中的注意事项。作者从基础语法讲起，说明了属性值可以是单个长度（形成四角相等的圆角），也可以是“水平半径 / 垂直半径”的形式（形成椭圆角）。 文章特别强调了使用的细节和兼容性问题。例如，该属性支持动画；参数取值范围广泛，支持各种长度单位；并且提醒读者注意书写方向（如 `tb-rl`）对参数顺序的影响，在某些浏览器中顺序会反转。此外，作者指出这份参考手册主要针对 `-webkit` 内核浏览器，如果需要兼容其他内核，还需查阅其他资料。 文中还穿插了一个在 Chrome 开发版中遇到的有趣 bug，并附有简单的代码示例，让讲解更具体。整体而言，这是一篇实操性很强的属性指南，为前端开发者提供了清晰的使用参考。
使用yuicompressor.jar实现对js、css文件的代码压缩
这篇文章提供了一套基于 YUI Compressor 的完整前端资源压缩方案。作者从实际需求出发，介绍了如何利用这个基于 Java 开发的 jar 文件，高效地将 JS 和 CSS 文件体积压缩至接近原文件的一半。 文章不仅讲解了基本的命令行用法，更核心的是分享了一个可直接使用的 Java 工具类代码。这个工具类能够递归遍历指定目录，自动识别所有 `.js` 或 `.css` 文件（排除已压缩的 `-min` 文件），并批量生成压缩命令进行处理。使用者只需修改 `yuiPath`、`filePath`、`fileType` 和 `encoding` 四个参数，就能轻松完成整个项目的资源压缩工作。 文末附上了工具的下载地址和具体的参数说明，方便读者即刻上手实践。这是一份从工具介绍到自动化实践，步骤非常清晰的实用指南。
小tip: 了解CSS text-decoration新特性新表现
这篇讲的是CSS里大家用惯了的text-decoration属性，其实远不止下划线、删除线那么简单。作者从常见的链接下划线、商品原价删除线出发，先回顾了CSS2.1时代那些略显“古早”的取值：比如几乎没人用的上划线（overline）和已被浏览器抛弃的闪烁（blink）。 真正的升级来自CSS3。text-decoration不再是一个单打独斗的属性，它演化成了一系列属性。其中，text-decoration-style解锁了虚线、点线、双线、波浪线等新线型；text-decoration-color让我们终于能单独控制装饰线的颜色，告别“线条只能跟文字同色”的时代。 文章尤其探讨了text-decoration-skip这个颇具巧思的属性，它能控制装饰线是直接穿透字符和图片，还是智能地“跳过”它们（如ink模式）。尽管目前浏览器支持度有限，但作者也指出了Safari已默认采用了类似ink的行为，并提供了重置方法。文末附有完整的演示代码，能让你直观感受这些新旧特性的表现差异。
JavaScript 中的 相等检测
这篇讲的是 JavaScript 开发者几乎都会遇到的经典困惑：相等比较。作者直接从那个让人抓狂的表格切入，将松散相等（==）和严格相等（===）的各种比较结果，用一张巨幅表格直观地呈现出来，比如 `0 == ""` 居然返回 `true`，而 `NaN == NaN` 却是 `false`。 表格的每一格都是一个具体的“坑”，清晰展示了 JavaScript 在类型转换时那些违反直觉的行为。这不仅仅是知识点的罗列，更像是一份“避坑指南”。文章通过可视化对比，点明了这些差异背后的核心：松散相等会进行隐式类型转换，而严格相等则同时比较值和类型。 对于开发者来说，理解这张表格是写出可靠、可预测代码的基础。它帮助我们在日常编码中快速决策：何时可以利用松散相等的便利，又在何时必须使用严格相等来避免隐蔽的 bug。
React初探
这篇文章讲的是作者对前端框架React的初体验和核心优势分析。React被视为前端领域的一次革新，它通过虚拟DOM和组件化的方式，重新定义了UI的构建逻辑。 作者从Hello World示例出发，展示了React如何通过JSX语法和组件类封装UI。文章重点拆解了React的几大优势：虚拟DOM通过内存中的DOM diff算法，大幅提升了性能，避免了直接操作真实DOM的高昂代价；组件化开发则鼓励将UI拆解为独立、可复用的模块，让代码结构更清晰。此外，React作为View层库，还兼顾了前后端统一和SEO友好，能兼容到IE8。 当然，作者也客观指出了React在初期存在基础包体积较大、与传统开发习惯有差异等挑战。整体来看，这篇初探为想了解React为何快速流行、其设计哲学与传统方式有何不同的开发者，提供了一个清晰的入门视角。
CSS3 transform对普通元素的N多渲染影响
这篇讲的是CSS3 transform如何在“表面无恙”的情况下，给普通元素带来一系列深远的渲染影响。作者从几个经典场景出发，演示了transform会如何悄无声息地改变元素的行为规则。 例如，给元素添加`transform: scale(1)`这样看似无意义的属性，却能让它像设置了`position: relative`一样，提升垂直地位并覆盖后面的兄弟元素。它还能“降服”`position: fixed`，使其固定定位效果在包含`transform`的父容器中失效，降级为`absolute`。此外，transform也会影响`overflow`对绝对定位元素的裁剪规则，以及改变`width: 100%`的计算基准。 文章通过清晰的示例和代码，揭示了这些容易被忽视的特性及其在不同浏览器下的细微差异，对前端开发者排查布局陷阱非常有实用价值。
javascript双向数据绑定
这篇技术文章深入浅出地讲解了JavaScript中的双向数据绑定。作者以AngularJS中的经典特性为引，指出其核心优势在于视图与数据模型的自动同步，免去了繁琐的手动DOM操作，但也客观说明了其局限性，比如在游戏或图形编辑器这类高频复杂交互场景中并不适用。 文章的重点在于剖析实现原理，将其拆解为“识别绑定、监视变化、传播变化”三步，并展示了两种落地方式。一种是基于jQuery的简洁实现，利用了其成熟的事件订阅发布能力；另一种则是原生的JavaScript实现，通过构建一个发布者-订阅者模式的数据绑定器，巧妙地将DOM事件监听与模型更新连接起来，代码逻辑清晰且具有启发性。 文末，作者还对比了观察者模式与Angular内部采用的“脏读”机制，指出前者实时高效，后者则在特定事件触发后批量检查，性能开销不同。这种从概念到实践，再到不同方案取舍的梳理，帮助读者不仅理解“是什么”，更看清了“如何选”和“为什么”。
javascript依赖注入
这篇讲的是如何在JavaScript中实现依赖注入。作者从控制反转（IoC）这个面向对象的核心法则入手，解释了依赖注入（DI）作为其流行实现方式的价值——它能让复杂程序模块化，便于测试与维护。 文章的目标很明确：如何设计一个“注入器”（injector）模块，让函数能自动获得所需的依赖，而无需硬编码或每次手动传递参数。作者首先实现了一个模仿RequireJS/AMD风格的方案，通过显式声明依赖数组来解析注入，但这需要开发者重复书写依赖项。 更精彩的部分在于第二种方案：利用JavaScript的反射能力，直接解析函数源代码中的参数名，从而自动匹配并注入对应的依赖。这借鉴了AngularJS的思路，让使用语法更简洁，也更“魔法”。然而，作者也指出了这种反射方法的阿喀琉斯之踵：代码压缩会改变参数名，导致依赖映射失败。 最终，文章通过对比这两种实现（显式声明与反射）的优劣，探讨了如何平衡开发便利性与生产环境的健壮性。它不仅给出了一个可复用的injector模块实现，更清晰地展示了在JavaScript中实现依赖注入的核心思路与现实挑战。
正则表达式基础
这篇讲的是JavaScript正则表达式的入门指南。作者从自己阅读Underscore源码时频繁“踩坑”的经历出发，坦言曾因畏难而回避正则，但最终发现理解核心思想后，配合实践就能掌握。文章系统梳理了正则表达式的核心概念。 从最基础的元字符及其转义讲起，作者逐步介绍了特殊字符、字符类（包括简单类、负向类、范围类、组合类与预定义类如\d、\w）、量词（覆盖了?、*、+以及{n,m}等简单量词，并清晰区分了贪婪与非贪婪模式的行为差异），最后讲解了使用小括号()进行分组的技巧，允许对多个字符进行整体匹配或捕获。文章穿插了丰富的JavaScript代码示例与测试结果，力求直观。 作者还推荐了一款可视化工具帮助理解正则。整篇文章的落脚点在于：正则表达式并非想象中那般艰难，关键在于厘清概念、多加思考与实践。
HTML页面布局基础
这篇讲的是CSS布局中两个最基础也最容易踩坑的概念：盒子模型和定位。作者坦言，虽然大家都知道这些知识，但实际开发中总会在细节上翻车。 文章首先拆解了盒子模型。标准盒子模型中，元素宽度仅指内容区；而怪异模式（IE盒子模型）下，宽度则包含了内边距和边框。CSS3通过`border-sizing`属性让你可以自由切换：默认是`content-box`（标准），设为`border-box`则进入怪异模式。作者附上了直观的代码和效果对比图，清晰展示了两种模式下实际渲染尺寸的差异。 定位部分则聚焦于`position`属性。重点区分了相对定位和绝对定位：相对定位元素会“赖在”原文档流位置不走，只是视觉上偏移；绝对定位则彻底“脱离队伍”，其位置由最近的非`static`祖先决定。文章通过代码示例和截图，演示了普通流、相对定位与绝对定位下元素布局的动态变化，特别是绝对定位如何通过`z-index`控制层叠顺序。 整体来看，这是一篇针对前端开发者常犯细节错误的实用回顾，用对比的方式把基础概念讲透了。
JavaScript中真正的哈希映射（译）
这篇讲的是JavaScript中如何创建真正的哈希映射。作者从日常使用对象字面量存储键值对的隐患出发，指出问题的根源在于对象默认继承自Object原型，导致`in`操作符等检查会污染原型链上的属性（比如`toString`），造成键值判断失误。即使尝试用`hasOwnProperty`方法，也可能因键名冲突而失效。 文章的核心解决方案是利用ES5引入的`Object.create(null)`来创建一个没有任何原型的“空对象”。这种对象彻底摆脱了原型链包袱，`in`操作符能可靠地只检查自身属性，`for...in`循环也不再需要过滤。同时，它依然支持常规的对象操作，如属性访问和JSON序列化。 简单来说，作者提供了一个清晰实用的思路：用`Object.create(null)`替代普通对象字面量，就能获得一个干净、安全的键值存储结构，避免一系列隐蔽的陷阱。对于更复杂的需求，文章也提到了ES6标准中的`Map`和`Set`。
iframe大小自适应
这篇讲的是如何实现iframe高度自适应，起因竟然是一个前端面试题。作者坦诚自己最初也对iframe有“性能差、不友好”的偏见，但深入研究后发现它在嵌入第三方内容时不可或缺。 文章的核心是针对两种场景给出了解决方案。在同域下，方法很直接：JavaScript可以直接访问iframe内部DOM，获取其滚动高度和宽度，然后设置给外层iframe标签，轻松实现自适应。但更挑战的是跨域场景，由于同源策略限制，父页面无法直接操作iframe内容。 为此，作者巧妙地利用了一个“代理页面”作为桥梁。在跨域的iframe内部，通过一个隐藏的iframe将页面尺寸信息编码到location.hash中，传递给这个代理页面。由于代理页面与父页面同源，它就能安全地读取这些信息，并反过来设置父页面中iframe的大小。这个方法虽然步骤多一些，但思路清晰，有效绕过了安全限制。 作者还特别提醒了开发测试时需要用本地服务器，避免浏览器直接访问文件导致的权限问题。文章最后附上了完整的Node.js测试代码和参考文献，方便读者动手实践和深入研究。
