Archive for the ‘ html/css ’ Category

HTML5教程:HTML5的基础写法

对比一下XHTML 1.0 Transitional的规范,html5基本上没有XHTML 1.0 Transitional严格的要求,并且简化了很多东西。

文档声明更简单了。

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "<a href="http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd</a>">
<!--在HTML5中,这样写:-->
<!DOCTYPE html>

html标签上不需要声明命名空间。

<html xmlns="<a href="http://www.w3.org/1999/xhtml">http://www.w3.org/1999/xhtml</a>" lang="zh-CN">
<!--在HTML5中,这样写:-->
<html lang="zh-CN">

字符集编码声明也简单了

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<!--在HTML5中,这样写:-->
<meta charset="UTF-8" />

可以不用给css及javascript代码写type属性了

<script type="text/javascript"></script>
<style type="text/css"></style>
<!--在HTML5中,可以直接写:-->
<script></script>
<style></style>

没有XHTML代码规范的要求

所有的标记都必须要有一个相应的结束标记;

所有标签的元素和属性的名字都必须使用小写;

所有的XML标记都必须合理嵌套;

所有的属性必须用引号””括起来;

<div></div>
<br>
<INPUT TYPE="TEXT" />
<!--这些都不做严格要求-->

商业价值:HTML5将带来什么

作为科技巨头的角力工具,这个互联网产业迫切需要的新标准,其诞生很可能会是个漫长的过程。

葛鑫|文

2010年上半年的苹果与Adobe的冲突,使HTML5的存在一夜之间被很多人所知晓。在乔布斯的煽动下,这一已经在科技界潜行数年的下一代Web标准,被迅速拎到了台面上,苹果、谷歌、微软这科技界三巨头,连同众多业界明星,似乎突然对HTML5变得情有独钟,利益集团的之间的争夺,成了这个技术最好的催化剂。

HTML5的火热似乎暗合了“合久必分,分久必合”的旧理。愈发多样化的互联网应用与现有平台割据之间的矛盾,产生了对标准统一Web标准的迫切需求,而HTML5正是担负这一使命的最佳候选——现在看来,也是唯一候选。

显然,它的重要性不言而喻。而围绕着这一标准的争夺,势必会激起科技界的惊涛骇浪。

HTML5的革命

HTML即超文本标记语言或超文本链接标示语言,是目前网络上应用最为广泛的语言,也是制作网页的主要语言。诞生于1993年的HTML,其文档制作并不是很复杂,且功能强大,支持不同数据格式的文件嵌入。

然而,HTML的最近一次升级还是1999年12月发布的HTML4。

乔布斯在檄文《关于Flash的思考》一文中说:“Flash是PC时代的产物,它是为个人电脑与鼠标发明的。”──其言外之意就是说已经不适应现在移动终端的需求。的确,诞生于上世纪末的HTML4仅是PC时代的产物(后继的XHTML语言除了语法外与HTML4几乎没有区别),在它诞生至今的10年里面,互联网世界已经发生了天翻地覆的变化:Netscape灰飞烟灭,微软的IE如今已经演化到了IE9;Firefox 从 Netscape 的死灰中诞生,重新占据了第二位;Safari和Chrome组成的Webkit(浏览器架构的一种)阵营为移动互联网世界勾画出了蓝图。

更重要的是,在如今的后Web2.0时代,人机交互、人网交互已经成为常态,对富媒体应用和本地存储的支持乏力成为现有浏览器的心腹之患。而将Web由内容平台改造为标准化的应用平台,并统一各大平台阵营的标准,正是HTML5的终极使命。

HTML5主要有以下几个特色:降低插件的重要性,简化Web开发;大幅提高对动态图像、位置服务、本地存储的支持;提高浏览器安全性。

很多业内人士认为HTML5以上特点是具有革命性的,特别是其丰富的标签体系,类似于内置了很多快捷键,将取代那些完成比较简单任务的插件,可以降低应用开发的技术门槛。

