HTML 5 的data-* 自定义属性
HTML5的data-*自定义属性为前端开发提供了一种标准化的数据存储方式。这篇文章从实际用法出发，清晰地对比了传统getAttribute/setAttribute方法与HTML5新增的dataset属性两种存取路径。前者兼容所有浏览器，但和非标准的自定义属性区别不大；后者则通过专属API提供了更简洁的对象式访问，并在属性名包含连字符时（如data-date-of-birth）自动转换为驼峰命名（dateOfBirth），但在部分旧版浏览器中尚未得到支持。 文章指出，data-*属性的更大价值在于其语义化及与CSS选择器、JavaScript的深度结合。开发者可以直接使用`[data-attr]`选择器来精准定位元素，或根据属性值设置样式，这为动态交互和组件化开发带来了便利。总体来看，文章在厘清基本概念的同时，也给出了兼顾兼容性与未来标准的实践建议。
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这一变化所作出的代码调整思路，体现了方案的延续性。 文末附有不同模式下的效果截图和具体代码示例，为处理类似浏览器兼容性问题提供了清晰、可操作的实用思路。
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库。这为处理历史遗留浏览器兼容问题提供了一个扎实且高性能的实践参考。
一览CSS布局标准
这篇文章梳理了CSS布局从诞生至今的完整演变脉络。作者从CSS1仅用于图文绕排的Float，讲到CSS2.1正式确立“常规流、浮动、绝对定位”三大布局支柱，为我们理解现代布局打下了基础。 核心篇幅留给了CSS3时代正在推进的五大布局标准。文章逐一解析了多栏布局、弹性盒布局、栅格布局等新方案，不仅点明了它们各自的状态和兼容性，还通过具体代码示例（比如用Flexbox轻松实现不定宽高居中）展示了这些新思路相比传统Float的简洁与灵活。 但这篇文章的价值不止于罗列技术点。作者敏锐地指出了一个关键矛盾：标准制定往往滞后于浏览器厂商的实现，开发者夹在中间饱受兼容性之苦。他更呼吁开发者不要只满足于Float或某些库，而应回归标准本身，去理解布局的原理。在低端浏览器逐渐退场的今天，这些更强大的新布局技术正是提升前端代码质量的关键。
你需要知道的三个CSS技巧
随着浏览器竞争白热化，越来越多的设备能支持前沿的W3C标准，这让我们得以用更强大的CSS来编写简洁、易维护的前端代码。这篇文章就聚焦于此，分享了三个或许被你忽略但非常实用的CSS特性。 第一个是`attr()`函数，它能直接在CSS中读取HTML元素的属性值。比如，通过`:after`伪类，你可以在打印页面时自动为链接加上其`href`属性地址，无需额外JavaScript。第二个技巧是`counter()`，它允许你在CSS中实现自动编号，为`h4`标题或区块添加序号时，不再受限于`
- `标签，灵活性大增。第三个是`calc()`函数，它让CSS能直接进行算术运算，轻松创建宽度为父元素宽度减去固定像素的元素，避免了以往需要JS计算样式的麻烦。
作者通过具体代码示例，展示了这些功能如何简化日常工作。文章的核心观点是，成熟的CSS已在某些方面具备替代JavaScript的能力，掌握它们能显著提升开发效率。
CSS技巧荟萃：了解CSS页面布局和加载流程
这篇讲的是CSS页面布局中一个常被忽略但至关重要的基础：浏览器的文档加载与渲染流程。作者没有直接抛出花哨的技巧，而是从最根本的元素显示类型——`block`与`inline`——的区别与特性讲起。
文章清晰地对比了这两类元素的默认行为：`inline`元素如 `` 会在同一行排列，而 `block`元素如 ` 这篇讲的是网页性能优化中一个经典又实用的技巧——CSS Sprites。作者从众多网站（比如早期淘宝）的CSS背景图设置出发，拆解了其背后的原理。
核心思路其实很直观：与其为页面上的小图标（按钮、装饰等）请求十几张甚至几十张独立图片，不如预先将它们排列、合并成一张大图。在前端，通过CSS的`background-position`属性，像从一张大画卷上“截取”特定部分一样，精准地为每个元素显示对应的图标。这样做最大的好处是，原本需要十几次HTTP请求才能加载完的图片，现在一次请求就搞定了。这直接减少了网络连接开销，显著提升了页面加载速度，这在移动端或高并发环境下尤为重要。
文章也坦诚地分析了它的两面性。优点很明确：减少HTTP请求、降低服务器压力、可能减小总图片字节数。但代价是开发与维护的复杂性：开发者需要用工具精确计算每个图标的坐标位置，后期修改或添加新图标也如同“针线活”，可能需要重新调整整张大图和坐标。
总体来说，这是一篇从现象到原理再到优缺点剖析的实用技术解说，清晰展示了如何在性能与开发便利性之间做出权衡。 这篇讲的是CSS布局中一个既经典又实用的技巧：利用BFC（块级格式化上下文）来控制元素的排列。文章先从“overflow:hidden会触发BFC”这个常见现象切入，解释了BFC本质上是创建一个独立的布局环境，内部的元素互不干扰。
核心价值在于通过一个清晰的案例展示了BFC的应用。当给图片设置左浮动后，右侧文字内容会环绕图片。作者接着演示，只需为文字容器添加`overflow:hidden`属性，就能使其形成一个新的BFC，从而让文字规整地排列在浮动图片的右侧，避免了复杂的清除浮动操作。
更进一步，文章还深入探讨了在IE6等旧浏览器下的兼容性挑战。这里引入了另一个概念“HasLayout”，并详细说明了如何通过`zoom:1`或`min-height:0`等Hack方式同时解决BFC和HasLayout问题，最终给出了一个兼顾各浏览器的完整CSS方案。整体来看，这篇文章从一个具体问题出发，将原理、标准实现和历史兼容方案串讲得十分透彻。 这篇文章讲的是一个让不少前端开发者困惑的现象：明明给父元素设置了 `overflow: hidden`，但子元素的内容依然“溢出”可见。难道 CSS 属性失效了？
作者从 W3C 标准出发，点出了问题的关键：`overflow` 属性有一个重要的例外情况——当绝对定位的子元素，其“包含块”已经不再是设置了 `hidden` 的父元素，而是更上层的祖先元素时，父元素的 `overflow:hidden` 将无法裁剪该子元素的内容。
文章最妙的地方是用了一个“海洋、大地、段子”的比喻来解释这个抽象的 DOM 定位关系。蓝色海洋（外层父容器）和红色大地（设置了 overflow:hidden 的元素）里，原本有个黄色段子（内容）被完美裁剪。但当段子通过 `position: absolute` “自立门户”后，它的位置就改由海洋决定了，于是大地的裁剪规则对他失效了。解决办法也很直观：让大地通过 `position: relative` “重新成为段子的监护人”，就能恢复裁剪。
所以，`overflow: hidden` 并非失效，而是定位关系的变化改变了它的作用范围。理解“包含块”如何随定位属性改变，是破解这类布局谜题的核心。 这篇来自作者的一次实际需求解决过程——帮朋友弄清楚，为什么从优酷等网站下载的flv文件，用传统的Flash SWF播放器代码无法正常播放。
问题的根源在于播放器参数配置。传统的通用播放器代码缺少针对flv格式的必要声明。作者最终给出的方案是，使用一段标准的 这篇讲的是CSS中容易被忽视的“垂直基线网格”问题。文章从印刷设计中的基线对齐谈起，对比了网页设计的现状：我们熟悉水平网格，却常常忽略垂直方向的一致性，这其实是基于人类大脑的“模式识别”原理——规整、可预测的间距能降低阅读的认知负担。
作者指出，CSS的`line-height`属性与真实基线存在差异，使得精确的垂直对齐变得棘手，但这恰恰是值得我们追求的。文章核心分享了一种基础的CSS实现思路：从最小的正文字体（如14px/22px）出发，定义一个基线单位（22px），并让页面所有元素的`line-height`、`padding`、`margin`都成为这个单位的整数倍。为了可伸缩性，这些像素值应转换为`em`单位。
通过这种简单的数学约束和可见网格的辅助检查，设计师能构建出结构清晰、节奏一致的页面布局，尤其在多列文本场景下，整齐的垂直对齐能带来类似印刷品的专业与可信感。这为处理复杂的垂直节奏提供了一套扎实的基础方法。 这篇讲的是前端开发者在实际项目中遇到的一个经典兼容性问题：HTML5简写的``在老旧的IE6浏览器里到底能不能用。作者从项目页面在IE6突然出现乱码的实际故障出发，进行了一系列系统性的测试。
测试对比了HTML5和HTML4两种字符集声明方法在多种环境下的表现。核心发现很有价值：IE6确实能正确识别HTML5的charset声明，其效果与传统HTML4方法一致。但有几个关键细节决定了成败：首先，meta声明必须位于` 这篇讲的是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浏览器）。
结论指向一个现实：在移动端大规模使用自定义字体仍需谨慎。测试数据为我们划出了清晰的兼容性边界，提醒开发者在追求视觉效果的同时，必须做好针对不同浏览器环境的兼容处理。 这篇讲的是，CSS中实现阴影效果的两种主流方式——传统的`box-shadow`属性与新的`filter: drop-shadow`滤镜——之间该如何选择。作者从自己项目中为实现全方位阴影而编写冗长`box-shadow`代码的经历出发，对比了两种方案的实现与效果。
核心差异在于，`drop-shadow`滤镜能更真实地模拟光照下的阴影，因为它能感知元素的实际轮廓（包括透明区域），生成的阴影贴合形状，视觉上更自然。相比之下，`box-shadow`只能为元素的整体矩形边界框添加阴影。此外，两者的浏览器兼容性也不同，`filter`在Webkit内核浏览器（如Chrome、Safari）中已获得良好支持，而Firefox和IE则仍需依赖`box-shadow`。
因此，在面向现代浏览器开发时，`filter: drop-shadow`无疑是更优的选择，能用更简洁的代码实现更逼真的效果。对于需要兼容旧版浏览器的场景，则应继续使用`box-shadow`作为备选。文章提供了清晰的代码对比和在线示例，直观展示了两者的区别。 这篇讨论的是在那些还没有进行响应式改造的老网站上，viewport meta标签为何依然关键。很多开发者熟悉响应式设计中 `width=device-width` 的标准写法，却忽略了旧网站在移动端的尴尬处境。
文章点明，iPhone和安卓设备默认会以980px宽度来渲染页面。这意味着，一个宽度为1024px的页面会被截断，而一个只有700px宽的页面则会留下大量空白。核心问题就在于，没有明确告诉浏览器页面的真实宽度。解决方案其实很简单：为这类固定宽度的网站，明确设置viewport的实际像素值，比如 ``。
更值得注意的是，文中剖析了一个常见的错误实践：在非响应式网站上使用 `initial-scale=1`，尤其是同时搭配 `user-scalable=no` 或 `maximum-scale=1`。这会导致页面被锁定在100%宽度且禁止缩放，用户无法看清被截断或缩小的内容，体验极差。文章给出的结论清晰有力：如果你的网站不是响应式布局，那就请避免使用初始缩放设置，并务必保留用户的缩放能力。 这篇文章从几个基础的HTML问题切入，探讨了应该如何正确使用标签、ID和CLASS。作者认为，多使用header、nav这类有语义的标签，而不是无意义的div和span，本质上是让HTML更接近内容本身，未来甚至可能取代常见的div class组合。
文章进一步驳斥了“应尽量只用class以避免破坏样式优先级平衡”的观点，指出id的唯一性和高优先级是自然的设计，能和class协作表达更精确的语义。同时强调，在命名class和id时，应基于内容含义（如main-content、sidebar）而非视觉位置（如left、right），以适应响应式设计的需求。
作者的结论很清晰：不要滥用class而回避id，也坚决避免使用像“f14 red”这样的纯样式类名。整个讨论传递的核心理念是，HTML的写法应当服务于内容的表达和未来的可维护性，鼓励开发者勇于尝试新标准，保持对技术趋势的敏感。 这篇讲的是Windows 8普及后，开发者发现不少网页在IE10中显示异常，一部分是旧版IE的CSS hack遗留问题，另一些则是新出现的兼容性问题。由于IE10不再支持条件注释，作者整理了几种针对IE10的CSS Hack方法。
首先是结合IE私有条件编译和JavaScript，在页面中为html元素添加“ie10”类名，从而通过选择器应用特定样式。另一种是利用IE10支持的“-ms-high-contrast”媒体查询特性，直接编写仅对该浏览器生效的CSS规则，不过这种方法也可能被未来版本继承。文章还提到了利用“min-width:0\0”这种hack同时覆盖IE9和IE10，但区分度不高。
作者在最后坦言，为IE专门编写hack是一件无奈的事情，这些方法都存在未来失效的风险，但它们确实是解决当前兼容性问题的实用技巧。 这篇讲的是一个容易被忽略的IE浏览器兼容性细节。作者从阅读《HTML5秘籍》出发，分享了他在开发中遇到的一个具体问题：当本地HTML文件需要加载JavaScript时，IE默认会因安全设置弹出警告框，影响用户体验。
他从中学习到了“Web标志”这个解决方案——其实就是在HTML头部添加一行形如``的特殊注释。这行注释的作用是告诉IE浏览器，将该页面视为从远程网站下载而来，从而在本地的安全沙箱中正常运行，避免弹窗。
文章不止于介绍技巧，作者还进一步提出了自己的思考：这个注释是否真的广泛适用？使用了它又会不会带来其他副作用？例如，有观点认为这可能导致页面从本地缓存加载，从而影响某些脚本效果。而许多主流网站并未使用这一注释，也引发了对其实际价值的探讨。作者将这些疑问抛出，为前端开发者留下了一个值得琢磨的实践话题。 这篇讲的是颜色在代码世界里的“面孔”——为什么同样是红色，有时写#FF0000，有时要写rgb(255,0,0)，有时又变成hsl(0,100%,50%)？作者从开发者的实际困惑切入，拆解了RGB、HEX、HSL等主流颜色格式的底层逻辑和表达差异。
文章的核心对比在于这些格式的侧重点不同：RGB和HEX是直观的“光三原色”混合模型，适合精确匹配设计稿；而HSL则从人眼感知出发，用色相、饱和度、亮度来描述，极大地方便了我们动态调整颜色明暗或生成色系。作者还点出了一个关键场景——无障碍设计（如调整对比度）时，HSL往往比RGB更得心应手。
理解这些差异不是为了死记硬背，而是为了在编码时做出更明智的选择。比如，需要精确的视觉一致性时用HEX，在编写需要动态变化的颜色代码（如主题皮肤、hover效果）时，切换到HSL会让逻辑更清晰、更易维护。CSS Sprites的原理
CSS布局中一个简单的应用BFC的例子
overflow:hidden真的失效了吗
flv网页播放器源码
CSS基线之道
HTML5 Charset能用吗？
font-face在移动终端的支持
是时候使用filter:drop-shadow了
非响应式设计的viewport
标签？ID？还是CLASS？
IE10 CSS hack
Web标志(The Mark of The Web)摘记
颜色的代码表达式