<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>刘钢的博客 - 我是UED &#187; 前端开发</title>
	<atom:link href="http://www.iamued.com/tag/%e5%89%8d%e7%ab%af%e5%bc%80%e5%8f%91/feed" rel="self" type="application/rss+xml" />
	<link>http://www.iamued.com</link>
	<description>http://www.IamUED.com</description>
	<lastBuildDate>Wed, 18 Jan 2012 02:51:35 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
		<item>
		<title>如何量身打造一个前端框架</title>
		<link>http://www.iamued.com/qianduan/1404.html</link>
		<comments>http://www.iamued.com/qianduan/1404.html#comments</comments>
		<pubDate>Thu, 15 Apr 2010 07:00:38 +0000</pubDate>
		<dc:creator>RichieLiu</dc:creator>
				<category><![CDATA[JavaScript脚本]]></category>
		<category><![CDATA[前端开发]]></category>
		<category><![CDATA[框架]]></category>

		<guid isPermaLink="false">http://www.iamued.com/?p=1404</guid>
		<description><![CDATA[转一篇：taobao拔赤的一篇文章 写的很好 查看原文 程序层面，重点是？ 框架包含：核心(core)、适配器(adapter)、基础接口(public api)、代码管理(sandbox &#38; plugin)、组件库(widgets)，显然，框架的重点在于基础接口、和代码管理机制的设计。widget的实现是基于框架提供的public api，public api interface一旦定型尽量不要更改，也就是说，设计要遵循编程基本原则：面向接口，而不是面向实现，这个原则的基本要求是接口的稳定性。因此，框架版本升级导致接口更改的情况可以不考虑？ 框架设计师应当将有限的精力放在adapter、public api、sandbox &#38; plugins上，以保证框架基础逻辑设计思路清晰，widget和外部plugin的实现则是纯粹工作量的堆积，可以由更多的人参与开发，以分担框架设计师的工作。 需不需要对core进行重构？ 比较纠结的问题是，要不要对core进行重构？即将适配器以下都由自己重构，完全放弃现有的jquery或者yui，这个看情况，个人认为，使用现成的“库”是比较聪明的选择，开源的初衷不也是这样吗？我们要做的，只是将jquery式的api或者yui式的api转换成我想要的api格式即可，api的实现，有什么重要呢？ 开发者的角色？ 框架设计：框架设计师着力设计public api和sandbox &#38; plugin，adapter可以另有人做，只要对adapter有规范完整的黑盒测试即可。 widget开发：可以由更多的人基于pbulic api开发大量的widget，入库保证有code review即可。 应用开发：任何人基于sandbox和widget都可以开发app了。 各自的视野？ 对于框架的使用者来说，他们的视野仅限于sandbox、plugin usage、widgets，手旁只要准备一本public api手册就天下无敌了。对于框架开发小组来说，着重维护widget和api，把项目中的widgets不断抽离、code review并入库。对于工程师来说，他们的视野是一本手册和一些demo，没有必要理解框架的细节。对于那些业余的人来说，让他们一眼看到这个框架有这么多widget和demo，他们就会傻乎乎的开始用了。。。 因此，框架的开发，在于专业、在于坚持、在于团队，三者缺一不可。。。]]></description>
			<content:encoded><![CDATA[<p>转一篇：taobao拔赤的一篇文章 写的很好 <a href="http://www.uedmagazine.com/ued/index.php?entry=entry100412-135038">查看原文</a></p>
<p><strong>程序层面，重点是？</strong></p>
<p>框架包含：核心(core)、适配器(adapter)、基础接口(public api)、代码管理(sandbox &amp; plugin)、组件库(widgets)，显然，框架的重点在于基础接口、和代码管理机制的设计。widget的实现是基于框架提供的public api，public api interface一旦定型尽量不要更改，也就是说，设计要遵循编程基本原则：面向接口，而不是面向实现，这个原则的基本要求是接口的稳定性。因此，框架版本升级导致接口更改的情况可以不考虑？</p>
<p><a href="javascript:openpopup('/ued/getpic.php?p=http://fmn.xnimg.cn/fmn040/20100412/1245/p_large_wG5X_7685000444862d11.jpg',800,600,false);"><img src="http://iamued-wordpress.stor.sinaapp.com/uploads/auto_save_image/2010/04/150358kfX.jpg" border="0" alt="" /></a></p>
<p>框架设计师应当将有限的精力放在adapter、public api、sandbox &amp; plugins上，以保证框架基础逻辑设计思路清晰，widget和外部plugin的实现则是纯粹工作量的堆积，可以由更多的人参与开发，以分担框架设计师的工作。</p>
<p><strong>需不需要对core进行重构？</strong></p>
<p>比较纠结的问题是，要不要对core进行重构？即将适配器以下都由自己重构，完全放弃现有的jquery或者yui，这个看情况，个人认为，使用现成的“库”是比较聪明的选择，开源的初衷不也是这样吗？我们要做的，只是将jquery式的api或者yui式的api转换成我想要的api格式即可，api的实现，有什么重要呢？</p>
<p><strong>开发者的角色？</strong></p>
<p>框架设计：框架设计师着力设计public api和sandbox &amp; plugin，adapter可以另有人做，只要对adapter有规范完整的黑盒测试即可。<br />
widget开发：可以由更多的人基于pbulic api开发大量的widget，入库保证有code review即可。<br />
应用开发：任何人基于sandbox和widget都可以开发app了。</p>
<p><strong>各自的视野？</strong></p>
<p>对于框架的使用者来说，他们的视野仅限于sandbox、plugin usage、widgets，手旁只要准备一本public api手册就天下无敌了。对于框架开发小组来说，着重维护widget和api，把项目中的widgets不断抽离、code review并入库。对于工程师来说，他们的视野是一本手册和一些demo，没有必要理解框架的细节。对于那些业余的人来说，让他们一眼看到这个框架有这么多widget和demo，他们就会傻乎乎的开始用了。。。</p>
<p>因此，框架的开发，在于专业、在于坚持、在于团队，三者缺一不可。。。</p>
]]></content:encoded>
			<wfw:commentRss>http://www.iamued.com/qianduan/1404.html/feed</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>分享：建议“前端开发”人员掌握的技术</title>
		<link>http://www.iamued.com/qianduan/1278.html</link>
		<comments>http://www.iamued.com/qianduan/1278.html#comments</comments>
		<pubDate>Tue, 02 Mar 2010 15:14:15 +0000</pubDate>
		<dc:creator>RichieLiu</dc:creator>
				<category><![CDATA[JavaScript脚本]]></category>
		<category><![CDATA[前端开发]]></category>
		<category><![CDATA[页面实现]]></category>
		<category><![CDATA[javascript]]></category>
		<category><![CDATA[技术]]></category>
		<category><![CDATA[方向]]></category>

		<guid isPermaLink="false">http://www.iamued.com/?p=1278</guid>
		<description><![CDATA[建议“前端开发”人员掌 握的技术 必备技能 XHTML CSS 高级应用 Photoshop JavaScript 拓展技能 Ajax+UE+SEO+PHP+Mysql 文章摘要 前几天有一个网友留言，提到他正在阅读 “Javascript,CSS,XHTML,Ajax,jQuery” 等等一系列书籍。回想我上学的时候，也是看了很多东西，最终却没有用上，所以，在此写写自己学前端的一些感想。 前端这一行，入门并不困难，掌握XHTML+CSS之后，基本上就可以找到一份工作。 其他的东西，我们可以入职后再慢慢学习。 那怎么才算掌握？掌握到什么程度？ 检验自己水平的最好方式就是实战！学代码，就要边学边做。 这是最基本的东西，一定要把基础打扎实。 做什么内容？ 我们既然是做前端的，为什么不用标准化的语言来写自己的简历？同样出去找工作，递一份doc的简历好使，还是递一个通过W3C验证的页面更有说服力？实在 不知道拿什么东西练手，甚至可以去重构yahoo的网站，看看他们怎么写的，再对比一下自己的代码。琢磨琢磨他们为什么那么写，有什么优点，有什么缺陷。 之后呢？ 掌握JS 进了公司门，从第一天开始，就要学习JavaScript， 玩到精。JS也是前端必备的技能之一。之所以把它列出去，是让初学者有一个渐进的步骤。同时学太多东西，难以消化，这样分开一步一步的玩精通，压力会小一 些。学完这个，基本上就可以称为一个前端工程师了，对将来的工作非常有帮助。 选择性掌握PS Photoshop也是一定要学的，学到什么程度可以根据你自己的需求来定。如果将来想自己做单子，那PS就要玩的很地道。如果将来靠前端吃饭，去大公司 是不需要前端开发做设计稿的，会分层切图就可以了。当然，如果PS玩的很好，是不错的事情。 最后谈一下拓展技能 Ajax、jQuery 这些绚烂的名词，等你工作1-2年，JavaScript玩的烂熟于心的时候，自然会接触到。把他们列为拓展技能，是因为目前中小型企业的网站上应用这些 还不是很多，甚至应用JS的都不是很多。做到前边几项基本上就可以找到一份工作，再掌握这些，自然是画龙点睛之笔。但我的建议是，不妨先看一下下面几个技 能，我个人感觉，更有价值。 PHP+Mysql或者ASP或者JSP或者…. 职业的特殊性决定了我们需要跟后端工作者频繁的沟通，掌握这方面的一些知识有利于更有效的交流问题。提升前端在整个团队中的形象，进而提升自己的待遇。另 外，学好这部分东西，有企业找你做网站的时候，你可以拿的更稳妥。至于学PHP还是学JSP，根据自己的爱好来定，我个人比较喜欢 PHP，wordpress是很好玩的东西。 SEO+UE（用户体验） 用户体验是王道，而SEO是吸引用户的王道。我投入了很大的精力在这一领域，所阅读的书籍甚至比前端的书籍还要多。当然，我也一直认为UE就是前端开发不 可缺失的一部分。玩好这一点，往上，可以晋升到产品经理、部门经理的位置；往下，可以博得自己客户的满意。况且这东西并不难学，多留神观察生活就是了。何 乐而不为？ 做好一个前端开发工程师，并不是我们最终的目的，前端是一个一专多长的职业，为什么不放大一下自己所学的知识，去做更有意义的工作？掌握了这些方方 面面的技能之后，就已经具备了独立运营网站的技术实力。希望大家能更灵活的运用自己所拥有的能力，做更绚丽的作品，仅以此文共勉。 本文转自：崔凯的blog http://uicss.cn/front-end-developer-needed-technical/]]></description>
			<content:encoded><![CDATA[<table style="height: 121px;" width="487">
<thead>
<tr>
<th scope="row"></th>
<th colspan="5">建议“前端开发”人员掌 握的技术</th>
</tr>
</thead>
<tbody>
<tr>
<th scope="row">必备技能</th>
<td>XHTML</p>
<p>CSS</td>
<th scope="row">高级应用</th>
<td>Photoshop</p>
<p>JavaScript</td>
<th scope="row">拓展技能</th>
<td>Ajax+UE+SEO+PHP+Mysql</td>
</tr>
<tr>
<th scope="row">文章摘要</th>
<td colspan="5" width="555">前几天有一个网友留言，提到他正在阅读 “Javascript,CSS,XHTML,Ajax,jQuery”  等等一系列书籍。回想我上学的时候，也是看了很多东西，最终却没有用上，所以，在此写写自己学前端的一些感想。</td>
</tr>
</tbody>
</table>
<p>前端这一行，入门并不困难，掌握XHTML+CSS之后，基本上就可以找到一份工作。<br />
其他的东西，我们可以入职后再慢慢学习。</p>
<ol>
<li>那怎么才算掌握？掌握到什么程度？<br />
检验自己水平的最好方式就是实战！学代码，就要边学边做。<br />
这是最基本的东西，一定要把基础打扎实。</li>
<li>做什么内容？<br />
我们既然是做前端的，为什么不用标准化的语言来写自己的简历？同样出去找工作，递一份doc的简历好使，还是递一个通过W3C验证的页面更有说服力？实在 不知道拿什么东西练手，甚至可以去重构yahoo的网站，看看他们怎么写的，再对比一下自己的代码。琢磨琢磨他们为什么那么写，有什么优点，有什么缺陷。</li>
</ol>
<p>之后呢？</p>
<ol>
<li>掌握JS<br />
进了公司门，从第一天开始，就要学习JavaScript， 玩到精。JS也是前端必备的技能之一。之所以把它列出去，是让初学者有一个渐进的步骤。同时学太多东西，难以消化，这样分开一步一步的玩精通，压力会小一 些。学完这个，基本上就可以称为一个前端工程师了，对将来的工作非常有帮助。</li>
<li>选择性掌握PS<br />
Photoshop也是一定要学的，学到什么程度可以根据你自己的需求来定。如果将来想自己做单子，那PS就要玩的很地道。如果将来靠前端吃饭，去大公司 是不需要前端开发做设计稿的，会分层切图就可以了。当然，如果PS玩的很好，是不错的事情。</li>
</ol>
<p>最后谈一下拓展技能</p>
<ol>
<li>Ajax、jQuery<br />
这些绚烂的名词，等你工作1-2年，JavaScript玩的烂熟于心的时候，自然会接触到。把他们列为拓展技能，是因为目前中小型企业的网站上应用这些 还不是很多，甚至应用JS的都不是很多。做到前边几项基本上就可以找到一份工作，再掌握这些，自然是画龙点睛之笔。但我的建议是，不妨先看一下下面几个技 能，我个人感觉，更有价值。</li>
<li>PHP+Mysql或者ASP或者JSP或者….<br />
职业的特殊性决定了我们需要跟后端工作者频繁的沟通，掌握这方面的一些知识有利于更有效的交流问题。提升前端在整个团队中的形象，进而提升自己的待遇。另 外，学好这部分东西，有企业找你做网站的时候，你可以拿的更稳妥。至于学PHP还是学JSP，根据自己的爱好来定，我个人比较喜欢 PHP，wordpress是很好玩的东西。</li>
<li>SEO+UE（用户体验）<br />
用户体验是王道，而SEO是吸引用户的王道。我投入了很大的精力在这一领域，所阅读的书籍甚至比前端的书籍还要多。当然，我也一直认为UE就是前端开发不 可缺失的一部分。玩好这一点，往上，可以晋升到产品经理、部门经理的位置；往下，可以博得自己客户的满意。况且这东西并不难学，多留神观察生活就是了。何 乐而不为？</li>
</ol>
<p>做好一个前端开发工程师，并不是我们最终的目的，前端是一个一专多长的职业，为什么不放大一下自己所学的知识，去做更有意义的工作？掌握了这些方方 面面的技能之后，就已经具备了独立运营网站的技术实力。希望大家能更灵活的运用自己所拥有的能力，做更绚丽的作品，仅以此文共勉。</p>
<p>本文转自：崔凯的blog http://uicss.cn/front-end-developer-needed-technical/</p>
]]></content:encoded>
			<wfw:commentRss>http://www.iamued.com/qianduan/1278.html/feed</wfw:commentRss>
		<slash:comments>4</slash:comments>
		</item>
		<item>
		<title>前后端分离开发模式初体验</title>
		<link>http://www.iamued.com/qianduan/566.html</link>
		<comments>http://www.iamued.com/qianduan/566.html#comments</comments>
		<pubDate>Sun, 22 Nov 2009 04:57:02 +0000</pubDate>
		<dc:creator>RichieLiu</dc:creator>
				<category><![CDATA[JavaScript脚本]]></category>
		<category><![CDATA[前端开发]]></category>
		<category><![CDATA[页面实现]]></category>

		<guid isPermaLink="false">http://www.iamued.com/?p=566</guid>
		<description><![CDATA[前后端分离的开发模式，原本觉得没什么稀奇的玩艺，在最近参与的一个大型项目中，让我有了更深的理解。 前后端分离的开发模式：系统分析阶段，系分和前端开发人员约定好页面上所需的逻辑变量，进入功能开发阶段，前端开发人员进行前台页面结构，样式，行为层的代码编写，并根据约定好的变量，逻辑规则，完成不同情况展示不同的表现。而后端开发人员，只需要按照约定，赋予这些变量含义，并提供前后端交互所需要的数据即可。 以前自己在php上玩过mvc开发框架，但是没有在这么大型的项目中实践过，所以过程中暴露出一些问题，也说明现实和理想还是存在一定差距的。 对项目中遇见的问题做了如下纪录： A.对交互白板的理解不足，如：对ajax实现大批量数据交互的实现，没有及时给出改进的建议 B.系分阶段产出的约定变的非常脆弱，开发过程中不时有新的东西和变更的东西出现，这就导致后面的前后端协作开发有些纠结 C.项目过程中，由于前期与需求方，设计师，系分的沟通力度不够，导致开发过程中发现很多考虑的不够周全的地方 D.项目开发过程中前后端开发资源的配比上较为悬殊，在后期频繁需求变更中，前端一直处于：勉强应付状态   可见，上面提到的这些，多是沟通和协作上的问题，以下是对这次初体验的小结，希望对前端开发工程师有所借鉴： 沟通：项目开发之前，尽可能主动的和系统分析师和交互设计师多沟通，确定页面中交互与服务器端交换数据的接口、方式、格式等，让前后端约定更丰满一些。因为她越丰满，后面的纠结就越少。 A.向前设计，参与到前期的交互设计的讨论中去，去理解设计，向后开发，去了解后端开发工程师关心的是什么，不想要关心的是什么，担心的是什么，学会站在对方的角度上去看问题 B.必须确认交互白板中各类出错场景以及出错提示文案是否完整，要求后台开发人员补充交互设计师无法知晓的后端异常出错的场景，并要求交互设计师给出相应的提示文案 C.明确交互效果中，哪些是需要通过ajax实现的，并与开发人员约定好数据接口，方式，格式等，并确认数据交互失败的情况下是否有文案提示，如无，主动找交互设计师补充该类场景的文案提示 协作：功能开发过程中，需要建立一个共同调试的环境，方便前后端同学协同开发。 A.有些数据接口api以及数据格式也许会到开发中才能够确认下来。可以有个接口文档。如果大家都知道彼此对业务规则都熟悉，可以在开发中逐个确认。无论如何，接口文档是必须的。它记录着在系统层面对业务的抽象。接口细节可以在开发中逐渐完善。 B.总有那么一些文件，是前后端开发人员都会修改的。这些敏感文件，修改前以及修改完毕都要知会后端开发人员。而且要养成edit前update的习惯。如果出现冲突，冲突最好能够一起解决，或者及时告知。避免再次冲突。 C,项目中前后端资源配比应该适当，1：10的资源配比想推起前后端分离的开发模式还是比较困难的，个人认为1：3是比较适中的配比。 出于前后端资源配比，系统分析阶段还不够详细等原因，在一些大型的项目中，对分离开发模式进行了一些调整，说实在的有些不得以，但是这应该是目前最符合现状的前后端分离的开发模式，抱着发展的眼光向前看，前端不断壮大之后，应该会有让人满意的答卷的！ 在功能开发阶段，由于项目比较大，一般会分解功能，这样的话就很难提供出一个功能相对稳定的前后端共同调试环境，再加上资源配比太过悬殊，所以建议在功能开发还不稳定这个阶段，前端开发资源以协助开发的角色进入，由后端开发人员参照系分阶段约定好的数据类型和接口提供数据和嵌套页面逻辑，当功能开发相对稳定以后，前端开发人员对嵌套后的前台内容进行验收，此时，前后端开发的DEBUG工作就可以并行操作了。 转自：http://ued.alipay.com/?p=1073]]></description>
			<content:encoded><![CDATA[<p>前后端分离的开发模式，原本觉得没什么稀奇的玩艺，在最近参与的一个大型项目中，让我有了更深的理解。</p>
<p>前后端分离的开发模式：系统分析阶段，系分和前端开发人员约定好页面上所需的逻辑变量，进入功能开发阶段，前端开发人员进行前台页面结构，样式，行为层的代码编写，并根据约定好的变量，逻辑规则，完成不同情况展示不同的表现。而后端开发人员，只需要按照约定，赋予这些变量含义，并提供前后端交互所需要的数据即可。</p>
<p><img style="cursor: pointer;" src="http://iamued-wordpress.stor.sinaapp.com/uploads/auto_save_image/2009/11/1257039To.jpg" alt="前后端分离开发模式" width="575" height="383" /></p>
<p><span id="more-566"></span></p>
<p>以前自己在php上玩过mvc开发框架，但是没有在这么大型的项目中实践过，所以过程中暴露出一些问题，也说明现实和理想还是存在一定差距的。</p>
<p>对项目中遇见的问题做了如下纪录：</p>
<p>A.对交互白板的理解不足，如：对ajax实现大批量数据交互的实现，没有及时给出改进的建议</p>
<p>B.系分阶段产出的约定变的非常脆弱，开发过程中不时有新的东西和变更的东西出现，这就导致后面的前后端协作开发有些纠结</p>
<p>C.项目过程中，由于前期与需求方，设计师，系分的沟通力度不够，导致开发过程中发现很多考虑的不够周全的地方</p>
<p>D.项目开发过程中前后端开发资源的配比上较为悬殊，在后期频繁需求变更中，前端一直处于：勉强应付状态</p>
<p><span id="more-1073"> </span></p>
<p>可见，上面提到的这些，多是沟通和协作上的问题，以下是对这次初体验的小结，希望对前端开发工程师有所借鉴：</p>
<p><strong>沟通：</strong>项目开发之前，尽可能主动的和系统分析师和交互设计师多沟通，确定页面中交互与服务器端交换数据的接口、方式、格式等，让前后端约定更丰满一些。因为她越丰满，后面的纠结就越少。</p>
<p>A.向前设计，参与到前期的交互设计的讨论中去，去理解设计，向后开发，去了解后端开发工程师关心的是什么，不想要关心的是什么，担心的是什么，学会站在对方的角度上去看问题</p>
<p>B.必须确认交互白板中各类出错场景以及出错提示文案是否完整，要求后台开发人员补充交互设计师无法知晓的后端异常出错的场景，并要求交互设计师给出相应的提示文案</p>
<p>C.明确交互效果中，哪些是需要通过ajax实现的，并与开发人员约定好数据接口，方式，格式等，并确认数据交互失败的情况下是否有文案提示，如无，主动找交互设计师补充该类场景的文案提示</p>
<p><strong>协作：</strong>功能开发过程中，需要建立一个共同调试的环境，方便前后端同学协同开发。</p>
<p>A.有些数据接口api以及数据格式也许会到开发中才能够确认下来。可以有个接口文档。如果大家都知道彼此对业务规则都熟悉，可以在开发中逐个确认。无论如何，接口文档是必须的。它记录着在系统层面对业务的抽象。接口细节可以在开发中逐渐完善。</p>
<p>B.总有那么一些文件，是前后端开发人员都会修改的。这些敏感文件，修改前以及修改完毕都要知会后端开发人员。而且要养成edit前update的习惯。如果出现冲突，冲突最好能够一起解决，或者及时告知。避免再次冲突。</p>
<p>C,项目中前后端资源配比应该适当，1：10的资源配比想推起前后端分离的开发模式还是比较困难的，个人认为1：3是比较适中的配比。</p>
<p>出于前后端资源配比，系统分析阶段还不够详细等原因，在一些大型的项目中，对分离开发模式进行了一些调整，说实在的有些不得以，但是这应该是目前最符合现状的前后端分离的开发模式，抱着发展的眼光向前看，前端不断壮大之后，应该会有让人满意的答卷的！</p>
<p><img style="cursor: pointer;" src="http://iamued-wordpress.stor.sinaapp.com/uploads/auto_save_image/2009/11/125704YtD.jpg" alt="前后端分离开发模式" width="575" height="383" /></p>
<p>在功能开发阶段，由于项目比较大，一般会分解功能，这样的话就很难提供出一个功能相对稳定的前后端共同调试环境，再加上资源配比太过悬殊，所以建议在功能开发还不稳定这个阶段，前端开发资源以协助开发的角色进入，由后端开发人员参照系分阶段约定好的数据类型和接口提供数据和嵌套页面逻辑，当功能开发相对稳定以后，前端开发人员对嵌套后的前台内容进行验收，此时，前后端开发的DEBUG工作就可以并行操作了。</p>
<p>转自：<a href="http://ued.alipay.com/?p=1073">http://ued.alipay.com/?p=1073</a></p>
]]></content:encoded>
			<wfw:commentRss>http://www.iamued.com/qianduan/566.html/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>IE bug:1像素的dotted/dashed边框</title>
		<link>http://www.iamued.com/qianduan/457.html</link>
		<comments>http://www.iamued.com/qianduan/457.html#comments</comments>
		<pubDate>Sun, 08 Nov 2009 10:47:15 +0000</pubDate>
		<dc:creator>RichieLiu</dc:creator>
				<category><![CDATA[前端开发]]></category>
		<category><![CDATA[页面实现]]></category>
		<category><![CDATA[bug]]></category>
		<category><![CDATA[CSS]]></category>
		<category><![CDATA[hack]]></category>

		<guid isPermaLink="false">http://www.iamued.com/?p=457</guid>
		<description><![CDATA[最近的一个页面中碰到的，本来想用 border 来模拟设计图的虚线效果，但是很明显 border 效果不如设计图来的好看。顺便研究了下 dashed 和 dotted 的区别。 首先，从字面上来理解，dashed 和 dotted 都是指“虚线”，他们的不同在于： dashed：来自 dash（破折号），由 dash 组成的虚线 dotted：来自 dot （点），由 dot 组成的虚线，也称点线 这里多说几句废话，其实参看下 demo，就能从视觉上获得更直观的感受了。 下面再说说相关的 bug 吧，当然了，这些 bug 再一次只是光荣地出现在了 IE 下，此处涉及到 IE6 和 IE7。 Bug1: 在 IE6 下，1px 宽的 dotted 表现的和 dashed 一样。当宽度大于 1px 时，表现正常。 Bug2:在 IE7 下，当 4 条边的宽度是 1px 和 其它任意数值共存时，1px 的 dotted [...]]]></description>
			<content:encoded><![CDATA[<p>最近的一个页面中碰到的，本来想用 border 来模拟设计图的虚线效果，但是很明显 border 效果不如设计图来的好看。顺便研究了下 dashed 和 dotted 的区别。</p>
<p>首先，从字面上来理解，<strong>dashed</strong> 和 <strong>dotted </strong>都是指“虚线”，他们的不同在于：</p>
<p>dashed：来自 dash（破折号），由 dash 组成的虚线<br />
dotted：来自 dot （点），由 dot 组成的虚线，也称点线</p>
<p>这里多说几句废话，其实参看下 <a href="http://www.iamued.com/demo/091108/dotted.html" target="_blank"><strong>demo</strong></a>，就能从视觉上获得更直观的感受了。<br />
下面再说说相关的 bug 吧，当然了，这些 bug 再一次只是光荣地出现在了 IE 下，此处涉及到 IE6 和 IE7。<span id="more-457"></span></p>
<p>Bug1: 在 IE6 下，<strong>1px</strong> 宽的 dotted 表现的和 dashed 一样。当宽度大于 1px 时，表现正常。</p>
<p align="center"><img src="http://iamued-wordpress.stor.sinaapp.com/uploads/auto_save_image/2009/11/184846RAa.jpg" border="0" alt="" width="440" height="326" /></p>
<p>Bug2:在 IE7 下，当 4 条边的宽度是 1px 和 其它任意数值共存时，1px 的 dotted 表现的和 dashed 一样。4 条边的宽度全为 1px，或者为其它不是 1px 的不同值时不会出现这个 bug。</p>
<p align="center"><img src="http://iamued-wordpress.stor.sinaapp.com/uploads/auto_save_image/2009/11/184846Ygx.jpg" border="0" alt="" width="441" height="330" /></p>
<p>Bug3:另外，IE6 下，1px 的 dotted 或者 1px 的 dashed 边框，在拖动页面时，有时候边框会连成实线，有时候会出现缺口。</p>
<p align="center"><img src="http://iamued-wordpress.stor.sinaapp.com/uploads/auto_save_image/2009/11/184850uYc.jpg" border="0" alt="" width="400" height="550" /></p>
<p>要解决这些 bug，要么直接就不用 dotted 而直接用 dashed；要么用图片代替；要么用额外标签和代码来解决。</p>
<p>鉴于只有在边框宽度为 1px 时才会出现这些 bug，可以设置外包围标签的边框宽度为 2px，通过增加一个内标签，设置其为 1px 的内容背景色边框，再通过设置 margin-top/right/bottom/left: -1px; 来盖掉外包围标签的 1px 边框，从视觉上实现正常效果。很啰嗦，很讨厌，很无奈。<br />
<code><br />
.b6 {<br />
border: 2px dotted #000;<br />
padding-top: 0;<br />
}<br />
.b6 .inner {<br />
border: 1px solid #9c9c9c;<br />
width: 100%;<br />
height: 100%;<br />
margin: -1px;<br />
position: relative;<br />
z-index: 100;<br />
}<br />
详情请参考 <a href="http://www.iamued.com/demo/091108/dotted.html" target="_blank">DEMO</a></code></p>
]]></content:encoded>
			<wfw:commentRss>http://www.iamued.com/qianduan/457.html/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