其实,由于鼓励创新,互联网在之前是非常欢迎浏览器插件的。而声音、动画及其他一些非常生动的网页,通过Adobe、 RealAudio、微软以及其他的一些公司开发的插件在网络呈现时也的确让人耳目一新。然而,问题很快就出现了,插件的接口是向所有人开放的,每个人都在尝试用自己定义的技术给网页增加新的功能,混乱不可避免。其中最有名的插件就是Flash,其他类似的插件更是数不胜数。

HTML5有望解决这一问题。举例来说,HTML5中的“video”标签使Web开发人员很容易地把视频内容与网页中的其他内容整合起来,使得Web的多媒体开发不再仅仅是使用Adobe的Flash、 微软的Silverlight和升阳的JavaFX——这些被垄断的富媒体开发工具的人员的专利。显然,这对互联网的富媒体化大有裨益。

总之,从获取到互动,从图片到视频,从云端到终端,当下互联网的复杂性,迫切需要HTML5这样的救世主出现。

其实,HTML5的诞生本身就是创新派“革命”的结果:万维网之父Tim Berners-Lee在创造出HTML的同时,建立了互联网标准化组织W3C(万维网联盟)。然而,在HTML之路上行走数年之后,W3C已经跟不上互联网时代的步伐。W3C当时认为,HTML4已经功德圆满,他们的下一步工作是语法升级的可扩展超文本置标语言XHTML。他们认为其可以将Web带入光明的未来。

然而,作为第三方的W3C组织忽略了一个重要的变量——在互联网时代崛起的科技巨头。实际上,在Netscape消失之后,IE并没有一统江湖。恰恰相反,浏览器进入了战国时代。Firefox、Opera、Safari相继诞生,而它们的背后都有着强大的支持力量。

于是,由于不满“互联网造物主”——W3C的思维僵化行为拖沓,苹果公司等新贵们自发组织成立了新的超文本语言标准工作组,这就是WHATWG(超文本应用科技工作组),其使命便是致力于HTML5的规范和普及。

现在看来,这些充满了野心和动力的科技巨擘,显然比无私的“互联网造物主”有力量的多。

巨人的战场

毫无疑问,HTML5将是未来互联网技术的制高点。围绕这个制高点,科技巨头们必将展开激烈的争夺。目前来看,争夺的主角,再一次锁定在了苹果和谷歌为首的两大阵营。

在苹果方面,其不断扩张的业务结构中,软件的权重始终是处于较弱的位置,比起Mac机与iPhone,其核心软件在业界的影响还要小的多。而HTML5为苹果改变这种局面,提供了千载难逢的良机。可以预见,依托其出色硬件平台,苹果将向HTML5高地展开持续攻势。

在谷歌方面,虽然它入局较晚,但其必然不会将互联网技术的优势地位拱手相让。实际上,除了在线软件领域的优势之外,谷歌TV、谷歌手机等硬件尝试,其根本目的便是为其软件拓展探路。比如谷歌的Nexus One手机就曾被用来展示最新的Flash Player 10.1。

在这场抢占互联网未来的制高点战役中,苹果与谷歌可谓针锋相对:

乔布斯批判Flash,谷歌马上在I/O大会上抨击苹果违背互联网精神;由于HTML5标准中没有指定任何的视频编解码器,在苹果明确提出自己掌握知识产权的H.264标准建议之后,谷歌在I/O大会上便提出了WebM标准;当苹果在主页中为HTML5特别开辟一个栏目之后,谷歌针锋相对地推出自己的HTML5“练兵场”——HTML5 ROCKS;双方都在抢先发布HTML5新特性……

在巨头们的强硬姿态下,各种科技力量已经开始站队。例如,包括Opera,Mozilla,Adobe等软件巨头和AMD,ARM,NVIDIA,Qualcomm在内硬件巨头明确表示支持谷歌的WebM标准;而之前蓝光阵营的索尼、富士、三星等公司,则本身就是H.264的专利拥有方之一。

