最近发现很多朋友希望在文章列表中显示new来表示最新的文章，引起大家注意，但是有不知道修改代码，这 里给大家总结一些方法，实现起来也很方便，希望能帮助大家。 第一种： 我们可以找到库文件new_articles.lbi 找到以下代码： [<a href="{$article.cat_url}">{$article.cat_name}</a>] <a href=”{$article.url}” title=”{$article.title|escape:html}”>{$article.short_title|truncate:10:”…”:true}</a> 修改为： [<a href="{$article.cat_url}">{$article.cat_name}</a>] <a href=”{$article.url}” title=”{$article.title|escape:html}”>{$article.short_title|truncate:10:”…”:true}</a><img src=’images/new.gif>’ 这样就添加了一个图片显示new了。 第二种，显示红色的new就像网站红色日期那样，这种就需要配合时间函数来实现 {if time()-$r[updatetime]<24*60*60}<font color=”red”>[new]</font>{/if} dedecms.com 这就实现了显示红色new，你也可以改为图标或者日期， 第三种，更多ecshop的相关知识在http://www.ecshopmoban.cn <%#NewPic(Convert.ToDateTime(DataBinder.Eval(Container.DataItem, “DateAndTime “)))%> public   string   NewPic(DateTime   T)                 {                         if   (T.Date   ==   DateTime.Now.Date)                         {                                 return   ” <img   src=Images/New.gif> “;                         }                         else                         {                                 return   [...]

经常看到说正则的文章，但说的只是方法，却很少有说以下几个基本概念： 1.贪婪：+,*,?,{m,n}等默认是贪婪匹配，即尽可能多匹配，也叫最大匹配 如果后面加上?，就转化为非贪婪匹配，需要高版本支持 2.获取：默认用(x|y)是获取匹配，很多时候只是测试，不一定要求得到所匹配的数据，尤其在嵌套匹配或大数据中就要用非获取匹配(?:x|y)，这样提高了效率，优化了程序。 3.消耗：默认是消耗匹配，一般在预查中是非消耗匹配。 举个例子，2003-2-8要变为2003-02-08 如果用/-(\d)-/第二次匹配将从8开始，从而只替换第一个2，错误 如果用/-(\d)(?=-)/则第二次匹配从第二个-开始，即不消耗字符- 4.预查：js中分为正向预查和负向预查 如上面的(?=pattern)是正向预查，在任何匹配 pattern 的字符串开始处匹配查找字符串。还有(?!pattern)是负向预查，在任何不匹配 pattern 的字符串开始处匹配查找字符串。负向预查有时会用在对[^]的扩充，[^]只是一些字符，而?!可以使整个字符串。 5.回调：一般用在替换上，即根据不用的匹配内容返回不用的替换值，从而简化了程序，需要高版本支持 6.引用：\num 对所获取的第num个匹配的引用。 例如，’(.)\1\1′ 匹配AAA型。’(.)(.)\2\1′ 匹配ABBA型。 <script> var str=”我不…不…不是…是结…结…结巴…巴” alert(str.replace(/(.)(\.+\1)+/g,”$1″)); </script> [Ctrl+A 全部选择 提示：你可先修改部分代码，再按运行] 当然还有很多，这些都只是基本的需要掌握的 遇到正则问题，一般可用以下两种方法解决： 1.分类，即根据所有的可能列出各种情况，如2003以内的数 0 0 1-999 [1-9]\d{0,2} 1000-1999 1\d{3} 2000-2003 200[0-3] 所以最后的匹配就是 (0|[1-9]\d{0,2}|1\d{3}|200[0-3]) 2.分组，即将整句分为不同的最小单元，如’、%、_成双出现 能成组的，即允许存在的，有 ” %% 如果是大于2的偶数个可细分为多个更小的2字符单元 __ [^'%_] 非以上字符 所以最后的匹配就是 ^(”|%%|__|[^'%_])*$ replace + function 5.5+支持 [...]

