IE10 CSS Hack（顺便聊聊IE11的CSS Hack）
这篇来自CSS88的文章，聚焦于开发者在实际项目中遇到的IE10 CSS兼容性难题。作者从同事反馈页面在IE10（甚至IE9）下出现异常的问题出发，系统梳理了针对IE10的CSS Hack方案。 文章核心介绍了两种实用检测方法：一是利用IE私有的条件编译（@cc_on），结合条件注释，为IE10添加专属的class，从而编写隔离样式；二是通过JavaScript检测`document.documentMode`属性，动态判断IE版本。作者还分享了针对IE11预览版不支持@cc_on这一变化所作出的代码调整思路，体现了方案的延续性。 文末附有不同模式下的效果截图和具体代码示例，为处理类似浏览器兼容性问题提供了清晰、可操作的实用思路。
谈谈 jQuery 中的防冲突（noConflict）机制
这篇讲的是如何优雅解决多 JavaScript 框架混用时对 `$` 符号的争夺问题，核心是解读 jQuery 的 `noConflict` 机制。 当项目同时引入 jQuery 和其他库（如 KISSY、Prototype）时，大家都喜欢用 `$` 作为快捷方式，冲突在所难免。作者从这个实际痛点出发，拆解了 jQuery 的应对之策：它通过 `jQuery.noConflict` 方法，允许开发者主动释放对 `$` 甚至 `jQuery` 对象本身的控制权。 文章深入源码，揭示了其实现上的巧妙之处。jQuery 在加载时会预先将 `window.jQuery` 和 `window.$` 保存在私有变量中。调用 `noConflict` 时，正是通过对比这些备份，决定将控制权“归还”给之前的占有者。那个可选的 `deep` 参数，就决定了是只交出 `$`，还是连同 `jQuery` 本身一并交出。 这种设计不仅适用于框架混用，也为 jQuery 多版本共存提供了解决方案。文章最后还给出了一个非常实用的技巧：通过闭包包裹代码，并传入 `noConflict` 返回的 jQuery 对象，可以在局部安全地恢复 `$` 的用法，让现有插件无缝工作。整个机制体现了 jQuery 在 API 设计上对复杂运行环境的周全考量。
浏览器的渲染原理简介
这篇讲的是浏览器如何把代码变成屏幕上可见页面的全过程。作者从那篇著名的《How Browsers Work》出发，指出其虽好但过于冗长，且对日常工作的直接帮助有限。于是他提炼出了一个更精简、更实用的版本，目标是让读者在通勤或休息的碎片时间里就能读完，并立刻能用上。 文章的核心是梳理浏览器渲染的几大步骤：解析HTML生成DOM树、解析CSS生成规则树，再由这两者构建出用于实际绘制的渲染树。作者特别拆解了DOM与CSS的解析逻辑，并点出CSS匹配的性能关键在于选择器的写法。最后，他重点区分了Reflow（重排）与Repaint（重绘）——前者因几何尺寸变化而成本高昂，在移动端尤其“痛苦”，后者则相对轻量。文章还直观地列出了哪些常见操作会触发高成本的Reflow，为前端性能优化提供了明确依据。 整个叙述直白且紧扣实战，比如缓存DOM样式引用、理解`display:none`与`visibility:hidden`的不同影响等细节，都能帮助开发者更深入地理解页面性能问题的根源。
Js事件监听封装（支持匿名函数）
这篇讲的是JavaScript中一个常见但容易被忽视的痛点：如何优雅地取消事件监听，尤其是当使用匿名函数绑定时。作者从实际开发中“想解绑却拿不到函数引用”的困境出发，提出了一套简洁的封装方案。 核心思路是利用一个哈希表（handleHash）作为事件类型的索引，在绑定时不仅执行原始函数，还将内部包装函数的引用缓存到对应的数组中。这样，即使外部是匿名函数，内部通过 arguments.callee（在非严格模式下）依然能获取其引用并保存下来。解绑时，则遍历该数组，逐个移除监听器。 这个方案的巧妙之处在于，它通过一层轻量的“包装”和“缓存”，完全兼容了 addEventListener 与 attachEvent，同时将匿名函数的“不可见引用”问题巧妙地转化为可管理的内部引用，让开发者可以随意使用匿名函数而无需担心内存泄漏或无法解绑。实际使用时，只需像普通绑定一样调用 bind，在需要时用 unbind 按事件名一键清理即可。
Javascript 装载和执行
这篇讲的是浏览器如何处理JavaScript文件的装载和执行问题。作者从JavaScript两大特性——“载入后立即执行”且“执行时阻塞页面”——出发，通过一系列具体示例，对比了多种解决方案的差异与适用场景。 传统将script标签放在head中会导致页面渲染被完全阻塞。即便使用document.write动态插入，对整个页面来说仍然是同步阻塞的。HTML5的async属性虽允许并行下载，但脚本执行时机不可控；而IE的defer属性能延迟执行且不阻塞DOM渲染，不过浏览器兼容性有限。 作者重点推荐了“动态创建DOM元素”的方式，这已成为异步加载的常用模式。进一步地，为了解决“何时执行”的问题，可以将脚本加载绑定到window.onload或特定交互事件上。文章还探讨了预加载脚本但不立即执行的进阶需求，介绍了利用object或iframe标签进行缓存的变通方法。 最终，作者通过对比演示，清晰地展现了每种方案在执行顺序、阻塞行为和浏览器支持上的权衡，为开发者在实际项目中选择合适的脚本加载策略提供了实用参考。
网站优化 更小的静态资源
这篇文章解决一个实际问题：如何通过压缩构建静态资源来加快网站加载。作者团队发现，更小的JS、CSS和图片文件意味着更少的网络传输时间，因此在构建阶段对它们进行优化至关重要。 核心方案是根据资源类型，选择不同工具进行深度压缩。对于JavaScript，他们对比了UglifyJS、Google Closure Compiler等工具，最终因稳定性考量，采用了Google Closure Compiler；对于CSS，则沿用了熟悉的YUI Compressor；而对于PNG和GIF图片，他们组合使用OptiPNG、AdvPNG和AdvDef三个工具，以实现最大化的压缩率。文章详细解释了每个选择背后的权衡与理由。 为了将这些工具集成到发布流程中，他们编写了一个简版的Bash构建脚本。这个脚本实现了自动化的压缩、复制和输出，避免了人工介入。从脚本执行结果的日志可以看到，多数文件的大小都得到了显著缩减，例如一个近50KB的JS文件被压缩到了约17KB，充分验证了方案的效果。 总的来说，这是一份非常扎实的前端工程化实践记录。它没有停留在工具介绍层面，而是完整展现了从工具选型到构建集成的决策与实现过程，其中对PNG图片“优先选用png8格式，并结合CSS Sprites”的建议，以及具体的脚本实现，对同类项目的优化工作都有直接的参考价值。
开发者调试工具Chrome Workspace
这篇讲的是Chrome开发者工具中一个能直接提升前端调试效率的内置功能：Workspace。 它允许开发者在DevTools里直接修改JS和CSS代码，并且改动会实时、自动地保存回本地文件。这省去了以往“在工具中调试确认效果，再切回编辑器手动同步修改”的重复步骤。过去实现类似自动保存需要依赖第三方工具（如autosave）并手动启动本地服务，现在Chrome正式版已原生支持，流程大大简化。 文章详细说明了启用方法：对于普通Chrome用户，需先在`chrome://flags/`中启用开发者工具实验选项，重启DevTools后在设置的“Experiments”中开启“File system folders in Sources Panel”。出于安全考虑，还需在目标项目根目录下创建一个名为`.allow-devtools-edit`的空文件（文中提供了Windows和Mac的命令行创建方式），然后在Workspace中添加该目录即可开始使用。作者也提醒，若资源通过URL加载，需使用Mappings设置映射，并特别注意路径结尾不要加反斜杠。 最后文章指出，尽管Workspace在调试阶段能有效提效，但其目前并不支持SCSS、LESS等预处理器文件的编辑，这是一个尚待完善的限制。
JavaScript的5种调用函数的方法
这篇讲的是 JavaScript 开发中一个高频踩坑点：函数调用方式如何直接影响 `this` 的指向。作者从自身经历出发，指出许多 bug 的根源在于对函数调用机制理解不深。 文章通过一个简单的 `makeArray` 函数，逐步演示了四种核心调用场景。无论是看似直接的全局调用、作为对象方法调用、使用 `apply`/`call` 显式指定上下文，还是作为构造函数配合 `new` 使用，其返回的 `this` 值都截然不同。例如，直接调用时 `this` 指向全局对象（浏览器中是 `window`），而作为对象方法调用时，`this` 则指向该对象本身。 作者还点明了事件处理中常见的 bug 陷阱：当函数被赋值给 DOM 事件属性后，若再将其作为普通函数调用，`this` 会丢失元素上下文。这也解释了为什么 jQuery 等库需要在内部重新绑定 `this`。 文章最终归纳了几条关键规则，清晰指出了不同调用方式下 `this` 的绑定逻辑。理解这些细微差别，是编写可预测、少 bug 的 JavaScript 代码的重要一步。
HTTP的升级产品：SPDY
这篇讲的是Google推出的SPDY协议如何试图解决传统HTTP协议在现代Web下面临的性能瓶颈。文章从对比出发，清晰地指出HTTP的三大痛点：每个请求需要单独TCP连接导致的低效、服务端无法主动推送内容、以及重复的头部信息造成带宽浪费。 SPDY的核心思路是“增强而非取代HTTP”，它通过在一个TCP连接上实现多路复用，允许并行处理多个请求；引入服务器推送，让服务器能预加载资源；并压缩头部信息，从而大幅减少延迟和带宽消耗。同时，SPDY强制使用SSL加密传输，提升了安全性。文中特别指出，这使得现有服务端应用无需大改，只需增加SPDY传输层即可升级。 对于不同角色，SPDY的价值立竿见影：普通用户感受到更快的加载速度和更高的安全性；前端工程师可以利用请求优先级优化页面渲染；运维人员则能减少服务器连接资源消耗。文章最后也点明了SPDY作为HTTP 2.0重要候选者的背景，其目标就是让整个网络“快”起来。
说说弹窗和新窗口打开拦截
浏览器对非用户主动触发的弹窗和新窗口打开的拦截，常让开发者头疼，尤其在需要与第三方网站交互的场景下。作者从实际产品需求出发，比如传递用户数据、验证流程后跳转，探讨了如何绕过这些限制。核心方案是利用表单提交到新窗口，通过设置target属性为“_blank”，将数据先发送到本站处理页面，处理完毕后再跳转到第三方站点。同时，建议在
如何判断Event事件是否是用户主动执行的
作者从网站模拟用户点击行为的常见做法出发，探讨了如何准确判断一个Event事件是否为用户真实触发的问题。在jQuery层面，可以通过检测`event.originalEvent`是否存在来实现，但这种方法并不完全可靠，因为程序完全可以通过`createEvent()`构造出一个几乎无法区分的模拟事件。 文章的核心发现在于，完全依靠JavaScript代码本身已无法彻底解决这一信任问题。最终的解决方案来自浏览器层面：根据DOM Level 3 Events标准，现代浏览器（如IE9+和Firefox）提供了`isTrusted`属性。该属性由浏览器内核自动设置，对于用户真实操作的事件返回`true`，对于程序合成的事件返回`false`，且开发者无法手动篡改它。 目前，基于WebKit的Chrome浏览器尚未支持此特性，但作者相信这会是未来的标准方向。这篇内容为前端开发者提供了一个从代码模拟局限到浏览器级解决方案的清晰思路，对于需要精确区分用户行为的场景（如安全防护、行为分析）很有参考价值。
现代浏览器中内置的几个可以等效替代jQuery的功能
这篇讲的是现代浏览器如何“内化”了部分jQuery的核心功能，从而为开发者提供更轻量的原生选择。作者从jQuery体积膨胀、对移动端不够友好这一普遍痛点出发，指出在现代浏览器中，完全可以用原生API等效替代许多jQuery特性。 文章具体拆解了三个关键点：一是使用`document.querySelector`和`querySelectorAll`来替代jQuery选择器，作者演示了如何将它们分别映射为`$`和`$$`，并提醒`querySelectorAll`返回的节点列表需要通过`Array.prototype.slice.call`进行转换才更易用；二是利用`classList`对象直接进行CSS类的`add`、`remove`和`contains`操作，这与jQuery的`addClass`、`removeClass`和`hasClass`功能对应。 除了功能替换，作者也坦率指出了局限：原生DOM操作无法实现jQuery的链式调用，且需注意不同浏览器的兼容性差异。文末附上了两种特性在各主流浏览器中的支持情况图表，让读者能快速评估技术选型。整体而言，文章为那些希望减少项目依赖、或进行移动端优化的开发者，提供了一份清晰的“去jQuery化”实用参考。
Javascript中的delete操作符
这篇从JavaScript中一个看似简单的delete操作符切入，但探讨的问题却非常根本：变量和对象属性之间的微妙关系。作者首先指明，要理解delete的行为，必须先理清JavaScript执行引擎在幕后创建的Global对象（浏览器中即window对象）和Activation对象（函数执行上下文）。所有全局和局部变量，本质上都是这些对象的属性。 文章通过一个代码示例生动地说明了这一点：在全局作用域中声明变量 `global` 后，可以通过 `this.global` 访问，这直接证明了变量作为Global对象属性的存在。基于这个核心视角，文章随后便能清晰剖析delete操作符的实质——它针对的是对象的属性，而非传统意义上的“变量声明”。这也解释了为什么delete无法删除通过var声明的变量或函数声明，因为它们被标记为不可配置。 作者从底层对象模型出发，把一个操作符的行为讲得透彻且连贯。这不仅帮读者知其然，更知其所以然，对于深入理解JavaScript的作用域链和执行上下文机制也大有裨益。
项目中对模板和js，css文件进行压缩的处理类
这篇讲的是一个基于PHP的前端资源压缩方案，核心目标是减少HTML模板中的冗余空白字符以及对JS和CSS文件进行专业压缩，从而节省用户流量与服务器带宽。 作者提供了一个具体的PHP处理类，它分两步工作：首先，递归遍历模板源目录，通过`trim`函数去除每个文件行首尾的空格和换行符，再拼接输出，以此实现模板的“瘦身”；其次，它调用外部工具——Google Closure Compiler（用于JS）和YUIcompressor（用于CSS），为对应的文件生成压缩后的`.min.js`和`.min.css`版本。 整个实现的巧妙之处在于自动化。脚本能自动处理整个目录树，无需手动逐个操作，并且内置了`grep -v "min.js"`这样的逻辑来避免对已压缩文件的重复处理。作者也明确指出了所需的环境配置，即把对应的编译器JAR包放在同级目录即可。这是一个简单但实用的前端工程化小工具，尤其适合希望快速集成到部署流程中来实现基础资源优化的开发者。
使用python/casperjs编写终极爬虫-客户端App的抓取
这篇讲的是在JavaScript动态渲染盛行的今天，如何有效抓取那些传统爬虫无能为力的“客户端App”型网页。作者以自动化获取Google Adwords关键词搜索量为实际案例，详细对比了两种实现路径。 文章首先回顾了经典的Selenium WebDriver方案。它像一位稳重的老兵，功能全面，能操控真实浏览器。作者分享了在无图形界面的服务器上配置它的技巧，并演示了如何通过分析页面结构、模拟登录、处理动态等待（如`implicitly_wait`）来一步步完成任务，最后用XPath提取出结果。方案虽可靠，但步骤相对繁琐。 随后，作者转向更现代的JavaScript Headless方案，重点介绍了CasperJS（基于PhantomJS）。这条路子轻快灵活，执行速度可达Selenium的三倍，代码也更直观——可以直接在浏览器控制台逻辑下编写。作者用它演示了几乎相同的功能，但指出CasperJS在进程间通信（IPC）方面存在局限。 最终，文章提供了一个完整的CasperJS爬虫脚本示例，读者替换账号即可运行。对于需要应对复杂JavaScript渲染的爬虫场景，这篇文章提供了从传统到现代的清晰路线图和实用代码。
Javascript的那些事儿
这篇文章从JavaScript的发展历程切入，探讨了它在构建数据库监控可视化方案中的实际应用。作者以Oracle Enterprise Manager中经典的“等待事件图”为实例，展示了如何利用JavaScript和ExtJS类库来复刻这一功能。 具体方案上，文章推荐使用ExtJS的图表组件来处理绘图工作，开发者只需专注于数据获取与格式转换。核心逻辑是创建一个JsonStore来存储等待事件数据，并通过定时（如每5秒）从数据库查询最新记录、移除最旧记录的方式，实现图表的动态前移更新。 文章还对比了JavaScript与Java在实现这一逻辑时的差异，突出了JavaScript作为动态语言在属性定义与操作上的灵活性——例如可以直接使用包含空格的属性名（如“ON CPU”），并通过字典式语法（item['time']）方便地遍历属性，这使得代码比Java实现更为简洁。 最终，通过前端JavaScript的动态数据操作与ExtJS图表库的结合，实现了一个可交互的、实时更新的等待事件监控面板。作者认为，JavaScript或许被低估了，在Web技术主导的时代，它确实是一个强大且实用的工具。
如何设置一个永远无法删除的Cookie
这篇讲的是如何绕过用户删除，实现对浏览器状态的持久化跟踪。作者以“防删除”为切入点，系统梳理了八种客户端存储技术，其核心思路是“灾备机制”——即使主要存储被清除，仍有后备方案可以恢复。 文章从最常见的 HTTP Cookie 讲起，分析了其 4KB 大小限制、明文传输等痛点，指出其被诟病但又不可或缺的矛盾地位。作为主要后备方案的 Flash Cookie (LSO) 能存储 100KB 二进制数据，但依赖插件且易被安全软件清理。作者还详细对比了 Silverlight 独立存储（每应用1MB）、IE专有的 userData（仅限IE且IE9后弃用）等早期技术。 更巧妙的方案在于利用浏览器的“非存储”特性来持久化数据：比如将信息编码为 URL 路径存入浏览器历史记录（但性能极差），或将数据拆分为 RGB 值藏入一张长期缓存的 PNG 图片像素中（需 HTML5 Canvas），亦或是利用 `window.name` 属性跨域跨页面持久保存高达 2MB 的数据（需注意 iframe 安全处置）。 这些方案本质上是在不同技术时代，对“如何在用户控制下保持身份识别”这一难题的持续探索。它们各自在存储容量、安全性、兼容性和实现复杂度间权衡，也从侧面推动了 localStorage 等现代 Web Storage API 的诞生。
如何成为一名优秀的前端工程师
这篇文章从“什么是优秀的前端工程师”这一核心问题出发，分享了作者对这一职业角色的深刻理解。作者认为，真正的优秀远不止于熟练使用jQuery或Bootstrap，而是能徒手实现功能、理解库背后机制，并在没有外援的情况下独立解决大多数任务。 文章首先强调了扎实的技术基本功。它指出，合格的前端必须精通HTML、CSS与JavaScript，并对DOM结构、事件模型、盒模型等基础知识点达到“想都不用想”的程度。超越编码本身，优秀的前端还需学会一门后端语言，以更好地完成系统交互。 其次，作者将沟通能力提到了与技术同等重要的位置。前端处于产品经理、UI设计师、项目经理和最终用户这四类角色的交汇点。优秀的前端需要像外交官一样，平衡各方需求，理解不同立场的关切，从而找到全局最优的解决方案，而非仅仅被动地执行“加个按钮”这样的指令。 文章还强调了持续学习对前端工程师的必要性，Web技术日新月异，停止学习就意味着被淘汰。最后，文章附上了一份详尽的前端知识架构图谱，从浏览器兼容、编程语言到工具链、性能优化，为读者提供了一份清晰的自我提升路线参考。整体来看，这是一篇为前端从业者指明方向、描绘清晰成长画像的实用指南。
CSS选择器
这篇讲的是CSS选择器的全面指南。作者从选择器的核心地位出发，系统地梳理了从基础到高级的各类选择器。 文章首先列举了最简单的元素选择器，随后重点讲解了四类关键选择器：关系选择器（如后代、子、相邻兄弟选择器）精准定位元素间的层级与位置关系；属性选择器通过 [attr] 系列语法，能灵活匹配元素的任意属性值，无论是完全相等、前缀、后缀还是包含片段；伪类部分则覆盖了用户交互状态（如 :hover, :focus）、文档结构（如 :nth-child, :not）乃至表单验证（如 :valid, :invalid）等丰富场景；最后，伪元素（如 ::before, ::after, ::selection）展示了如何通过纯CSS为元素生成或修饰内容。 文中每种选择器都配有清晰的代码示例，比如用 ul > li 仅选中直接子元素，或用 div[class^=a] 匹配类名以特定字母开头的容器。对于容易混淆的 :nth-child 与 :nth-of-type，作者也通过实例厘清了二者的区别——前者按绝对位置计数，后者则按同类型元素计数。这为前端开发者提供了即查即用的实用参考。
一种基于匹配回朔的 css3 选择器引擎实现
这篇讲的是如何在不支持CSS3选择器的老式IE浏览器中，实现一个高效的选择器引擎。文章深入解析了KISSY框架内对应的选择器实现方案。 作者面对的核心问题是，IE6/7/8不支持现代标准的CSS3选择器，而开发者又需要在页面中使用如“兄弟选择器”、“子元素选择器”等高级语法。解决方案分为两大步：首先利用LALR解析器生成器，将选择器字符串解析为结构化的双向链表；随后，引擎采用自右向左的查找策略，并结合“匹配回溯”算法来完成节点匹配。 实现过程中的一个巧妙之处在于“分组与回溯”机制。引擎会将选择器链表按“直接位置”关系（如+、>）进行分组，以此作为匹配和回溯的基本单元。在匹配过程中，如果遇到失败（例如对于“+”紧邻选择器，当前节点不匹配），引擎能智能地回溯到上一个分组，并重新寻找可能的匹配路径，而不是直接放弃。 文章提供了具体的代码流程图与匹配实例，并通过性能测试对比显示，该实现的效率优于知名的Sizzle库。这为处理历史遗留浏览器兼容问题提供了一个扎实且高性能的实践参考。