在这场争夺中,特别值得关注的是软件领域的老大微软的态度。其也已经在HTML5领域密集布局。目前来看,一方面,微软欲利用既得优势树立自己的标准,如其宣布Chrome, Firefox和Safari并不适合处理HTML5内容,而自己的IE9渲染HTML5动画的速度是Chrome 5、Safari的12倍以上等。另一方面,与谷歌放弃正在开发的位置服务技术Gear而转投HTML5不同,微软肯定不会轻易放弃Silverlight,其在口头支持HTML5的同时,是否会沿用捆绑销售的老伎俩尚未可知。

除了主张自己的主导标准外,在其他HTML5细节上,微软似乎与苹果站得更近些。例如,其已经公开宣布支持H.264标准。当然,这可能与其和苹果一样同为封闭性研发体系,并同为H.264专利拥有方之一有关。

按照计划,WHATWG将在2012年向W3C提交HTML5规划。但历史证明:HTML5完成它的使命将并非易事。

从2003年WHATWG公布HTML5草案算起,已过7年光景,HTML5并没有诞生,WHATWG的最大进展仅是促使潜在对手XHTML 2.0的夭折——2008年,W3C宣布,其工作重点已经转移到HTML5方向上。

之所以WHATWG进展也如此缓慢,原因同样是由于平台的割据,并且形态更为复杂。从采用不同操作系统的手机,到各家的应用程序商店;从尚处于少年期的云端技术到各家保留的专利。特别是已经势同水火的苹果与谷歌,对于连互联网电视都要各立山头的它们来说,什么变量才会使他们妥协于同一种大互联网标准呢?

而对于那些“卫星国”来说,滋味可能更为难受。虽然与苹果都有某种嫌隙的它们被谷歌拉到I/O大会上,势成“倒乔联盟”,但在实际商业生存中它们会与哪方合作还尚未可知。

比如,H.264在团结了硬件播放器阵营发展多年之后,已经成为实际上的下一代互联网视频技术,连谷歌自己的Youtube都已经向它敞开了大门,“卫星们”还会拒绝么?对于它们来说,不停的换队(如同Palm的生存状态)显然是件痛苦的事情,但商业利益的考量显然要压倒一切。

可见,虽然各方对统一标准、提高互联网易用性的目标还是一致的,但是在各方完成博弈之前,人们还要一直等待下去。

显然,虽然HTML5时代令人兴奋,但是它的真正到来,很可能将是一个漫长的过程。

文字注释,display:none,type=hidden,所能引起的文字叠影(Duplicate characters)BUG所有可能性解决方案汇总

刚经历了一个噩梦般的BUG。在无法测试的情况下,靠猜测可能性最终解决了问题,呃呃。 IE6在一些情况下会引发文字叠影BUG,也就是网上常说的多了一只“猪”。下午看到这种情况时我很嗨皮,因为最容易想到就是注释引起的,只要把注释删了就可以。但是打开源文件发现不是这么回事,没有注释,但依然还是发生了文字叠影. 大致发生问题的代码是这样的:

<div id="a" style="display:none;">
<div class="b"><strong>这里是会发生文字叠影的地方。</strong></div>
<div class="div_form_bottom"></div>
</div>

a层是个隐藏起来的层,用户进行某个操作以后,这个层会显示出来,里面嵌套了负责反馈操作结果(b层)和一个返回按钮(c层)。

 

耐心找了几十篇关于如何解决这问题的文章,发现引发这种BUG有几个条件:

1.最常见的是注释引起的,一个父容器包含两个浮动的子容器,中间夹一段注释最喜欢发生这种问题。

2.hidden的input直接放在form下.

 3.display为none的div也有可能引发此bug.

 

综合前面提到的引发这种BUG有几个条件,只有第三条比较符合。但情况又不完全相同。最后我用的是“给文字区块加position:relative;属性”来解决问题,比较遗憾的是无法深入测试。这种情况作为特例记录。

 

下面是比较正常条件下的基本测试和解决方案汇总。 测试代码包含了上面说到的三种情况:

 

