所谓第三方组件（widget），就是指我们提供给第三方网站使用的小模块，如微博的关注按钮，分享按钮，社交化组件，微博秀等等。当我们的组件放在第三方网站上时，不经意间会继承东道主网站的某些样式。但是，我们的目标是：保证自己组件样式的展现，即便寄人篱下，也不可丢失自己的个性！
通常我们会面临如下一些问题。
一、被同样的命名覆盖
我们先来看看某些网站的公用文件的写法：
eg1某网站：
clearfix这个命名，恐怕对于大多数的前端工程师都是再熟悉不过的了，这个词基本已经成为清除浮动某种方法的代名词了。当然，这种清除浮动的方法可以用其他命名，这个class也可以用来定其他属性。如果我们的组件恰好的也用了clearfix的命名，那么一定要想办法避免被同样命名的覆盖。在微博的组件中，我们会在所有组件中的class命名上加上我们自己特有的前缀WB_widget， 其余命名：WB_widget_xxxx;虽然看起来这样没有什么节省代码命名上的优势，但是确实可以避免一些简单的class命名重复。当然，如果您偏要修改我们组件的样式，偏偏要定义成和我们这样具有特殊命名的class同名的话，那我们也是拦不住的。
二、继承了多余的属性
再来看看下面几个网站的样式：
eg2某网站：
eg3某网站：
eg4某网站：
eg5某网站：
看着上面几个网站的通用写法，这就意味着，如果我们只是简单的定义，那么，我们的文本段落会有边距，我们的链接会有背景色，我们的图片都是块元素单独成一行，我们的文本区域都有着与第三方网站统一的边框，而不是我们定义的颜色……碰到这么多无法称之为样式显示bug的问题，一切都由于我们的组件规范的严谨性。那么如何保证网站对我们用的标签没有特殊定义？这个问题真正思考起来恐怕会得到一个很纠结的答案：除了考虑到我们经常用到的那些css属性之外，我们还要考虑到我们现在爱不释手的css3属性，既然考虑到了css3属性，不可避免的要考虑到各个高级浏览器的兼容问题。
纠结之后，恐怕最后得出的结论使我们非常不喜欢的reset周全考虑：
这么大篇幅的reset，估计也只能说是尽量把常用的考虑进去了；具体还要看使用组件的第三方，网站的样式到底会出现什么样的特殊性。