overflow:hidden真的失效了吗
这篇文章讲的是一个让不少前端开发者困惑的现象：明明给父元素设置了 `overflow: hidden`，但子元素的内容依然“溢出”可见。难道 CSS 属性失效了？ 作者从 W3C 标准出发，点出了问题的关键：`overflow` 属性有一个重要的例外情况——当绝对定位的子元素，其“包含块”已经不再是设置了 `hidden` 的父元素，而是更上层的祖先元素时，父元素的 `overflow:hidden` 将无法裁剪该子元素的内容。 文章最妙的地方是用了一个“海洋、大地、段子”的比喻来解释这个抽象的 DOM 定位关系。蓝色海洋（外层父容器）和红色大地（设置了 overflow:hidden 的元素）里，原本有个黄色段子（内容）被完美裁剪。但当段子通过 `position: absolute` “自立门户”后，它的位置就改由海洋决定了，于是大地的裁剪规则对他失效了。解决办法也很直观：让大地通过 `position: relative` “重新成为段子的监护人”，就能恢复裁剪。 所以，`overflow: hidden` 并非失效，而是定位关系的变化改变了它的作用范围。理解“包含块”如何随定位属性改变，是破解这类布局谜题的核心。
深入理解Javascript之执行上下文(Execution Context)
这篇讲的是JavaScript中最核心但常被忽略的概念——执行上下文。作者从代码的运行环境切入，清晰地将执行上下文划分为全局、函数和Eval三种类型，并指出它是理解变量提升、作用域等行为的钥匙。 文章用一个函数调用图，生动展示了多个执行上下文是如何像栈一样被管理的：单线程的JavaScript引擎在执行代码时，每调用一个函数就会创建一个新的上下文并压栈，执行完毕后再弹出。这种“堆栈”模型解释了代码执行的严格顺序。 更深入地，作者剖析了执行上下文创建时的两个关键阶段。在真正的代码执行前，引擎会先进入“建立阶段”，完成变量与函数的声明、作用域链的构建以及this值的确定。这正解释了为什么函数内的变量可以在声明前被访问（值为undefined），而函数却可以立即调用。 通过对堆栈机制和建立阶段的拆解，文章把抽象的引擎内部行为变得可视化，帮助开发者从根本上理解代码的运行逻辑。
jQuery旋转插件—rotate
这篇介绍的是一个实用的 jQuery 图片旋转插件，作者分享了这个小工具的调用方法和兼容性考量。它在不同浏览器下采用了不同的技术方案，在高级浏览器上利用 CSS3 Transform，而在老旧的 IE 6 等版本上则回退到 VML 来实现旋转效果，确保了广泛的兼容性。 插件的核心方法是 `rotate`。你可以直接传入一个角度数值进行旋转，也可以通过参数对象进行更精细的控制，比如设置初始角度，或者将旋转操作绑定到其他事件上（如点击），在事件内部还能方便地继续链式调用。 对于需要在网页中实现图片旋转，同时又必须兼顾各种新旧浏览器的项目来说，这个插件提供了一个现成的、考虑周全的解决方案。它把底层的兼容性细节封装起来，让开发者能用简洁的代码完成旋转交互。
flv网页播放器源码
这篇来自作者的一次实际需求解决过程——帮朋友弄清楚，为什么从优酷等网站下载的flv文件，用传统的Flash SWF播放器代码无法正常播放。 问题的根源在于播放器参数配置。传统的通用播放器代码缺少针对flv格式的必要声明。作者最终给出的方案是，使用一段标准的
javascript事件触发器fireEvent和dispatchEvent
这篇讲的是如何用JavaScript主动触发事件，重点对比了两种不同环境下的实现方法。 文章指出，我们平时绑定事件后，大多依赖用户的点击、输入等行为来触发。但在某些场景下，比如需要自定义事件或在特定逻辑中主动发起事件时，就需要事件触发器了。作者清晰地对比了IE和现代浏览器（Chrome、Firefox等）提供的两种不同API：IE使用的是私有的`fireEvent`方法，而符合W3C标准的现代浏览器则采用`dispatchEvent`方法。 文章通过一个在IE下触发自定义`ondataavailable`事件的代码示例，展示了如何手动让事件生效。这揭示了两者核心的差异在于适用的运行环境，但共同的目的都是为了让JavaScript代码能够像用户操作一样，主动地发起和分发事件。这对于构建复杂的前端交互逻辑、实现组件间的通信很有帮助。
交互模式之分页还是加载？
浏览网页或App时，你更习惯点击“下一页”，还是让页面自动刷出新内容？这篇讲的正是这个我们每天都会用到、却很少细想的小选择。作者从用户心理和使用场景出发，对比了分页（Pagination）与连续加载（Continuous Scrolling）这两种交互模式的微妙差异。 核心区别在于掌控感与沉浸感。分页模式将信息切块，赋予用户清晰的进度预期和强大的定位跳转能力，尤其适合信息量未知的搜索结果列表。但它也创造了“停顿点”，可能打断用户心流，甚至引发“是继续还是离开”的犹豫。相反，连续加载通过自动刷新维持了无中断的浏览体验，让社交信息流的沉浸感最大化，代价是用户容易迷失，也难以回溯。 文章还指出，当下许多产品采用折中方案，例如Quora和微博在自动加载数次后插入分页按钮，平衡了流畅与可控。在屏幕更小、操作更需便捷的手机端，连续加载成为主流，但搜索类应用仍会保留分页。作者的分析最终落脚于：交互模式没有绝对优劣，关键在于匹配产品目标与用户当下的核心需求——是需要高效检索，还是享受无限漫游。
正则表达式 — QQ微信、优酷前端 邮箱正则表达式验证 Bug
作者从一个具体的“坑”入手，揭示了众多网站（包括优酷、QQ微信）在邮箱验证环节可能存在的通用缺陷。他发现，许多广泛流传的正则表达式无法正确匹配像 i@julying.com 这样用户名或域名仅为单个字母的合法邮箱，根源在于早期代码为了图省事，未考虑这种边界情况，而后继开发者则盲目沿用。 文章不仅指出了这个容易被忽略的验证漏洞，还分析了其“代际传递”的技术债成因。作为解决方案，作者提供了经过改进的PHP和JavaScript版邮箱正则表达式，并附上了新手实例代码，这些新表达式明确支持了对单字母部分的验证。 这篇文章的价值在于提醒开发者，处理用户输入时绝不能有侥幸心理。那些“感觉上”少见的情况，恰恰可能是系统的薄弱环节。它以小见大，强调了对所有数据可能性进行严格验证的重要性，避免重蹈类似SQL注入等历史问题的覆辙。
CSS基线之道
这篇讲的是CSS中容易被忽视的“垂直基线网格”问题。文章从印刷设计中的基线对齐谈起，对比了网页设计的现状：我们熟悉水平网格，却常常忽略垂直方向的一致性，这其实是基于人类大脑的“模式识别”原理——规整、可预测的间距能降低阅读的认知负担。 作者指出，CSS的`line-height`属性与真实基线存在差异，使得精确的垂直对齐变得棘手，但这恰恰是值得我们追求的。文章核心分享了一种基础的CSS实现思路：从最小的正文字体（如14px/22px）出发，定义一个基线单位（22px），并让页面所有元素的`line-height`、`padding`、`margin`都成为这个单位的整数倍。为了可伸缩性，这些像素值应转换为`em`单位。 通过这种简单的数学约束和可见网格的辅助检查，设计师能构建出结构清晰、节奏一致的页面布局，尤其在多列文本场景下，整齐的垂直对齐能带来类似印刷品的专业与可信感。这为处理复杂的垂直节奏提供了一套扎实的基础方法。
缓存为王
这篇讲的是Web性能优化中一个常被低估的选手：缓存。作者从“快速Web应用的关键是Ajax、优化JavaScript和更好的缓存”这一观点出发，做了一项有趣的实测，想看看这三招在实际网站里到底谁最管用。 他用WebPagetest工具模拟不同网络环境，对Alexa前1000网站进行了对比测试。结果有点出乎意料：缓存模式表现最强，页面加载中位数只需3.46秒，远快于“快速网络”（4.13秒）和“禁用JavaScript”（4.74秒）。核心原因在于，缓存直接将90个HTTP请求削减到仅32个，大部分资源从本地读取，彻底避免了网络传输。 文章进一步分析，当前很多网站虽配置了缓存，但有效期很短，导致优势局限于“重复浏览”。作者由此提出，未来的方向是延长缓存时间，并探索预读技术，让性能优势更持久。这提醒我们，在追求新技术的同时，扎实做好缓存这一“基本功”，往往能带来最显著的收益。
JavaScript中两个感叹号（!!）的作用
这篇讲的是JavaScript里两个感叹号“!!”这个小技巧的具体作用。它能将任何表达式的结果强制转换为严格的布尔值（true或false），尤其适合处理那些可能为null、undefined或0的变量。 文章从一个常见场景切入：当变量`a`未定义时，直接用它做条件判断可能不符合预期。而`!!a`会先将其转为布尔值，这里因为`a`是undefined，第一次取反`!a`得到true，再次取反`!!a`就得到了false。这样就为后续逻辑提供了一个明确的布尔判断基础。 作者随后将“!!”这种布尔转换，与其他类型转换做了对比。比如`parseInt()`和`.toString()`是显式转换，而像数字加空字符串`1234+""`就是隐式转换为字符串。“!!”可以看作是一种针对布尔类型的隐式强制转换。 文章还梳理了JavaScript的布尔转换规则：false、undefined、null、0、空字符串会被转为false，而其他值如true、1、非空字符串、对象等则会转为true。因此，对于这些非标准布尔值，“!!”能快速得到一个等价的、干净的布尔状态，让代码意图更清晰。
使用window.postMessage实现跨域通信
这篇文章直面JavaScript开发者长期头疼的跨域通信难题。在同源策略的限制下，作者梳理了document.domain、location.hash、Flash以及window.name等几种传统的变通方案，指出了它们在数据容量、类型或浏览器兼容性上的各种局限。 文章的重心放在了HTML5提供的标准解决方案——跨文档消息传输（Cross Document Messaging）上。它详细讲解了window.postMessage方法的发送机制与message事件的监听接收，强调了该API实现简洁、支持IE8+等现代浏览器的核心优势。文中还通过参数说明和事件对象属性解析，给出了清晰的代码指引。 值得注意的是，文章并未一味推崇新技术，而是客观指出了postMessage在IE8/9下仅支持字符串传输、对IE6/7需额外兼容等现实不足，并引导读者通过JSON序列化等方式进行优化。整篇文章从问题出发，对比了演进路径，最终聚焦于一个广泛可用的现代标准方案，脉络清晰。
HTML5 Charset能用吗？
这篇讲的是前端开发者在实际项目中遇到的一个经典兼容性问题：HTML5简写的``在老旧的IE6浏览器里到底能不能用。作者从项目页面在IE6突然出现乱码的实际故障出发，进行了一系列系统性的测试。 测试对比了HTML5和HTML4两种字符集声明方法在多种环境下的表现。核心发现很有价值：IE6确实能正确识别HTML5的charset声明，其效果与传统HTML4方法一致。但有几个关键细节决定了成败：首先，meta声明必须位于`
`标签最前面，且在文档前512字节内；其次，服务器端（如Nginx）设置的charset优先级高于页面内的meta标签；另外，在UTF-8文件中使用中文注释，并非乱码的直接原因。 测试还揭示了一个有趣的优先级问题：当用两个meta标签先后声明不同字符集时，浏览器以第一个声明为准。因此，作者最终的结论是：只要遵循规范（头部简洁、声明靠前），开发者完全可以放心使用HTML5的DOCTYPE和简化的charset写法，无需担心主流浏览器的兼容性问题。对于需要长期维护的项目，通过服务器端统一设置字符集是更高效可靠的选择。IE BUG相关文章集合
这篇资源集合聚焦于困扰前端开发者多年的IE浏览器兼容性问题，从底层的渲染机制到具体的bug修复方案，构建了一个系统的知识网络。 文章的核心首先深入剖析了IE特有的“HasLayout”机制，这是众多怪异bug的根源。它链接了多篇详解，帮助读者理解这个只存在于IE引擎中的概念如何影响页面布局。紧接着，文章将视线转向了标准的“块级格式化上下文”，并进行了对比解析。理解这两者的差异，是掌握IE兼容问题的关键所在。 真正的实战干货在于第三部分——具体的IE bug清单。这里罗列了从经典的3px bug、margin加倍、PNG透明问题，到Z-index层级失效、overflow处理异常等二十余个具体场景。每个条目都直接指向问题的表现与解决方案，比如如何为IE6修复`position:fixed`，或怎样处理父级padding后子元素的绝对定位。 最后，文章还整理了多个综合性的BUG修复指南与hack速查表，相当于为开发者提供了一套应对IE怪异模式的工具箱。对于需要维护历史项目或追求极致兼容性的前端工程师而言，这份清单能快速定位问题，节省大量试错时间。
关于前端开发
这篇文章是作者对“前端开发工程师”这个职位的深度思考与经验分享。他首先正本清源，强调前端首先是“开发工程师”，扎实的代码能力是基础；在此之上，对“界面”的敏锐感知与审美能力，才是前端区别于其他程序员、可以引以为傲的核心价值。 针对不同背景的入行者，作者给出了非常具体的建议：对于设计师或网页制作人员，必须明白前端开发是“从刨木头开始”的代码构建，而非简单的模板拼装；对于软件开发工程师，关键挑战在于培养对界面好坏的直觉；对于已经在做前端的人，则需要反思自己的技术深度与工作热情，警惕“够用就行”的心态。 文章也为前端爱好者提供了学习路径：通读权威书籍打好基础，通过个人项目实践所学技术，并在交流中共同提升。作者认为，对前端技能本身的精通远比掌握周边技能更重要，而真正的精通往往源于内在的热情与持续的专注。
javascript运算/转换技巧
这篇整理了多个实用的JavaScript编码技巧，专注于简化常见操作。作者直接对比了常规写法与更简洁的实现，提供了许多能立刻用在项目里的“糖”方法。 比如，将字符串快速转换为数字，除了 `parseInt` 和 `Number`，还可以用一元加号 `+` 直接搞定。要将任意值转为布尔值，双非运算符 `!!` 是最直观的写法。求数字数组的最大值，用 `Math.max.apply` 可以避免冗长的循环。文章还触及了几个经典痛点，如浮点数运算误差的修正方法（使用 `toFixed`），以及如何高效地实现数字前补零。 值得注意的是，文章不仅限于类型转换，还包含了防御性编程（如用几行代码防止页面被 iframe 嵌入）和函数参数处理（将 `arguments` 对象转换为真正的数组）的技巧。这些内容虽小，却能实实在在地提升代码的健壮性和简洁度。
font-face在移动终端的支持
这篇讲的是CSS3 font-face特性在移动终端实际兼容性的测试报告。作者开篇点明，font-face能实现漂亮的自定义字体和高质量的图标，在PPI较高的移动设备上显示效果尤其完美，但其支持情况却参差不齐。 文章核心介绍了由BBC News的开发者Kaelig进行的一系列测试。他使用Modernizr脚本并配合另一段检测代码，来探明各主流移动浏览器真实的font-face支持情况，避免被一些声称支持但实际无法渲染的“骗人”浏览器误导。测试结果非常详尽，将移动浏览器明确分为三类：完全支持（如iOS 4/6的Safari、Android 4的Chrome和默认浏览器、Windows Phone 8的IE等）、明确不支持（主要是各平台上的Opera Mini）以及会“骗人”的浏览器（例如Windows Phone 7的IE9和Android 4的UC浏览器）。 结论指向一个现实：在移动端大规模使用自定义字体仍需谨慎。测试数据为我们划出了清晰的兼容性边界，提醒开发者在追求视觉效果的同时，必须做好针对不同浏览器环境的兼容处理。
使用 SourceMap 来进行前端代码调试
这篇文章讲的是前端代码调试中的一个常见痛点：我们写的源码和浏览器实际运行的代码往往不一致。因为现代前端项目普遍会对JavaScript、CSS进行压缩、合并，还会使用Sass、Less、TypeScript等预编译语言进行转换，这导致生产环境中的代码与我们本地编写的代码相去甚远，调试变得异常困难。 SourceMap正是为了解决这一问题而生的技术。作者从这个实际开发场景出发，清晰地解释了它的核心作用——建立压缩或编译后的代码与原始源码之间的映射关系，让开发者可以在浏览器的开发者工具中直接调试最初的、可读的源代码。虽然作者也坦诚地指出，当时的SourceMap生态还不够成熟，但它指明了未来前端调试工具链的一个重要方向。 文章的主体部分是一份详尽的演示文稿（Slides），作者通过二十多页的幻灯片，系统地梳理了SourceMap的原理、格式及其在开发流程中的应用。如果你正苦恼于如何调试生产环境中的“天书”代码，或是想理解这个日益重要的前端基础工具，这篇结合了清晰讲解与视觉化幻灯片的内容，提供了一个不错的入门视角。
YSLOW法则中，为什么yahoo推荐用GET代替POST？
你一定听过“POST请求会被拆分成两个TCP包发送”这个经典结论，它常被用来解释为什么Yahoo的YSLOW优化法则推荐在AJAX中使用GET。但作者没有止步于此，他决定亲手验证一下这个看似权威的说法。 通过Wireshark抓包分析，作者确实观察到，在IE8等浏览器中，一个POST请求的HTTP头部和正文数据会被分开发送，形成两个独立的数据包。这初步印证了Yahoo的优化建议。 然而，实验出现了转折。当作者测试Firefox 5浏览器时，发现POST请求的头部和数据被合并到了一个TCP包中发送，与IE8的行为截然不同。这意味着，那个“POST必被拆分”的结论并非普适真理，其实际表现高度依赖于浏览器的具体实现。 这篇文章的价值在于，它带领读者完成了一次从盲从规范到动手验证的技术探索。作者的实测表明，即使是像“GET优于POST”这样被广泛接受的前端优化法则，其底层原理也可能因环境而异。这提醒我们，在技术选型时，不能只看结论，了解其在不同场景下的实际表现或许更重要。
取得当前script元素的src(path)
这篇讲的是如何在浏览器中准确获取当前正在执行的 script 元素的路径。作者从标准方案切入，介绍了 document.currentScript 这一便捷的 API，它不仅能拿到 src，还能区分脚本是同步还是异步加载。 不过，文章的重点落在了 IE 浏览器的“坑”上。当通过 document.write 动态插入多个 script 标签时，IE 下的 script readyState 状态与标准浏览器不同。例如，在一个由 a.js 动态写入 a.a.js 和 a.b.js 的场景中，a.a.js 通过 readyState 查找可能意外获取到 a.b.js 的路径，而其他浏览器则能正确识别自身。这揭示了 IE 独特的加载与执行机制：即便脚本已下载完成（loaded），其执行流程仍可能保持阻塞。 因此，作者提供了一个兼容函数，通过检查 document.currentScript 是否存在来降级，并针对 IE 实现了基于 readyState 的回退逻辑。文章通过这个具体的细节对比，点明了不同浏览器在脚本加载行为上的核心差异，对处理动态脚本场景的开发者有很强的实操参考意义。
各种浏览器审查、监听http头工具介绍
这篇文章的核心是在帮开发者解决一个实际问题：如何方便地查看和调试HTTP请求/响应头信息。作者从自己研究浏览器缓存和HTTP协议的实践出发，系统梳理了六种不同的解决方案。 文章详细对比了主流浏览器及相关工具的内置审查或插件支持。这包括了谷歌浏览器（Chrome）的开发者工具、专业的HTTPWatch、傲游3.0的网络面板、Safari浏览器上的Firebug Lite插件、火狐浏览器（Firefox）自带的Firebug，以及IE浏览器的内置监听工具。对于每一种工具，作者都给出了具体的开启步骤（比如快捷键或点击位置），并说明了如何在刷新页面后定位到目标资源，最终查看到包含Cookie、缓存状态等详细信息的HTTP头。 这些工具虽然入口各异，但核心目标一致，都是为了让开发者能“看见”网络传输中肉眼不可见的头部数据。对于前端工程师调试布局和资源加载，或是后端开发者排查缓存策略与接口响应，它们都是不可或缺的效率利器。文章用步骤截图的方式清晰地演示了操作流程，实用性很强。