<div style="width: 400px;">

   <!-- 注释注释 -->
   <input type="hidden" value="hidden" />
<div style="display:none;">hidden</div>
<div style="width: 400px; float: left;">IE6文字溢出的BUG</div>
</div>

解决办法(没有直接在IE6下测试,用的是IETester):

A 直接删除注释。

B 改变结构,不出现【一个容器包含2两个具有“float”样式的子容器】的结构。

C 修正注释的写法,写成IE条件注释。

D 在出现问题的子容器后面加个丑陋的br

E 在出现问题的文字最后加一个空格。很无耻,原理是让它复制出一个空格,我是如此理解的。但是奏效了。还有一个办法就是文字后面跟个display:none的span,也奏效了。

F 在第二个容器后面加一个或者多个清除浮动的div来解决。这个方法我试了没有作用。

G 给文字区块外面包上一个div

H 去除文字区块的固定宽度

I 给文字区块加position:relative;属性

J 要把input直接放在form下面,可以用div或者fieldset把这个input包起来

K 有display:none的,将display:none 所在的层再用一个div包起来。

 

一些值得注意的解决办法和demo测试:

第二种情况我没有遇到过,但是这位童鞋遇到了:http://hi.baidu.com/niez/blog/item/d2f88977a6de011db151b92d.html

还有一位童鞋遇到的问题也很神奇,在这里:http://blog.gulu77.com/?p=524

一个老外提出的应对方法:http://www.ajaxupdates.com/decoy-fix-for-ie-duplicate-characters-bug/ 针对我遇到的问题无效,但是他的思路很有意思。

全方位清理浮动[转]

原文地址:http://isd.tencent.com/?p=1122

忘记从什么时候开始用:after来清除浮动,原理多多少少知道一点,但没有深究,只是因为好用,用习惯了,常年放在一个reset的css里,名字叫做clearfix。今天在腾讯的ISD看到这个文章介绍了多种清除浮动的方法,文章里附有demo。强烈推荐好好研究那个demo,很多细节的东西口头上说还不如多做测试。

清除浮动一个凡是做页面的人都会遇到的一个东西,但是是否大家都能够清楚的知道,全方位的了解呢?于是一闲下来了马上写了这样的一篇文章,不能讲面面俱到,然而基本能将我所知道的倾囊相授了。

我们粗略的一起来看看清除浮动的办法一共有多少个(IE里面用zoom:1就不写了,下一个专题再写)。对应的DEMO

  1. 采用伪类:after进行后续空制的高度位零的伪类层清除
  2. 采用CSS overflow:auto的方式撑高
  3. 采用CSS overflow:hidden的方式产生怪异适应
  4. 采用display:table将对象变成table形式
  5. 采用div标签,以及css的clear属性
  6. 采用br标签,以及css的clear属性
  7. 采用br标签,以及其自身HTML的clear属性

粗略的看,他们都能将问题解决;然而他们另外一方面又有着各自的利弊。(一一对应)

  1. 优点结构语义化完全正确,不会产生其余的怪异问题。
    缺点复用方式不当容易造成代码量急剧增大。
    建议最外层轻浮动时使用,或清晰模块化复用方式的人使用。
  2. 优点结构语义化完全正确,代码量极少。
    缺点多个嵌套后,点击最外层的轻浮动框会遭成最外层至最内层内容全选(FF);或者在mouseover造成宽度改变时会出现最外层模块有滚动条(IE)。
    建议内个模块使用,请勿嵌套
  3. 优点结构语义化完全正确,代码量极少。
    缺点内容增多时候极易不会自动换行而内容被隐藏掉。
    建议宽度固定时使用,请勿嵌套
  4. 优点结构语义化完全正确,代码量极少。
    缺点盒模型属性已经改变,可想而知奇异事件自然多得你数都数不到。
    建议如果你不想改Bug改死你的话,最好不要使用;不过可以作为alpha版本当中临时性的忽悠下测试。
  5. 优点代码量极少,复用性极高。
    缺点完全不能完美的适应语义化,不利于改版以及需求变更。
    建议初学者使用,可以让你快速的解决浮动问题。
  6. 优点语义化程度比第5种情况要更优;代码量极少,复用性极高。
    缺点语义化依旧不完美,不利于改版以及需求变更。
    建议初学者使用,可以让你快速的解决浮动问题。
  7. 优点语义化程度比第5、6种情况要更优;代码量最少,复用性极高。
    缺点语义化依旧不完美,不利于改版以及需求变更。
    建议引导初学者思维升级时使用,让其明白与其用classname来控制一种表现,倒不如回归到WEB1.0的时代的网页直接用html属性来控制表现,毕竟后者的代码量更少。

