看来必须抡胳膊上了。本来是准备交给别人去做,结果最后人没来公司……这样不得不自己动手把代码全部重写。今天终于搞定一大部分,受益匪浅。
其实什么事情一定要投入时间投入精力才能做好,如果为了完成认为,为了用div而用div,那意义何在呢?
非常感谢David和old9抽出时间帮我解决了不少问题,技术和思想上的。
==项目随笔==
对于标准,我没有那么大的热忱,也不是什么绝对簇拥。如果感兴趣,这几篇文章足以解释标准的存在缘由和相关问题。
浏览器大战
也许,我们应该放弃#wrapper
了解真相,到底什么才应该是Opera的BUG,我们应该找谁去抱怨
==资源==
http://www.w3.org/TR/CSS21
我一直坚信,作为一个企业,它关心的应该是如何最大限度发挥div+css的优势;它关注的应该是产品的易用性、兼容性以及执行效率的问题。因此不得不再次重申,我根本没有打算让每一个页面都通过w3c的认证,我决不会为了通过认证而把5k的代码改称7k的或者把消耗3%的CPU的解决方案改称消耗4%的。
回到当初讨论的话题,div+css的优势。其实之前我已经总结过了div+css的优势。但是当我跟着具体项目深入的时候才发现必须贯穿这种思想才能把事情做好。当然,这是要付出代价的,比如加班阅读文档、频繁地去论坛请教。但我觉得作为一个项目的负责人员,这些问题是不能回避的。躲得了初一,躲不了十五,现在把内容勉强显示好了,日后改版怎么做?日后套动态网站怎么做。内容和样式的不彻底分离将会使得后续的维护成本极高,无奈的是,没有人在乎这个成本,因为没有人指望去维护,他们只会改版改版,再改版。
就直接说项目第一轮改版,仍然存在许多问题。把一大堆的描述样式的img标签放在非css的路径下,这本身就是一个不正确的做法。div+css的本意就是为了让搜索引擎能更加直接、便捷的基础到内容。搜索引擎不会关心你的样式,更不会关心你用了什么图片来修饰网页(注意,这里的图片特指那些修饰网页的图片)。对于非语义标签(比如<hr>、<br>这些标签,也可以理解为勇于显示内容的标签),应该尽量避免其在HTML中的出现。当然,这一点真正制作网页的时候才深有体会。起初我也觉得有些地方用hr标签实现起来挺方便,后来才发现这种做法是与div+css以及SEO的思想违背的。<hr>标签完全可以巧妙的用border来代替。而<p>在逻辑上则更优于<br>。
今天一个朋友,也是做网页设计的,这样抱怨道:“要不是为了兼容性,我才不会装Firefox呢”,我的回答是“要是你不看好FF,你干脆别顾虑其兼容性了”。其实很多项目设计、开发人员为了偷懒而放弃对FF的兼容,这是一件非常不负责任的行为。不过如果你确实不是因为偷懒,而是因为相信IE能继续垄断而节省自己的调试时间去为企业做更多贡献,我肯定是发自内心的支持的。
附:Firefox和Oprea均拥有比IE更好的文字渲染引擎,请用ie和Firefox访问我的blog,看看鼠标滑过标题的移动速度就知道了。
关于list-style失效的问题
无论是列表本身(ol, ul) 还是单个的列表元素(li),拥有 layout 后都会影响列表的表现。不同版本 IE 的表现又有不同。最明显的效果就体现在列表符号上(如果你的列表自定义了列表符号则不会受这个问题影响)。这些符号很可能是通过某种内部机制附到列表元素上的(通常是附着在它们外面)。不幸的是,由于是通过“内部机制”添加的,我们无法访问它们也无法修正它们的错误表现。
最明显的效果有:
列表获得 layout 后,列表符号会消失或者被放置在不同的或者错误的位置。
有时它们又可以通过改变列表元素的边距而重新出现。这看起来似乎是以下事实导致的结果:layout 元素会试图裁掉超出其边界的内部内容。
列表元素获得 layout 之后,会有和上面一样的问题出现,更多参考 (extra vertical space between list items)http://www.brunildo.org/test/IEWlispace.php
进一步又有一个问题就是(在有序列表中)任何具有 layout 的列表元素似乎都有自己独立的计数器。比如我们有一个含五个列表元素的有序列表,只有第三个列表元素有 layout。我们会看到这样:
1… 2… 1… 4… 5…
此外,如果一个有 layout 的列表元素跨行显示时,列表符号会底部对齐(而不是按照预料的顶部对齐)。
以上某些问题还是无法解决的,所以如果需要列表符号的时候最好避免让列表和列表元素获得 layout。如果需要限定尺寸,最好给别的元素设定尺寸,比如给整个列表外面套一个元素并设定它的宽度,又或者比如给每个列表元素中的内容设定高度等等。
另一个IE中列表的常见问题出现在当某个 li 中的内容是一个 display: block 的锚点(anchor)时。在这种情况下,列表元素之间的空格将不会被忽略而且通常会显示成额外的一行夹在每个 li 之间。一种避免这种竖直方向多余空白的解决方法是赋予这些锚点 layout。这样还有一个好处就是可以让整个锚点的矩形区域都可以响应鼠标点击。
作者blog @ http://www.jluvip.com/blog
解决方案-用js动态写入li序列… -_-
float的闭合
在float元素间增加一个标记
这个样式定义为:
{
clear:both;
}
我个人摸索的最好的div居中方法
{
width:xpx;
margin:xpx auto;
}
注意,一定要设置width,否则靠左。
我个人概括的图片存放规则
一、非语义图片(就是指那些表现样式的图片)存放于styles/images下
二、样式图片尽量在CSS中体现,可以用background+text-indent来配合完成,对于非块元素,用display:block使得text-indent属性生效
关于strong标签重写的好处
对于特定的内容,如果要进行强调,又需要设置自己的样式,可以不必另行定义div,而用strong标签的重写。
例如如下的HTML代码:
<strong>我是强调的内容</strong>,我是普通的内容
</div>
对应的CSS文件如下:
{
font-weight:normal;
color:#f00;
}
这种方法从语义上来说是非常利于SEO的。
令人发指的IE
当box为float时,IE下面会使得margin加倍。真是莫名其妙……IE6页没有解决这个问题。
解决方法是float后续标签闭合(见前),并且给float的fox赋以“display:inline;”的属性,至于这该死的
display:inline是什么意思,我实在是不明白……
不管怎么说,问题解决了,感谢David!
另外一个IE的sbbug
当Windows样式主题为XP样式时,所有的按钮不能定义background-image,只能定义background,也就是说
{
…
background:url(images/reg/login.gif) no-repeat;
…
}
可以,然而
{
…
background-image:url(images/reg/login.gif) no-repeat;
…
}
就不行了!
唉!不过加上background-color:transparent;之后就好了!
感谢old9~
换行打破float的问题
假设布局
A|B
div B标浮在A的右侧,这时候如果不设定B的宽度,则B很可能由于内容过多而撑破大的布局,跑到A的下面,形成
A
B
的局面。
因此一定要注意设置B的宽度。
IE与FF对宽度的理解不同
在IE中,如果子元素宽度超标,会自动“撑破”母元素,而FF不会,所以常用FF调试的时候,一定要确保子元素width小于母元素。
不管是IE还是FF, border都是跟padding走的。而width则在IE和FF有不同的理解,准确地说,border会跟width+padding走!
本文来自:http://www.awflasher.com/blog/archives/634
Google更注重原创、时效性好的文章:
| 相关阅读 | 本月十大 |




