“szzkzs”通过精心收集,向本站投稿了5篇关于float的一个小问题网页设计,下面给大家分享关于float的一个小问题网页设计,欢迎阅读!

篇1:关于float的一个小问题网页设计
最近遇到一个不太容易注意到的关于Float的问题,如下:
当结构为float leftblock,样式为.left { float: left; width: 50px; height: 50px; background: #000; }.block { width: 200px; height: 60px; background: #F60;}
假使我们称第一个div为A,第二个div 为B,按理说,float使元素脱离正常流(Normal Flow),A应该“浮”起来,盖在B上面;而B应该占据A原来的位置。
事实上, 在现代浏览器中,显示方式跟我们想象的完全一致,如下:
但在IE6和IE7下,发现很诡异的问题,其显示方式如下:
我们可以看到,A并没有完全脱离正常流,还占据着原来的位置,而B跟随A出现(A和B之间有3px间隔,IE6下的bug,IE7的显示方式与 上面相同,只是没有3px的间隔)。
这是为什么呢?
根据CSS1对float的规定:The normal flow will wrap around on the right side。也就是说对于左浮动的元素,其后的正常流将围绕在其右边。
而在CSS2中, 明确说明:Since a float is not in the flow, non-positioned block boxes created before and after the float box flow vertically as if the float did not exist。也就是说浮动元素脱离正常流以后,浮动元素前后创建的未定位的块级元素会垂直相连,好像浮动元素不存在。
在 CSS2中,明确说明了浮动元素的位置会被占据(在direction:ltr的正常流下,为后面的占据),而在CSS1中,说得很含糊,没有具体说明块 级元素是否会占据前面浮动元素的位置。
为了了解是否所有只支持CSS1的浏览器对于这种情况的处理都一致,我安装了Netscape 6.2.3,其显示方式如下:
可以看到,和现代浏览器的显示方式一模一样,
难道又是IE对规范有着自己独特的理解?为此,我查询了一下微软的技术文档,其中写 道:Objects following a floating object move in relation to the position of the floating object。也就是说,浮动对象后面的对象按相对于浮动对象的位置移动。其实这也是一种很模糊的说法,并没说明后面的块级元素是否会占据前面浮动元素的位置。
由此可以推测,一般浏览器认为,对象如果脱离正常流,就不会占据其原来的位置,所以对于左浮动的元素,其后面的块级元素将会占据它的位 置,呈现浮动元素盖住后面元素的情况。
而对于只支持或部分支持CSS1的IE,则认为虽然浮动元素脱离正常流,但其后的正常流将围绕在其右 边,呈现了半脱离的情况,左浮动元素后面的块级元素跟随在其右边。
另外还有一个问题。对于上例,当对B设置左边距(margin-left) 时,对于IE6和IE7存在一个临界值,当margin-left的值小于这个临界值时,设置不起作用,当大于这个值时,才起作用,这个临界值恒等于A的宽度。
我们可以这么认为:A脱离正常流,正常情况下,B的左边距(margin-left)应当直接接触到其容器(body标签)的左填充边 (padding-left),对于此例,其容器不存在左填充,所以原本B的左边距应当直接接触容器的左边(即margin-left等于0),但由于在 IE6和IE7中,B跟随在A右边,相当于A把B从容器的左边顶开了,且左边距又没有发生变化(即margin-left还是等于0),所以,当B的左边 距小于等于这个临界值的时候,都不起作用。
PS:正常流(Normal Flow)
正常流是默认的定位方式。任何没有具体指定{position:absolute}或者{position:fixed}属性以及没有被浮动的元素 都将默认获得此属性。在这种方式里,块级元素在它们的包含块里一个一个垂直延伸,行内元素在它们的包含块里从左至右的水平排布。
本文来自:www.tgideas.com/?p=982
篇2:position替代部分float进行定位网页设计
CSS 定位机制
CSS 有三种基本的定位机制:普通流、浮动和绝对定位,
position 属性值的含义:
static
元素框正常生成。块级元素生成一个矩形框,作为文档流的一部分,行内元素则会创建一个或多个行框,置于其父元素中。
relative
元素框偏移某个距离。元素仍保持其未定位前的形状,它原本所占的空间仍保留。

absolute
元素框从文档流完全删除,并相对于其包含块定位。包含块可能是文档中的另一个元素或者是初始包含块。元素原先在正常文档流中所占的空间会关闭,就好像元素原来不存在一样。元素定位后生成一个块级框,而不论原来它在正常流中生成何种类型的框。
fixed
元素框的表现类似于将 position 设置为 absolute,不过其包含块是视窗本身。 (ie6秀逗了)
(以上文字纯为凑字数,来自www.w3school.com.cn/css/css_positioning.asp)
————————————-
为什么使用定位
1.html代码结构简单;
2.思路清晰;
3.减少reflow;
可能存在的问题
1.有人说耗性能;(没觉得,也没官方说明,
)
2.经常出现bug; (因人而异。)
写代码的时候,思路是非常重要的,整理好思路,然后写代码,效率会提高很多。
相反,你看到一堆东西要写,思路不清晰,容易烦躁,写出来的东西就跟那什么什么一样,自己都看不下去,关键问题是,自己还懒的改,这就是传说中的坑。
网页制作 —>前端重构
一个是代码上的重构,还有一个是人自己思想上的重构,
对于每个元素有自己的理解和感情。
如果千篇 一律,写着一样的代码,就跟一个没感情的机器人一样,
本来前端的工作就比较枯燥,
自己再不找个乐子,那就对不起自己了。
篇3:支付宝交互设计中的一个小问题交互设计
个人对交互设计的了解并不多,这里从一个用户的角度来谈一谈支付宝中一处很不好的交互设计,
由于负责 CPH 合租服务器的收款事宜,每次都会接受参与者通过支付宝直接付款功能转过来的钱。在这个过程中,只要是第一次使用该功能的用户,95%以上都会犯一个同样的错误。即在付款过程中会来询问我的姓名,而我了解的是该付款过程并不需要收款方的真实姓名啊,只需要支付宝账户便可。由于此类情况发生率太高,根据个人对交互设计的理解,这应该不是用户的问题,而是设计的问题了。具体情况如下所示:
上图是在使用该功能时的收款方信息输入区域,用户往往在第一个输入框中填入支付宝账户,而对第二个输入框则都认为需要填入收款方的姓名,而设计者的初衷是想用户再次确认账户。为什么如此多的用户都犯同样的错误呢?个人觉得有以下几点:
一:用户固有的概念模型
用户在现实生活中对转账这种行为的固有概念模型是需要向银行提供收款方的帐号以及姓名(ATM机除外),而当同样的行为转移到网上时,用户会以固有的模型去思考,便下意识地认为需要提供收款方的真是姓名,
二:支付宝措辞的问题
简单说就是在交互设计中没有对用户进行合理的引导。设计者在这儿希望用户再次输入账户进行确认,不过使用的措辞却是“收款方账户名确认”,让我们来看看大多数设计者在这样的情况下是怎么做的:
如上所示,在需要重复输入信息的情况下,几乎都是用的是“确认/重复/再输一遍……”,将强调重复的词放在需要被重复输入的信息前面,一是符合用户阅读的先后顺序,也是配合用户的固有概念模型和用户习惯。因此支付宝要改的话,这个必须得改才行。
另外就是“收款方账户名”里面的这个“名”字, 我想很在一定程度上对用户的理解造成了干扰,让用户想到姓名。没想通支付宝的人为什么要加这个“名”呢?直接用“帐号”不就行了吗?当然这个理由纯属搞笑,:)
希望大家发表自己的看法,如果有支付宝的相关朋友路过,还请多多指教。
来自:www.ilmay.cn/post/alipay-ue.html
篇4:一个demo引发的争议网页设计
在某论坛上(不打广告)看到一个让我很惊艳的CSS效果,
它是鼠标左右滑动来实现3D的动态效果,个人觉得是个很赞的效果,感觉非常的莎士比亚,非常的歌剧啊~~~~不过也引发了一场争论。争论分为两派:“坚决顶起”派和“不以为然”派。“坚决顶起”派认为果然CSS是很强大的东西,这个demo的效果很酷很赞,很值得推崇;而“不以为然”派却认为,CSS应该用在正途上,不要做这些无谓的事情。
个人加入的是“坚决顶起”派。
从零开始接触CSS只有短短半年,在这半年里面看到CSS的不断完善和强大,不断的催促自己追赶着它的脚步(有点小清新了…咳 ⊙n⊙b)。
举个感触最深的例子吧~
这就是我对HTML的理解,是最原生态的美。当CSS出现后,我们就不仅限于单一的表现形式,我们渴望更多的色彩和线条。
这是CSS赋予HTML的,淡妆的美。简洁的背景色加上明朗的线条,给人以素雅幽静。
这是CSS背景图赋予HTML的,浓妆的美,
各式各样的效果,只有想不到,没有图片做不到。虽然图片能呈现出琳琅满目的样子,却也掩盖不了其自身存在的问题。
这是CSS3赋予HTML的,相宜的美。比淡妆稍浓,比浓妆稍淡。CSS3的各种新属性,让原本需要图片才能完成的样式得以解脱,让加载变得更加流畅。
CSS所有的进步都围绕着用户的感官体验,其目的就是为了呈现出视觉的饕餮盛宴。如果是这样,那CSS就必将进步,必将为用户带来更新奇的视觉享受。
在使用CSS1的时候,我们能想象出在未来的某一天,CSS可以实现圆角、阴影甚至是动画吗?同理,在网络高速发展的今天,我们已然觉得CSS3足够强大,但是在未来的某一天,难道不会出现令我们更加惊艳叫绝的CSS4、CSS5吗?
似乎有点跑题了,再拉回来。
这个demo并没有利用大热的CSS3,而是一层一层的迭代背景图,实现3D效果。代码很复杂,我一时半会儿也难以理解,不过这并不影响它的观赏性。这是一个创意,一个灵感。也许现在的页面暂时用不到,但是未来的事情谁又能吃的准呢?也许在 CSS4中出现了background-move属性也未可知啊(无限YY……)。
附上demo地址:ued.ctrip.com/blog/wp-content/uploads//10/new21.html
篇5:firstletter的一个小妙用网页设计
OL定义有序列表的时候,除非指定list-style-position:inside;,否则文字和前导符是有缩进的,
但有的时候,OL定义的列表类型有限制,比如不能定义汉字的“一、二、三”,我们只好手动来输入这些字符,但这下文字和字符连在一起。
运行代码框
[Ctrl+A 全部选择 提示:你可先修改部分代码,再按运行]
这个时候就可以使用first-letter这个伪类来帮忙了:
运行代码框
[Ctrl+A 全部选择 提示:你可先修改部分代码,再按运行]渲染结果:
这下,前导符就和文字保持一定距离了,而且能控制的样式也更多一点。
不过前导符后面那个顿号就控制不到样式了,但我想可不可以设置背景图来取代呢?
简单测试却发现,控制first-letter伪类的背景,与控制list-style-image一样让人琢磨不透,遂弃之。
另外,各个浏览器对待前导符旁边的符号处理方式也不一样,因为没有安装Safari,所以没有测试它:
代码:
IE8和FF3和Opera表现一致,Chrome只对左侧的符号进行处理,IE6、7就只处理了第一个字符。
本文来自:bbs.blueidea.com/thread-2973723-1-1.html