Unicode – CSS中文字体转编码

备份一下这方面的内容,虽然大部分字体应该不会用到。

中文名 英文名 Unicode Unicode 2
Mac OS
华文细黑 STHeiti Light [STXihei] \534E\6587\7EC6\9ED1 &#x534E;&#x6587;
&#x7EC6;&#x9ED1;
华文黑体 STHeiti \534E\6587\9ED1\4F53 &#x534E;&#x6587;
&#x9ED1;&#x4F53;
华文楷体 STKaiti \534E\6587\6977\4F53 &#x534E;&#x6587;
&#x6977;&#x4F53;
华文宋体 STSong \534E\6587\5B8B\4F53 &#x534E;&#x6587;
&#x5B8B;&#x4F53;
华文仿宋 STFangsong \534E\6587\4EFF\5B8B &#x534E;&#x6587;
&#x4EFF;&#x5B8B;
丽黑 Pro LiHei Pro Medium \4E3D\9ED1 Pro &#x4E3D;&#x9ED1; Pro
丽宋 Pro LiSong Pro Light \4E3D\5B8B Pro &#x4E3D;&#x5B8B; Pro
标楷体 BiauKai \6807\6977\4F53 &#x6807;&#x6977;
&#x4F53;
苹果丽中黑 Apple LiGothic Medium \82F9\679C\4E3D\4E2D\9ED1 &#x82F9;&#x679C;
&#x4E3D;&#x4E2D;&#x9ED1;
苹果丽细宋 Apple LiSung Light \82F9\679C\4E3D\7EC6\5B8B &#x82F9;&#x679C;&#x4E3D;
&#x7EC6;&#x5B8B;
Windows
新细明体 PMingLiU \65B0\7EC6\660E\4F53 &#x65B0;&#x7EC6;&#x660E;
&#x4F53;
细明体 MingLiU \7EC6\660E\4F53 &#x7EC6;&#x660E;&#x4F53;
标楷体 DFKai-SB \6807\6977\4F53 &#x6807;&#x6977;&#x4F53;
黑体 SimHei \9ED1\4F53 &#x9ED1;&#x4F53;
宋体 SimSun \5B8B\4F53 &#x5B8B;&#x4F53;
新宋体 NSimSun \65B0\5B8B\4F53 &#x65B0;&#x5B8B;&#x4F53;
仿宋 FangSong \4EFF\5B8B &#x4EFF;&#x5B8B;
楷体 KaiTi \6977\4F53 &#x6977;&#x4F53;
仿宋_GB2312 FangSong_GB2312 \4EFF\5B8B_GB2312 &#x4EFF;&#x5B8B;_GB2312
楷体_GB2312 KaiTi_GB2312 \6977\4F53_GB2312 &#x6977;&#x4F53;_GB2312
微软正黑体 Microsoft JhengHei \5FAE\x8F6F\6B63\9ED1\4F53 &#x5FAE;&#x8F6F;&#x6B63;
&#x9ED1;&#x4F53;
微软雅黑 Microsoft YaHei \5FAE\8F6F\96C5\9ED1 &#x5FAE;&#x8F6F;&#x96C5;
&#x9ED1;
Office
隶书 LiSu \96B6\4E66 &#x96B6;&#x4E66;
幼圆 YouYuan \5E7C\5706 &#x5E7C;&#x5706;
华文细黑 STXihei \534E\6587\7EC6\9ED1 &#x534E;&#x6587;&#x7EC6;
&#x9ED1;
华文楷体 STKaiti \534E\6587\6977\4F53 &#x534E;&#x6587;&#x6977;
&#x4F53;
华文宋体 STSong \534E\6587\5B8B\4F53 &#x534E;&#x6587;&#x5B8B;
&#x4F53;
华文中宋 STZhongsong \534E\6587\4E2D\5B8B &#x534E;&#x6587;&#x4E2D;
&#x5B8B;
华文仿宋 STFangsong \534E\6587\4EFF\5B8B &#x534E;&#x6587;&#x4EFF;
&#x5B8B;
方正舒体 FZShuTi \65B9\6B63\8212\4F53 &#x65B9;&#x6B63;&#x8212;
&#x4F53;
方正姚体 FZYaoti \65B9\6B63\59DA\4F53 &#x65B9;&#x6B63;&#x59DA;
&#x4F53;
华文彩云 STCaiyun \534E\6587\5F69\4E91 &#x534E;&#x6587;&#x5F69;
&#x4E91;
华文琥珀 STHupo \534E\6587\7425\73C0 &#x534E;&#x6587;&#x7425;
&#x73C0;
华文隶书 STLiti \534E\6587\96B6\4E66 &#x534E;&#x6587;&#x96B6;
&#x4E66;
华文行楷 STXingkai \534E\6587\884C\6977 &#x534E;&#x6587;&#x884C;
&#x6977;
华文新魏 STXinwei \534E\6587\65B0\9B4F &#x534E;&#x6587;&#x65B0;
&#x9B4F;