使用 line-height 垂直居中 line-height:24px; 使用固定宽度的容器并且需要一行垂直居中时，使用 line-height 即可（高度与父层容器一致），更多的垂直居中总结可以看这里。 清除容器浮动 #main {     overflow:hidden; } 期前也提到过这样的问题，更多信息可以看这里。 不让链接折行 a {     white-space:nowrap; } 上面的设定就能避免链接折行，不过个人建议长链接会有相应的这行（有关换行方面的讨论，参看圆心的记录）。 始终让 Firefox 显示滚动条 html {     overflow:-moz-scrollbars-vertical; } 更多的 Mozilla/Firefox 私有 CSS 属性可以参考这里。需跨浏览器的支持，也可以使用 body, html {     min-height:101%; } 使块元素水平居中 margin:0 auto; 其实就是 margin-left: auto; margin-right: auto; 这个技巧基本上所有的 CSS 教科书都会有说明，别忘记给它加上个宽度。Exploer 下也可以使用 body{     text-align: [...]

标准化设计解决方案 – 标记语言和样式手册 Web Standards Solutions The Markup and Style Handbook Part 1: Get Down With Markup  从标记语法谈起 Chapter 9 精简标签 先前我们不断提到结构化内容能够把结构与设计细节分类并精简标签,该怎么做呢?我们可以使用符合标准的XHTML与CSS代替表格,图片制作我们所需要的版面. 使用标准技术制作网站(特别是十分依赖CSS的网站)的时候,我们常常会养成一个不太好的习惯,就是加上多余的标签和class属性,技术完全不需要它们. 通过在CSS中使用集成选择器(descendant selectors),我们就能消除多余的<div>,<span>与分类属性.精简标签代表页面将能读取得更快,同时更容易维护,在这一章中,我们会讨论几个完成这项任务的简单做法. 以标准技术制作网站时,如何精简标签? 精简标签是个值得讨论的重要话题,制作网站时,用合法的XHTML书写,用CSS设定展示效果能得到的巨大好处之一,就是精简标签.简短的代码代表着下载速度加快,对于使用56k拨号上网的用户来说,这绝对是关键,简短的代码也代表服务器空间需求,带宽消耗减少,这能让老板,系统管理者开心. 问题在于,单纯的确定页面符合W3C标准规范并不代表内容所使用的代码会缩短,你当然能为符合标准的标记内容加上各种不需要的标签,没错,他的确符合标准,但可能为了让设计CSS的时候方便一点,加了不少多余的代码. 别怕!这边有些技巧,让你能设计出简洁,有符合标准的标记内容,但也同时保留足够的CSS样式控制能力.接着让我们学习几个精简标签的简单技巧. 继承选择器 在这里我们要看看两种在个人网站标记侧边栏(包括信息,链接和其他东西)的做法.把所有好东西塞进一个id是”sidebar”的<div>里,以便稍后把它放到浏览器视窗中的某一处(第二部分将会讨论CSS布局 / 排版功能). 方法A:高兴的分类 <div id=”sidebar”>   <h3>About This Site</h3>   <p>This is my site.</p>   <h3>My Links</h3>   <ul>     <li><a href=”archives.html”>Archives</a></li>     <li><a href=”about.html”>About [...]

