“滑动门”的版本间的差异
来自Blueidea
小 （→将链接更改为适当的锚文本） |
|||
| （未显示3个用户的9个中间版本） | |||
| 第1行： | 第1行： | ||
| − | + | 滑动门是一种利用[[CSS]]来控制自适应导航栏外观的一种技术。 | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| + | 滑动门使用最频繁的地方是导航栏。其实，当一个容器中的文字数量不定的时候，而需要背景自动反映这一变化，都可以考虑使用滑动门。 | ||
当满足以下条件，则可能需要使用到滑动门技术： | 当满足以下条件，则可能需要使用到滑动门技术： | ||
| 第13行： | 第10行： | ||
在制作滑动门以前，您需要斟酌到底能不能用低成本的方法实现。不是所有的效果图上的自适应导航都能用滑动门来实现。壁如，当效果图上的文字使用了特殊效果（阴影，浮雕，外发光等等），因为无法通过修改xhtml中的文字,来达到修改图片上文字，因此，滑动门在这种情况下并不适用。 | 在制作滑动门以前，您需要斟酌到底能不能用低成本的方法实现。不是所有的效果图上的自适应导航都能用滑动门来实现。壁如，当效果图上的文字使用了特殊效果（阴影，浮雕，外发光等等），因为无法通过修改xhtml中的文字,来达到修改图片上文字，因此，滑动门在这种情况下并不适用。 | ||
| + | 在[[CSS 2.1]]环境下，'''滑动门导航至少需要2个标签配合才能完成实现'''。 | ||
| + | |||
| + | |||
| + | |||
| + | == 范例 == | ||
| + | *[http://www.w3cn.org/article/translate/2005/112.html CSS中的滑动门技术]（未考虑:hover） | ||
| + | *[http://www.planabc.net/2007/02/10/sliding_doors_of_css/ 100%点击区的滑动门] | ||
| + | *[http://veerle.duoh.com/blog/comments/simple_scalable_css_based_breadcrumbs/ 一款简洁的导航] | ||
| + | *[http://demo.rexsong.com/200705/css_background_menus/ 滑动门效果（23例）] | ||
| + | *[http://bbs.blueidea.com/viewthread.php?tid=2962953&page=1#pid4801907 一款滑动门导航]【第1楼第2个运行框的代码】 | ||
| + | *[http://bbs.blueidea.com/viewthread.php?tid=2962953&page=1#pid4812969 点击后高亮显示的滑动门导航]【第23楼运行框的代码】 | ||
| + | |||
| + | == 区别 == | ||
| + | |||
| + | 很多新手接触滑动门的时候，经常与[[Tab选项卡]]混为一谈。请记住，在某些情况下，Tab选项卡可能会使用滑动门技术，因为一组Tab选项卡看起来和导航非常类似。滑动门主要是靠控制CSS的各种属性实现的。而Tab选项卡主要是靠书写[[JavaScript]]脚本来实现的，尽管有时候需要使用滑动门技术来改变其外观。 | ||
| − | == | + | == 缺点 == |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | 滑动门频繁出现的场合是导航栏区域，而导航栏是一组链接集。 | |
| + | 某些时候，为了增强导航栏的交互表现，我们会使用伪类:hover来对链接做一些小小的改变，例如背景图片产生轻微变化，以强调鼠标指针已经移上这一事实，事实上这也是使用滑动门的最基本目的。 | ||
| − | + | 但是要实现滑动门效果，则必须添加'''额外的标签'''。事实上，'''所有的滑动门示例都需要至少2个标签配合才能完成实现'''，这是由于在[[CSS 2.1]]规范中，一个元素只能定义一副背景图片，因此要用额外的标签，来配合完成视觉上“滑动”的动作。 | |
| − | + | 在[[CSS3]]的草案中，W3C相关工作小组已经在为[http://www.blueidea.com/tech/web/2009/6806_6.asp CSS多重背景图]而努力，因此在未来，就不需要再使用这些额外的标签。 | |
| − | + | ==注意事项== | |
| − | + | ||
| − | + | 因为滑动门技术是极有可能牵涉到图片的，因此您要考虑以下问题： | |
| − | + | #注意增加字体颜色与背景颜色的对比<ref>文字来源：[http://www.moond.com/lab/?p=40 Readability － 可读性]</ref>，否则在背景图片未加载成功之前<ref>会员在：[http://bbs.blueidea.com/viewthread.php?tid=2971087 页面重构中琐碎“细节”：图片杂边]帖子中，有这么一段话：<i style="color:#050;">基本上每次登陆，登陆按钮总是最后出现，出现之前按钮的位置一直是白底状态，网速慢的时候要等更久，图片的...</i>，这是我们应该尽力避免的地方。</ref>，易造成使用障碍<ref>这不仅仅是使用滑动门才需要考虑的问题，请参考会员[[user:yoom|yoom]]的想法：[http://bbs.blueidea.com/viewthread.php?tid=2905962 安全的使用图片导航]</ref>，因此建议将字体颜色和背景颜色的反差拉大。 | |
| + | #如果对于页面加载速度要求苛刻，您应该尽可能将平时和:hover时的背景图融合到一副背景图上([[css sprites]])，而使用background-position来定位，这样以减少请求次数，并可避免在低端浏览器中出现导航“闪烁”。 | ||
| + | ==备注== | ||
| + | <references /> | ||
| − | [[Category:CSS | + | [[Category:CSS]] |
2010-04-22T10:42:30的最后版本
滑动门是一种利用CSS来控制自适应导航栏外观的一种技术。
滑动门使用最频繁的地方是导航栏。其实，当一个容器中的文字数量不定的时候，而需要背景自动反映这一变化，都可以考虑使用滑动门。
当满足以下条件，则可能需要使用到滑动门技术：
- 导航边框样式为非矩形，或者导航栏背景图片有阴影等装饰性效果。
- 在未知文字数量的情况下，导航栏自动适应宽度。
在制作滑动门以前，您需要斟酌到底能不能用低成本的方法实现。不是所有的效果图上的自适应导航都能用滑动门来实现。壁如，当效果图上的文字使用了特殊效果（阴影，浮雕，外发光等等），因为无法通过修改xhtml中的文字,来达到修改图片上文字，因此，滑动门在这种情况下并不适用。
在CSS 2.1环境下，滑动门导航至少需要2个标签配合才能完成实现。
范例
- CSS中的滑动门技术（未考虑:hover）
- 100%点击区的滑动门
- 一款简洁的导航
- 滑动门效果（23例）
- 一款滑动门导航【第1楼第2个运行框的代码】
- 点击后高亮显示的滑动门导航【第23楼运行框的代码】
区别
很多新手接触滑动门的时候，经常与Tab选项卡混为一谈。请记住，在某些情况下，Tab选项卡可能会使用滑动门技术，因为一组Tab选项卡看起来和导航非常类似。滑动门主要是靠控制CSS的各种属性实现的。而Tab选项卡主要是靠书写JavaScript脚本来实现的，尽管有时候需要使用滑动门技术来改变其外观。
缺点
滑动门频繁出现的场合是导航栏区域，而导航栏是一组链接集。 某些时候，为了增强导航栏的交互表现，我们会使用伪类:hover来对链接做一些小小的改变，例如背景图片产生轻微变化，以强调鼠标指针已经移上这一事实，事实上这也是使用滑动门的最基本目的。
但是要实现滑动门效果，则必须添加额外的标签。事实上，所有的滑动门示例都需要至少2个标签配合才能完成实现，这是由于在CSS 2.1规范中，一个元素只能定义一副背景图片，因此要用额外的标签，来配合完成视觉上“滑动”的动作。
在CSS3的草案中，W3C相关工作小组已经在为CSS多重背景图而努力，因此在未来，就不需要再使用这些额外的标签。
注意事项
因为滑动门技术是极有可能牵涉到图片的，因此您要考虑以下问题：
- 注意增加字体颜色与背景颜色的对比[1]，否则在背景图片未加载成功之前[2]，易造成使用障碍[3]，因此建议将字体颜色和背景颜色的反差拉大。
- 如果对于页面加载速度要求苛刻，您应该尽可能将平时和:hover时的背景图融合到一副背景图上(css sprites)，而使用background-position来定位，这样以减少请求次数，并可避免在低端浏览器中出现导航“闪烁”。
备注
- ↑ 文字来源：Readability － 可读性
- ↑ 会员在：页面重构中琐碎“细节”：图片杂边帖子中，有这么一段话：基本上每次登陆，登陆按钮总是最后出现，出现之前按钮的位置一直是白底状态，网速慢的时候要等更久，图片的...，这是我们应该尽力避免的地方。
- ↑ 这不仅仅是使用滑动门才需要考虑的问题，请参考会员yoom的想法：安全的使用图片导航