css行高问题

《CSS权威指南》中关于行高的描述:

从技术角度讲,一行中的每个元素都有一个内容区域,它是由字体尺寸决定的,内容区域又包含一个内联框,在没有其他因素的情况下,内联框刚好等于内容区域。如果行高使用的是缺省值NORMAL,行间垂直距离将会是用户代理的缺省值,它通常是字体尺寸的1-1.2倍。

行高设置的最好办法(我自己说的,不是Eric Mayer说的):设定一个数值,实际上是个缩放因子(scaling factor),当使用数字时,继承的就不再是计算值,而是这个缩放因子。这个缩放因子应用于这个元素及其所有子元素,因此每个元素都有一个关于它自己的字体尺寸的行高计算值。

如果是设定成百分比、px或pt的话,无论如何都会被作为带有单位的值来继承,比如说:

 
<style type="text/css">
 body{font-size:12px;line-height:150%;}
 p.p1{font-size:14px;}
</style>

<BODY>
<p>最新版《CSS权威指南》一书经过全面更新,涵盖了Internet Explorer 7,详细介绍了各个CSS属性以及属性之间的相互作用,并指导你如何避免一些常见的错误。不论你是一位经验丰富的web创作人员,还是一无所知的新手,都可以把它作为内容翔实的CSS参考资料放在手边。Eric A.Meyer。在HTML、CSS和web标准领域是国际上公认的专家,他从1993年就开始从事web方面的工作。他也是complex spiral consulting公司的奠基人,其客户包括美国在线、苹果计算机公司、富国银行和Macromedia等著名公司。
</p>

<p class="p1">最新版《CSS权威指南》一书经过全面更新,涵盖了Internet Explorer 7,详细介绍了各个CSS属性以及属性之间的相互作用,并指导你如何避免一些常见的错误。不论你是一位经验丰富的web创作人员,还是一无所知的新手,都可以把它作为内容翔实的CSS参考资料放在手边。Eric A.Meyer。在HTML、CSS和web标准领域是国际上公认的专家,他从1993年就开始从事web方面的工作。他也是complex spiral consulting公司的奠基人,其客户包括美国在线、苹果计算机公司、富国银行和Macromedia等著名公司。
</p>

</BODY>

