Html+CSS 在
网页构建（Web Page Building） 中的应用已经不是什么新鲜事了。轻盈的
Div布局 方式替换了笨重
Table布局 方式。而在
Div布局 方面多数人使用的是
float方式 ，Div 在 float 的控制下忽左忽右好不自在。但我们今天要说的不是 网页构建 ，而是
B/S结构 软件界面构建。所以我想介绍另外一种方式
position方式 。我个人比较喜欢这种方式，虽然很多人认为把 Div 的
position属性 设置为 absolute 后用 top属性 和 left属性 在页面中随意定位进行布局是一种极端菜鸟的方式，但在
B/S结构 软件界面构建过程中这种
position方式 的灵活绝对会给你带来意想不到的效果。当然我所说所写
position方式 还存在很多的不足之处，这只是为了抛砖引玉，来给大家打开一个话题。
引用:
闲话：
既然我们是在说 B/S结构 软件界面的构建，那就先来介绍一下 B/S结构 吧！
B/S结构（Browser/Server结构） 即 浏览器和服务器结构 。它是随着Internet技术的兴起，对 C/S结构（Client/Server结构） 的一种变化或者改进的结构。在这种结构下，用户工作界面是通过浏览器来实现（也就是说 B/S结构 软件界面可以被理解为是建立在现有浏览器所能解释的 Html；CSS；Scrip等基础之上特殊的网页），这也就使得其具有了 C/S结构 所不能比拟的跨平台性等优势…… （详见： http://baike.baidu.com/view/679018.html）
说完 B/S结构 让我们来说说既然 B/S结构 软件界面（其实就是一种特殊用途的网页）和普通网页有什么根本性的区别呢？
一、整页滚动。我个人不建议在 B/S结构 软件界面中使用整页滚动。因为浏览器滚动条的实在是为了当初方便阅读那些绵长的文章，这样的阅读习惯也促使了之后的网页也变得绵长。不过作为网页这也没什么不好（你完全可以将这理解为现实生活中把小说印在卫生纸上来供人们阅读，拉动滚动条就好像是向上抽出更长的卫生纸），但作为软件界面，其强调的更多是控制而不是阅读，整页滚动条就显得不那么合适宜了。在我的观念中软件界面设计时应尽可能的将一类操作在一个界面上显示出来，而不是还有一部分（也许这是更重的功能）隐藏在下面需要拉动滚动条（试想某个核大国的总统在按动核按钮后才发现滚动条，而下边的页面是警告说对方遭受核打击后很快会进行核报复…… 所以我们要坚决反对使用核武器 ：p） 。即便是受到屏幕尺寸的制约也尽可能的使用局部滚动条或者干脆使用 Step-by-step方式 来解决。你什么时候看见操作系统（不论是糟糕的Win或是优秀的Mac）中在设置的界面中使用滚动条（有一个例外是iPhone，它在很多的设置界面中都使用了滚动条，但它有让人叫绝手指控制滚动的方式来弥补这一点） 。
二、尺寸适应。分辨率一直是困扰网页设计者的问题，在网页设计中大多还是集中在页面宽度的问题上。适应800px还是1024px，这就好像当年哈密雷特口中的 "To be or not to be"，近年来随着显示器的变革这个问题还在愈演愈烈，除了刚刚说的2种分辨率，也许很多设计师脑中已经开始考虑1280px这个宽屏分辨率甚至更高的分辨率。当然也有的设计师干脆就只为800px，说这也是个不错的兼容性考虑，可惜我那1920px的显示器啊整天闲着两边。在 B/S结构 软件界面中从来没有这么简单的办法，因为复杂的功能可能有着大量的操作设置或数据显示，一丝一毫的空间都不容的浪费。并且上一条也指出我们不想用整页滚动条来解决问题，这带来的不单是显示面积的限制，还有就是我们需要考虑的是宽度和高度双重尺寸适应问题。不单单是显示器分辨率，当浏览器不是最大化时界面同样要适应（Mac系统根本就不存在最大化），也就是说界面要时时应对浏览器窗口尺寸大小而调整。所以利用一切可能的手段使页面可以自动适应浏览器窗口尺寸就成为了棘手但却是必须去做的事情。又由于这个问题同时又衍生出的新问题是软件界面在自动适应时不同区域不会是等比缩放尺寸的，势必有些区域随之放大缩小而有些区域固定不变。这一点可以参照 C/S结构 软件界面，以大家常用的网页制作工具Dreamweaver为例，主要的代码显示区域是随窗口尺寸的调整而调整，但上边的菜单及功能按钮区域、下边的属性及结果区域、右边的功能区域都是固定不变的或者单方向调整的（只调整宽度或者高度） 。
三、布局结构。在布局上 B/S结构 软件界面和网页设计上有相同的地方，结构无非就是"上-中-下" "左-中-右"，更复杂的结构也可由这2种衍生出来。但由于上一条后半段的所指出的问题，在布局时我一般倾向于将区域分成两类来对待：一类是主区域，页面中一般只有一个主区域，用来显示主要数据，当应对浏览器窗口尺寸变化时界面主区域随之变化尺寸；另一类是辅区域，页面中可以有多个辅区域，当应对浏览器窗口尺寸变化时界面辅区域固定不变或单方向调整。另外还有被我之前迫害了半天的滚动条。在 B/S结构 软件界面中我建议尽量在同一界面上只使用一个滚动条或一对滚动条（X轴和Y轴），因为在同一界面上出现的多个滚动条会让用户感到茫然。如果其他区域有滚动显示的需求时尽量用一些其他的方式来替代系统提供的滚动条。这唯一的滚动条一般被使用在主区域中，因为主区域即作为应对浏览器窗口尺寸变化而变化的区域，就表明了它可能对显示内容有较大量的要求，在低分辨率或窗口尺寸较小下的情况下滚动条会帮助其来完成任务。有了这些只是X轴和Y轴的问题解决了，有时在 B/S结构 软件界面实现中还要涉及Z轴的问题，这是网页设计中一般较少见的。
开篇还没写什么呢就写了这么多的闲话，我这个人就是这个优点：比较能跑题！闲话还是留着以后再说，先转入正文吧！
在根本上是利用了
Html+CSS 的
盒模型，在这里我就不过多的解释
盒模型 了。但要说的是由于不同浏览器或相同浏览器不同版本
（且不说哪个浏览器的好坏，但同浏览器不同版本的极大差别只有某公司的某种浏览器的6.0版本和7.0版本才有这样的如黄色粘稠物一样的问题）之间的兼容性问题我们是采用了2种方式利用
盒模型 的。这2种方式分别来自 IE6.0 的
非标准盒模型 及 Firefox 为代表的
标准盒模型 。
说道解释
盒模型 我们不能不提一下
DOCTYPE，因为
DOCTYPE 对浏览器解释
盒模型 有着非常大的影响。尤其体现在 IE6.0 的
非标准盒模型 的解释上。这其中的差异我就不多说了，这样的文章远有比我写的好的。在这里我只说一下我的做法：
代码1-1
提示：您可以先修改部分代码再运行
很多人可能会说我的
DOCTYPE 写的有问题，因为按照标准
DOCTYPE 必须要书写在文件的首行。这可不是我发明的写法，最早看到这种写法是在 Adobe.com
（最近改版的版本已经放弃了这样的写法） 。第一行是声明
XML文档 编码为UTF-8，第二行是声明
DOCTYPE 类型 为 xhtml1-Strict 。其实这算是
DOCTYPE 的一种Hack写法，由于
DOCTYPE 没有写在第一行 IE6.0 及以下版本浏览器不解释，而 IE7.0\Firefox\Opera\Safari 却可以解释。我测试了很久发现这确实是一种不错的选择，因为
DOCTYPE 没让IE6.0变得更好反而更糟。所以我之后的
盒模型 都是基于这种
DOCTYPE 写法基础来解释的。
先来说 IE6.0 的
非标准盒模型，让人郁闷的是这个
非标零件 因为他的广泛使用却成为了我们必须考虑的标准。IE6.0在解释
双盒嵌套 （<div><div></div></div>） 中，子Div宽度被设置为100% 时其真实宽度为 父Div 宽度 – 父Div 边线宽度 - 父Div 内补丁宽度。父Div 真实宽度为设置宽度。
代码1-2
提示：您可以先修改部分代码再运行
以上边代码为例
（见代码1-2），
父Div testDiv1 的真实宽度为设置的宽度600px，
子Div testDiv2 的真实宽度为600px - padding-left:100px - padding-right:100px = 400px
这代码对我们有什么意义呢？看一下 代码1-2 的页面
（IE6.0浏览器），从左到右分别是 黄-蓝-黄，这有没有点像是”左-中-右”的布局结构呢？让我们修改一下代码再看看。
代码1-3
提示：您可以先修改部分代码再运行
看一下 代码1-3 的页面
（IE6.0浏览器），从上倒下分别是 黄-蓝-黄，这有没有点像是”上-中-下”的布局结构呢？可能你会想我是不是疯了！这个谁不知道啊！这是最简单不过的代码了……
让我们来让这些代码变得更有意义吧！在这之前我们需要先要引入一段基础代码。这段代码是我在做 B/S结构 软件界面时所倾向于的做法。它可以帮助我们将页面格式化为无整页滚动条，并根据浏览器窗口尺寸时时自动适应。
代码1-4
提示：您可以先修改部分代码再运行
看一下 代码1-4 的页面，并试着改变你浏览器的窗口尺寸。你会发现你得到了一个我许诺给你的。这段代码兼容 IE6.0\IE7.0\Firefox\Opera\Safari 。其实这个是我对
body标签 利用
position方式 的重构。你也可以记住这种方法，因为接下来我们很多时候都会用这种方法。
好了，让我们利用这段基础代码使之前再简单不过的代码变得有意义吧！'
代码1-5
提示：您可以先修改部分代码再运行
看一下 代码1-5 的页面
（IE6.0浏览器）， 展现在你面前的是一个标准的”左-中-右”布局结构。
mainDiv 是
父Div，
middleDiv 是
子Div 也是
主区域，
middleDiv 利用了其
父Div 的
padding属性 来为两边的
leftDiv rightDiv 子Div 也是
辅区域 Div留出空白。
mainDiv 相对
Body 宽度值是100%，
middleDiv 相对
mainDiv 宽度值是100%，这就使得
middleDiv 的宽度相对浏览器窗口尺寸是自动调整的，高度亦同。
leftDiv rightDiv 分别利用
left:0px; 和
right:0px; 来相对定位居左或居右对齐。试着改变你浏览器的窗口尺寸，看看效果吧！
你可能会说：”这算什么？
float方式 也可以啊！CSS的代码还比这个简单呢！”
那让我们来修改一下代码吧！这样可以实现的”上-中-下”布局结构，并且相对浏览器窗口尺寸是自动调整。这是
float方式 不能实现的。
代码1-6
提示：您可以先修改部分代码再运行
这里要说明的是在 代码1-6 中的
bottom:-1px; 这是因为IE6.0浏览器对CSS解释错误而产生的手动修复，当
子Div 使用
bottom属性 并且其
父Div 的高度
真实值 为单数时，
子Div 的
Bottom属性 在浏览器表现出的
真实值 比
设置值 大1px。
不知道你看明白这些代码了没有，这些就是我所谓的
position方式 来实现的结构布局。你可能要说：”拽什么拽啊！你看看你的方式在Firefox中的样子吧！” 别急啊！之前不是说了么由于兼容性问题我们是采用了2种方式利用
盒模型 。现在让我们来说另外一种吧！
Firefox 为代表的
标准盒模型 这才是未来的王道。现在的 IE7.0\Opera\Safari 都可以非常好的遵循
标准盒模型 。
标准盒模型 在解释
双盒嵌套 （<div><div></div></div>） 中，
子Div 宽度被设置为100% 时其真实宽度为
父Div 的设置宽度。
父Div 真实宽度为设置宽度 +
父Div 内补丁宽度 +
父Div 边线宽度。也就是说
父Div 的盒被撑大了。并且在
标准盒模型 中通常
height属性 是无效的。那我们有什么办法能解决这样的问题呢？看下边这段代码。
代码1-7
提示：您可以先修改部分代码再运行
看一下 代码1-7 的页面
（Firefox浏览器），发现
mainDiv 并没有被 padding 和 border 撑大了。这正是利用了
body>#mainDiv 这一种CSS的Hack写法来解决了问题。具体的我就不多说了，想必大家一眼就能看明白
（其实就相当于你告诉浏览器说：我要做一个盒子，盒子大小你看着办，但盒子的左边和右边都要距离墙0px远） 。但
padding属性 还是在很多时候影响了
position方式 ，所以我们尽量不在
标准盒模型 的布局中使用它。可回想一下在
非标准盒模型 中
padding属性 可是非常重要的一部分。那么为了兼容2种模型，我们使用另一种CSS的Hack写法，在CSS属性前边加”_”来使这一属性只有IE6.0才能识别并解释，而
标准盒模型 的浏览器都不能解释这一CSS属性。
未完待续……
[
本帖最后由 wiseinfo 于 2007-12-23 05:59 编辑 ]