最近网上再度兴起了CSS布局和Table 布局的争论。我最初颇有些不以为然：我原以为CSS 布局的意义早已深入人心，却没想到还有这么多设计师及开发人员持有异议。 静下心来看罢大家的讨论，一番细想，觉得原因可能有两个方面： 一方面，IE6阴魂不散，让Web开发成本居高不下。网上曾经有一个统计，数据显示Web开发人员针对IE6的投入/产出比是最低的。相信大多数前端工程师都有被IE6折磨得咬牙切齿的经历。与其那般痛苦的用CSS布局，还不如用table 来的爽快方便。 另一方面，我发现前端工程师们越来越务实和注重效率。CSS2以及CSS3的诸多新特性迟迟未能广泛普及，而Web标准布道者们所津津乐道的CSS的优点，在照进现实时又经常会遭遇妥协。尽管我一直以Web标准布道为己任，但也不得不同意：table的浏览器兼容性是最好的；table 布局对于设计师来说更容易上手。 就国内环境而言， table切图依旧是制作门户网站专题或者电子商务网站促销页面的最常用方式，存在即有它的合理性。 所以，我们在推崇CSS布局的同时，无需为了证明它的优越性而把table本身贬得一文不值。日常开发中，也无需激进得完全抛弃table。table本身有语义，该显示数据表格的时候就应该使用<table>；在开发过程中，一些需要权衡成本的场合用table+css的布局也未尝不可。在这方面，很欣赏google 和 facebook 前端工程师们的务实做法。大家可以去关注下facebook 上常见的带半透明阴影的弹出对话框，就是使用<table>来制作的，同样非常的精妙。 这一番的争论，结合近年来Web标准的发展，让我开始思考Web开发中改良和改革的区别。 XHTML 2试图直接进化到XML，宣布与HTML的决裂。这曾经让我这个传统的HTML开发者感到恐慌。而当我看到WHATWG组织提出HTML5(最终被W3C认可)的时候，它的温良的改进让我感觉亲切得多，事实也证明，HTML5正越来越向我们走进。而Douglas Crockford甚至觉得HTML5都太猛烈了，提出了HTML 4.2的改良方案。 再看JavaScript， ECMAScript 4 将JavaScript 改得天翻地覆，所幸技术委员会在最终阶段回归理智，重新提出的向下兼容的ESMAScript 3.1 显然得到更多真正战斗在一线的开发人员的认可。 改良，而非血淋淋的改革，也许才是推动技术发展的更实际、更合情合理的方式。Web标准的演进是如此，产品或项目的升级是如此，甚至社会制度的建设亦如此。

导言：本文一步一步手把手教你打造一个极酷的三层分离的标准滑动门导航菜单，从思路、原理、步骤，手段可谓“无所不用其极”，即便你是菜鸟，相信你看了本文后，也能打造出属于自己的超级漂亮的标准导航菜单。本菜单无冗余结构，利于数据动态输出，非常适合于用在平常的项目中去。本教程中讲到了基本的滑动门原理，相信对那些还在这条路上摸索的朋友会有一些帮助！当然如果有什么错误和问题，也欢迎大家提出来探讨。 本导航菜单想达到的理想目标是： 漂亮，有个性。 结构清晰，语义明确，无冗余标签。 表现、结构、行为三层分离，无侵入式。 有利于后台程序的数据输出。 菜单有三态效果的变化。 能高亮记录点击后的菜单项。 自适应文字的宽度。当文字内容长短变化时按钮能适时变化。 兼容各大主流浏览器。 让我们一步一步的实现这种理想的菜单吧！ 在论坛中经常看到很多朋友在制作菜单，但说实话，不是结构冗余，就是有形无神，或有神无貌。而我们现在要打造的就是极品菜单。无论您是新手或老手，在这个教程中都应该有所收获。 一个理想的菜单其结构应该是干净的、无冗余、分离的，然而因为种种的原因，会为它加上许多无意义的东西，到最后，会离“干净”越来越远。所以在做菜单前，有些原则是在整个制作过程一直要牢记的，不能以任何外力所阻扰。 结构篇 在我的印象中，理想的标准菜单应该具有下面的结构： <div id=”nav”>         <ul id=”menu”>        <li><a href=”#none” title=”博客园”>博客园</a></li>        <li><a href=”#none” title=”社区”>社区</a></li>        <li><a href=”#none” title=”首页”>首页</a></li>        <li><a href=”#none” title=”新随笔”>新随笔</a></li>        <li><a href=”#none” title=”联系”>联系</a></li>        <li><a href=”#none” title=”管理”>管理</a></li>        <li><a href=”#none” title=”订阅”>订阅</a></li>        <li><a href=”#none” title=”冰极峰”>冰极峰</a></li>         </ul> </div> [...]