在这个测试里,P1的行高不是想象中的14px × 150% = 21px,而是12px × 150% = 18px,因为父元素(也就是body)的行高是作为一个计算后的带单位的数值继承给P1的。而如果不写150%而写成数值1.5的话,P1的行高就将会是14px × 1.5 = 21px。

我检讨了一下为什么我以前没有发觉这个问题,原因就是我一直采用一个笨办法,反复的在各种元素里设置行高。

以前一直遇到各浏览器行高显示不一致的问题,没机会去深究,在互联网上找到资料先记录一下,待日后测试。另外近日对流式布局很感兴趣,虽然浏览器添加了缩放功能以后,这种布局已经可以不考虑了。

《IE和FF,行高不一致的解决方案》 原文地址:http://sundov.blogbus.com/logs/62465567.html

定义在LI上面
li{font-size:14px; padding-top:7px; height:18px;}

这里的行高,相当于24PX。

还可以保证IE和FF里面相对的一致,现在各个主流的网站都可以用。

利用background的百分数定位创建faux列

最近在修改一个流式布局的网站。以前几乎没有真正在实践中接触流式布局,今天遇到了这样一个问题:

流式布局的三栏式网站,由于左栏内容修改后非常短,原来又包含有背景色和边框等属性,所以背景色无法拉长到整个布局的高度。那么应该怎么做呢?很自然的想到了在包含着这三栏的父元素上创建一个伪列(人称“faux列”)来实现这种效果。

对于固定宽度的布局来说这是容易的,只需重复一个固定宽度的背景图片便可。但是对于流式布局来说却遇到了问题:因为流式布局是按百分比来进行布局的,在不同的浏览器分辨率下,各栏的实际宽度的是不同的。实在想不到办法的情况下去翻了一下《精通CSS——高级web标准解决方案》,想不到真的找到了答案哟:那就是使用background属性的百分数定位来处理背景图片!

关于background属性的百分数定位,书上如是说:“如果使用像素设置背景的位置,那么图像的左上角会定位在距离元素左上角指定的像素数的地方。如果使用百分数定位,就会对图像上的对应点进行定位。”

比如,如果将垂直和水平位置设置为50%,那么实际上会把图像上距离左上角50%的点定位到父元素上距离左上角50%的位置:

例如:background-position: 150px 150px;

position1
background-position: 50% 50%; 看到的却并不是如下的效果哦:

position2

而其实是这样的:

position3

说起来以前也是理解百分数定位的,只是一直不知道这样的定位究竟有什么作用,直到我遇到了今天这个问题。想来这确实是最佳的解决方案。如果还不明白的童鞋,模仿我遇到的问题做一遍会比任何时候理解得都透彻。话说在《精通CSS——高级web标准解决方案》这本书上我当时还画了不少横线的,呃呃,看来是白画了,实践才是王道啊。。。

一个滑动门的CSS实现

说起来,现在很少使用滑动门技术了;前不久有个小项目需要用到,由于时间紧迫又太久没有使用,做得有点马虎。下午闲来无事重新做了一个,一个图片实现,兼容IE6-8(原谅我直接忽略IE5)、chorm和FF。做个记录以备不时之需。

简单效果如下:

slideDoor

为了按钮能够自适应文字宽度,需要下面的图片:

test

代码:


<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "<a href="http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd</a>">
<html xmlns="<a href="http://www.w3.org/1999/xhtml">http://www.w3.org/1999/xhtml</a>">
<head>
<link href="css/global.css" rel="stylesheet" />
<title>XHTML-test</title>
<style type="text/css">
  #wrapper{width:90%;margin:0 auto;}
  #nav{width:100%;margin-top:10px;}
  #nav li{float:left;display:inline;margin-right:10px;}
  #nav a{float:left;display:block;height:26px;line-height:26px;padding-left:4px;background:transparent url(images/test.gif) no-repeat 0 0;color:#fff;}
  #nav a span{float:left;display:block;padding-right:4px;background:transparent url(images/test.gif) no-repeat right 0;cursor:pointer;}
  #nav a:hover{background:transparent url(images/test.gif) no-repeat 0 -26px;}
  #nav a:hover span{background:transparent url(images/test.gif) no-repeat right -26px;}