呵呵 确实没有必要为了div而用div
table在数据表现方面还是有很大的优点
这就是中国…
廉价劳动力, 呵呵…
会html不够,要会javascript, 会javascript不够,要会flash, 会flash不够,要会asp/php/jsp/.net中的一点, 会那些还不够, 还要会ajax…
这样的情况似乎在中国特别明显…
table在数据表现方面还是有很大的优点
本来XHTML+CSS的本意也是这个,只是用DIV+CSS来布局,而对于数据表现则使用TABLE
不断学习,勇于创新
团结紧张,严肃活泼
我说你就别 div+css 了, 太别扭了, 标准又不只是 div+css, 改叫 xhtml 吧,
to kakera
不是为了div+css而div+css,更不是为了标准而div+css……:)
这个问题还在讨论啊。。我也打一点我个人的看法哈。
对于所有的浏览器来说,网页的标准是相对的,你的代码写得再漂亮也不可能满足所有的浏览器,不过有时仅仅是大部分就够了。。
有没有办法实现对任一浏览器绝对的标准呢?
有。。
那就是大量运用图片(或和图片差不多的FLASH),而且图片的个数是越少越好(一个页面一个图片极好)。呵呵,韩国人早想到了。。。。
因为国内如此的网络环境,才会有大把的人把国外的标准化喊得这么响(那些订规矩的老外不知道多感谢偶们呢),韩国网络环境好,
WEB全部图片化都无所谓,所以你会看韩站上大把大把的运用图片和FLASH(你看的显示器显示的一个平面,图片就是为表现平面而存在的,所以没有比图片更能表现和说明一个东西的。如果你举些另类反驳,那就是图片实现方式比较复杂化一些。而且还有一个好处就是可以极大的减少代码量,图片只是个下载显示的过程,而大量的代码运行须占用相对的服务器资源。以前一个老程序员跟我说的。呵呵)。
未来的WEB程序将会“胖(RIA)”化,现在就有一些相关的开发环境了(我玩过的:FLASH|FLEX,Laszlo),还有
即将运行在微软在VISTA上的。所以那时,标准化就会成为一堆废纸。嘿嘿。。
首页声明一下,国内是要标准化的。。比个不恰当的比喻:不标准化就相当于ML不戴套 [razz] 。
因此染上AIDS和失去回访客都是不好的。
所以,要么改善国内的硬件环境,之后,各位设计同行们就大把地运用图片和FLASH吧或其它。。哈哈。这个也不是我们现在能做得到的。
所以,上面说的都是废话了,大家还是去修练怎么标准化网页吧,因为BOSS需要。
最后。如我是BOSS,你是DIV+CSS还是XHMTL+CSS都无所谓,只要别让我染上AIDS。。。
最后发现,写AW的BLOG比写自己的BLOG都认真啊 [redface] 。。
@Blank.感动啊%_%
其实你写我的blog卖力,也许是因为某一些原因,总之我觉得挺遗憾,如果我能早加入公司,绝对会让HR慎重考虑你…人才流失啊…
而大量的代码运行须占用相对的服务器资源。以前一个老程序员跟我说的。呵呵
说错了,只有服务器的脚本才会占用服务器的资源.普通的html是不会的.这里只一个请求和响应的问题.另,javascript也是在客户端解释的.而不是在服务器端.
至于这该死的display:inline是什么意思,我实在是不明白……
利用这个display:inline确实解决了问题,汗。
[url=Http;//www.topcod.com.cn]中山干燥剂,佛山干燥剂,深圳干燥剂[/url][url]www.topcod.com.cn
[/url]