Data URI Data URI 是由 RFC 2397 定义的一种把小文件直接嵌入文档的方案。通过如下语法就可以把小文件变成指定编码直接嵌入到页面中： data:[<MIME-type>][;base64],<data> MIME-type：指定嵌入数据的 MIME。其形式是[type]/[subtype]; parameter，比如png图片对应的MIME是image/png。parameter可以用來指定附加的信息，更多情況下是用于指定text/plain和text/htm等的文字编码方式的charset参数。默认是text/plain;charset=US-ASCII。 base64：声明后面的数据的编码是base64的，否则数据必须要用百分号编码（即对内容进行urlencode）。 在上个世纪 HTML4.01引入了Data URI方案 ，到今天为止除了IE6和IE7之外，所有主流浏览器都支持，但IE8对Data URI的支持还是有限制的，只支持object（仅是图片时）、img、input type=image、link和CSS中的URL，且数据量不能大于32K。 优点： 减少HTTP请求数，没有了TCP连接消耗和同一域名下浏览器的并发数限制。 对于小文件会降低带宽。虽然编码后数据量会增加，但是却减少了http头，当http头的数据量大于文件编码的增量，那么就会降低带宽。 对于HTTPS站点，HTTPS和HTTP混用会有安全提示，而HTTPS相对于HTTP来讲开销要大更多，所以Data URI在这方面的优势更明显。 可以把整个多媒体页面保存为一个文件。 缺点： 无法被重复利用，同一个文档应用多次同一个内容，则需要重复多次，数据量大量增加，增加了下载时间。 无法被独自缓存，所以其包含文档重新加载时，它也要重新加载。 客户端需要重新解码和显示，增加了点消耗。 不支持数据压缩，base64编码会增加1/3大小，而urlencode后数据量会增加更多。 不利于安全软件的过滤，同时也存在一定的安全隐患。 MHTML MHTML是MIME HTML (Multipurpose Internet Mail Extension HTML)的缩写，是由RFC 2557定义的把一个多媒体的页面所有内容都保存到同一个文档解决方案。这个方案是由微软提出从IE5.0开始支持，另外Opera9.0也开始支持，Safari可以把文件保存为.mht（MHTML文件的后缀）格式，但不支持显示它。 MHTML和Data URI还比较类似，有更强大的功能和更复杂的语法，并且没有Data URI中“无法被重复利用”的缺点，但MHTML使用起来不够灵活方便，比如对资源引用的URL在mht文件中可以是相对地址，否则必须是绝对地址。hedger在《Cross Browser Base64 Encoded Images Embedded in HTML》针对IE的解决方案使用的是相对路径就是因为声明了Content-type:message/rfc822使IE按照MHTML来解析，如果不修改Content-type则需要使用MHTML协议，这个时候必须使用绝对路径，如《MHTML – when you need data: URIs [...]

由于 window.onload 事件需要在页面所有内容（包括图片等）加载完后，才执行，但往往我们更希望在 DOM 一加载完就执行脚本。其实在现在大部分主流浏览器上（Firefox 3+，Opera 9+，Safari 3+，Chrome 2+）都提供了这一事件方法：addDOMLoadEvent。 document.addEventListener(“DOMContentLoaded”, init, false); 那对于 IE 我们如何模拟 addDOMLoadEvent 事件呢？ Matthias Miller 最早提供了如下的解决方案： // for Internet Explorer (using conditional comments) /*@cc_on @*/ /*@if (@_win32) document.write(“<script id=__ie_onload defer src=javascript:void(0)><\/script>”); var script = document.getElementById(“__ie_onload”); script.onreadystatechange = function() {     if (this.readyState == “complete”) {         init(); // call the onload [...]