</style>
</head>
<body>
  <div id="wrapper">
    <ul id="nav">
   <li><a href="#"><span>tt1</span></a></li>
   <li><a href="#"><span>test2</span></a></li>
   <li><a href="#"><span>test3test3</span></a></li>
   <li><a href="#"><span>t4</span></a></li>
   <li><a href="#"><span>test5</span></a></li>
 </ul>
  </div>
</body>
</html>

还可以再简化一下:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "<a href="http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd</a>">
<html xmlns="<a href="http://www.w3.org/1999/xhtml">http://www.w3.org/1999/xhtml</a>">
<head>
<link href="css/global.css" rel="stylesheet" />
<title>XHTML-test</title>
<style type="text/css">
  #wrapper{width:90%;margin:0 auto;}
  #nav{width:100%;margin-top:10px;}
  #nav a{float:left;display:block;margin-right:10px;height:26px;line-height:26px;padding-left:4px;background:transparent url(images/test.gif) no-repeat 0 0;color:#fff;}
  #nav a span{float:left;display:block;padding-right:4px;background:transparent url(images/test.gif) no-repeat right 0;cursor:pointer;}
  #nav a:hover{background:transparent url(images/test.gif) no-repeat 0 -26px;}
  #nav a:hover span{background:transparent url(images/test.gif) no-repeat right -26px;}
</style>
</head>
<body>
  <div id="wrapper">
   <div id="nav">
    <a href="#"><span>tt1</span></a>
    <a href="#"><span>test2</span></a>
    <a href="#"><span>test3test3</span></a>
    <a href="#"><span>t4</span></a>
    <a href="#"><span>test5</span></a>
   </div>
  </div>
</body>
</html>

CSS文字排版的技巧记录

1、对于更有吸引力的段落排版,可以采用Robert Bringhurst的方法,它约定:用你的文字大小乘以30就可以得到段落的宽度。比如如果你的文字大小是12px,用30乘以它,也就是360px,这样每行大约可以呈现65个英文字符。(注意该技巧所指的是英文,但可以借鉴)

2、行高用来限定每行文字之间的空白大小。一个经验之谈就是让行高比你的字体大6-7px。比如,如果你的文字大小是12px,加上6px就是你的行高,也就是18px。

3、line-height是可以继承的,由于这个特性,子元素就可以不用重复定义line-height了。

但是只要有单位或百分比的line-height继承,都发生了重叠的现象。那到底这是什么原因导致的呢?

如果line-height属性值有单位或百分比,那么继承的值则是换算后的一个具体的px级别的值;而如果属性值没有单位,则浏览器会直接继承这个“因子(数值)”,而非计算后的具体值,此时它的line-height会根据本身的font-size值重新计算得到新的line-height 值。

From – http://www.css88.com/archives/1311

延伸阅读:

网页设计中的默认字体样式详解

CSS文字排版终极指南

常用Web字体的中英文以及字符混排效果

使用text-overflow:ellipsis对溢出文本显示省略号

使用text-overflow:ellipsis对溢出文本显示省略号有两个好处,一是不用通过程序限定字数;二是有利于SEO。需要使用对对溢出文本显示省略号的通常是文章标题列表,这样处理对搜索引擎更友好,因为标题实际上并未被截字,而是局限于宽度而未被显示而已。

通常的做法是这样的:


overflow:hidden;
text-overflow:ellipsis;
-o-text-overflow:ellipsis;
white-space:nowrap;
width:100%;

其中,overflow: hidden和white-space: nowrap都是必须的否则不会显示省略号;-o-text-overflow: ellipsis针对Opera;而宽度的设定主要是针对IE6;

该方法支持Internet Explorer, Safari, Chrome 和 Opera,但FF并不支持,不过可以通过Jquery来实现类似的效果。

下载这个Jquery插件:jQuery ellipsis plugin

调用方法:


$(document).ready(function() {
    $('.ellipsis').ellipsis();
}