❶ CSS Sprite是什么，谈谈这个技术的优缺点
个人简述一下，不从网上摘抄
CSS Sprite技术所白了就是图片拼合技术，主要是指将网页上很多用于装饰作用的小图片全部整合到一张图片内，减少网页加载时的HTTP请求并发数，页面加载时利用CSS中的背景图片定位属性background-position来指定需要显示这张大图上指定位置的部分
使用这个技术的优点就是减少页面加载时的瞬间HTTP请求并发数，提高了加载速度
缺点是这些被整合到一张图片的各种小图案后期维护修改比较麻烦，修改任意一个小图案都需要修改这张整图，同时还需要注意小图片在这个整图上的位置不能改变
❷ Web Components是什么和其他的前端开发方式有什么优缺点
Web Components 是组件规范，但还没有足够多的浏览器支持，目前只有chrome34+支持。
简单介绍：
Web Components的组件开发者在一个独立的沙箱（shadow dom）当中开发组件(包含：dom,css,js)
而组件的使用者则可以通过:
<slider>
<frame><img src="1.jpg"/></frame>
<frame><img src="1.jpg"/></frame>
<frame><img src="1.jpg"/></frame>
</slider>
这样的自定义标签来使用组件，就像浏览器原生支持的一样。
❸ 使用CSS 预处理器的优缺点有哪些
缺点：
简单来说CSS预处理器语言较CSS玩法变得更高级了，但同时降低了自己对最终代码的控制力。更致命的是提高了门槛，首先是上手门槛，其次是维护门槛，再来是团队整体水平和规范的门槛。这也造成了初学学习成本的昂贵。
优点：
用一种专门的编程语言，为CSS增加了一些编程的特性，将CSS作为目标生成文件，然后开发者就只要使用这种语言进行编码工作。通俗的说，CSS预处理器用一种专门的编程语言，进行Web页面样式设计，然后再编译成正常的CSS文件，以供项目使用。CSS预处理器为CSS增加一些编程的特性，无需考虑浏览器的兼容性问题，例如你可以在CSS中使用变量、简单的逻辑程序、函数等等在编程语言中的一些基本特性，可以让你的CSS更加简洁、适应性更强、可读性更佳，更易于代码的维护等诸多好处。
❹ css sprite是什么，有什么优缺点
CSS Sprites在国内很多人叫css精灵，是一种网页图片应用处理方式。它允许你将一个页面涉及到的所有零星图片都包含到一张大图中去，这样一来，当访问该页面时，载入的图片就不会像以前那样一幅一幅地慢慢显示出来了。对于当前网络流行的速度而言，不高于200KB的单张图片的所需载入时间基本是差不多的，所以无需 顾忌这个问题。
加速的关键，不是降低重量，而是减少个数。传统切图讲究精细，图片规格越小越好，重量越小越好，其实规格大小无所谓，计算机统一都按byte计算。客户端每显示一张图片都会向服务器发送请求，所以，图片越多请求次数越多，造成延迟的可能性也就越大。
CSS Sprites原理
CSS Sprites其实就是把网页中一些背景图片整合到一张图片文件中，再利用CSS的“background-image”，“background- repeat”，“background-position”的组合进行背景定位，background-position可以用数字能精确的定位出背景图片的位置。
CSS Sprites优点
利用CSS Sprites能很好地减少了网页的http请求，从而大大的提高了页面的性能，这也是CSS Sprites最大的优点，也是其被广泛传播和应用的主要原因；
CSS Sprites能减少图片的字节，曾经比较过多次3张图片合并成1张图片的字节总是小于这3张图片的字节总和。
CSS Sprites缺点
诚然CSS Sprites是如此的强大，但是也存在一些不可忽视的缺点
在图片合并的时候，你要把多张图片有序的合理的合并成一张图片，还要留好足够的空间，防止板块内不会出现不必要的背景；这些还好，最痛苦的是在宽屏，高分辨率的屏幕下的自适应页面，你的图片如果不够宽，很容易出现背景断裂；
CSS Sprites在开发的时候比较麻烦，你要通过photoshop或其他工具测量计算每一个背景单元的精确位置，这是针线活，没什么难度，但是很繁琐；幸好腾讯的鬼哥用RIA开发了一个CSS Sprites 样式生成工具，虽然还有一些使用上的不灵活，但是已经比photoshop测量来的方便多了，而且样式直接生成，复制，拷贝就OK！
CSS Sprites在维护的时候比较麻烦，如果页面背景有少许改动，一般就要改这张合并的图片，无需改的地方最好不要动，这样避免改动更多的css，如果在原来的地方放不下，又只能（最好）往下加图片，这样图片的字节就增加了，还要改动css。
CSS Sprites非常值得学习和应用，特别是页面有一堆ico（图标）。总之很多时候大家要权衡一下利弊，再决定是不是应用CSS Sprites。
❺ web前端工程师的优点和缺点
优点：HTML5APP可以在PC和移动、iOS和Android上运行。
缺点：在对性能要求较高的情况下，或选择使用本机开发知识。
实现此目的的最佳方法是混合方法，大型框架使用本机、基本功能等，一些模块使用HTML。Web前端工程师：使用（X）HTML／CSS／JavaScript／Flash等各种Web技术开发的客户端产品。
Web前端工程师：完成客户端程序（即浏览器端）的开发，开发JavaScript和Flash模块，结合后台开发技术模拟整体效果，富InternetWeb开发，致力于通过技术提升用户体验。
Web前端工程师：对Web2．0、HTML＋CSS和浏览器兼容性有深刻的理解。了解其他IT编程语言，如PHP、Java、．net和vue。
(5)css前端开发优缺点扩展阅读：
掌握以下技术：
1．掌握基本的web前端开发技术：HTML、CSS、JavaScript、DOM、BOM、AJAX等，了解其与不同浏览器的兼容性、渲染原理及bug
2．必须具备网站性能优化、SEO和服务器端开发的基本知识
3．必须学会使用各种web前端开发和测试工具来辅助开发吗
4．除了技术知识之外，还需要理论知识，包括代码的可维护性、组件的易用性、分层语义模板和浏览器分层支持
5．未来的web前端开发工程师还将学习HTML5、web视觉设计、网站色彩搭配、网站交互设计模式等相关技术
网络--web前端工程师
❻ div+css与table+css的优缺点
作为一个身处 2008 年末的 Web 设计师，你是否好意思承认自己的代码中使用了 Table，如果是，你是一个有勇气的人，Web 设计是个奇怪的行业，你可以将自己的网站设计得像晚报的分类广告，或者楼道里的开锁广告，但千万别让人知道你使用了 Table，在你的源代码中发现 Table 就像一个销售被人掀起裤脚发现穿了白袜子一样。
Table 是如此丑陋，臃肿，哪怕只显示一段简单的内容，你也需要 <table><tr><td> 这三个基本的标签，每个标签里面还要加上一堆乱七八糟的属性，不像<div>，既简单，又整洁，又时尚，它和 CSS 珠联璧合，琴瑟和谐，它们构成最完美的 Box 模型，他们象现实中的箱子，你把东西放进去，然后，很自由地对他们进行排列，厌烦了一种布局，没关系，简单地改动一下 CSS 定义，一种全新的布局便诞生了；不象 Table，Table 像食堂里的餐具柜，一排排，一列列，土里土气，油腻腻的，象我们的父辈，邋遢，什么都往家里拿，胡乱堆在角落里，如果 Div 是小资，Table 就是老三届，他们不属于这个时代。
也就是近几年的事，至多不过三五年，W3C是一个人人都认为重要但人人都不喜欢的组织，他们的官方网站十分丑陋，我敢说平生没见过这么丑陋的网站，但他们的网站是为数不多的可以通过全部W3C标准验证的网站，这意味着，他们的网站在语法上，在结构上，在可访问性上是完美的，虽然依旧十分丑陋。不过这是笑谈，W3C非常重要，否则微软会把全体 Web 开发工程师带到万劫不复的境地，还好，Netscape 死后，涅磐出 Firefox，而 Opera 在 Firefox 横空出世之后虽然没得到任何好处，至少得到了精神上的支持，看到没，终于有大哥出来收拾你。乔布斯复出后，苹果重返昔日的光芒，这时人们才知道世界上还有一个叫做 Safari 的浏览器，所有这一切加在一起，让 W3C 真正有了存在的必要。
W3C 说，Table 可以用来容纳文字，格式文字，图片，链接，表单，以及其它 Table ... 但是，Table 不应该单纯用来做网页布局（Tables should not be used purely as a means to layout document content），理由是，当 Web 被非可视化设备渲染的时候，Table 会出现问题，他们指定是屏幕阅读器以及盲文浏览器，另外，Table 在大型显示设备上会强迫用户左右滚动，因此，Web 设计者应该使用 CSS 而不是 Table。参见 W3C HTML 4.01 关于 Table 的定义。 W3C 说这段话的时候，是1999年12月24日，那时尽管 CSS 早已诞生，但并没有多少人使用，最初的 Web 像一个在线版的文档，并没有成为现在这样的平台，不需要过多过多地考虑布局问题，随着互联网第一次泡沫的形成，涌现出大量的门户网站，门户网站是 Table
布局的始作俑者，因为他们的首页比一整份报纸的所有版面拼接在一起还复杂，Table 在这方面十分顺手，结合 colspan 和 rolspan，你几乎能够实现任何复杂的版面。
这种布局风格在2000年代初，一直到中期仍然十分流行，尤其国内，在大为美的潜意识下，人们把所有能塞到一个页面的东西都塞进了首页，Table 就像一个旧时代的管家，把所有东西虽不能井井有序，但至少是一样不少地编排起来。然而这样的 Web 终于到了让人厌恶的地步，随着搜索，RSS 订阅，以及以博客为代表的个性化 Web 的出现，人们有更多渠道获得信息，而不必去访问那几个让人几乎要晕过去的门户的首页，于是出现了一种清新的，轻量的 Web 风，使用更简单的布局，更明快的配色，大图标，大 Banner，以及更容易阅读的大字体，同时，在这个时候，CSS 已经非常成熟，而 Firefox, Opera, Safari 为代表的浏览器，在遵守 W3C 标准方面要远远好过 IE，人们终于认识到 CSS 的威力。因为 CSS 在布局上，其核心是一个 Box
模型，人们必须为 CSS 找一个可以依附的容器对象。
Div 成为幸运者一方面因为它天生就是 Box 的最佳原型，在语义上，Div 代表页面的一个区域，在外形上，它四四方方，更重要的是，它不像 <P> 或 <a> 那样事先已经被赋予特殊的语义（虽然它们也能用于 Box 模型）；另一方面，则出于人们对 Table 统治一个臃肿时代的憎恶，一个时代的结束，继任者都会努力抹去旧时代的痕迹，那些旧时代的象征或代表的命运多半如此，人们并不是简单地忘却它们，而是断然划清界限。
Table 的一切不公平待遇就此开始。为什么说不公平，W3C 不建议 Table 布局的时候，只说应使用 CSS 代替，这是什么意思，Table 不支持 CSS 吗？当然支持，而且，由于 Table 作为老牌的 HTML 对象，它的地位曾如此重要，任何浏览器都对 Table 提供了最完美的支持，包括 CSS 支持。当人们拥抱 Div 的时候，似乎忘记了 Table 也是 Box，而且是一个拥有多个内格的 Box，Table 作为一个整体，和 Div 在 Box 模型方面没有任何区别，而它的内格，除了 Margin 之外，仍然是一个 Box，内格不含 Margin 概念这是应该理解的。Div 很优秀这不必说，然而当人们说 Div + CSS 的时候，似乎暗示着 Table 无法 CSS，这是天大的误会。
Div 支持的所有 CSS 属性，Table 全部支持，事实上，在 Div 大红大紫之前，那些 Div 的早期采用者曾信心不足地表示，Table 能做到，Div 都能，而他们也为自己的话付出了代价，企图在 Div 中实现垂直居中的人明白我的意思，企图在 IE6 中不经 CSS Hack 而实现 100% Div 布局的人更明白我的意思。100% Height 问题，几个 Div 之间的宽度自适应问题，相信任何从事 Div + CSS 设计的人会遇到。Table 在这方面的优势并不是因为它本身多么优秀，而是因为它老牌，没有浏览器敢忽视，也因为它的特性原本如此，人们发明表格，是因为希望数据显示得整齐，就这么简单。然而，为什么 Table 后来背上那么多的恶名？Div 拥护者对 Table 的责难不外乎以下几条。
代码臃肿：你至少需要写下 <table><tr><td>这三个标签之后，才能开始真正的内容，另外，Table 的各种标签中还包含了复杂的属性定义，而 Div 只需 <div>一个标签。
页面渲染性能问题：浏览器需要将整个表格完全读完后才会开始渲染。
不利于搜索引擎优化：搜索引擎喜欢内容与修饰分开。
可访问性差：屏幕朗读软件和盲文浏览器无法很好地理解 Table 中的内容。
不够语义（Semantic）：我们需要语义的 Web。
第1条：代码臃肿
首先，Table 里面唯一无法用 CSS 定义的属性只有 Cellspacing, Cellpadding 几个，其它属性都可以并且应当使用 CSS，这样，剩下的，就是 <table><tr><td> 和 <div> 的对决，我相信一个动辄几十K大小的网页，即使使用了几十个 Table，因此多出来的代码也可以忽略不计，那些埋怨 Table 代码臃肿的人其实该检查自己的编码习惯，能将 Table 写得十分臃肿的人，写 Div 相比也未必会简洁到哪里。
第2条：页面渲染性能问题
我使用一台2004年的笔记本电脑，1.6G 的 CPU 与 1G 内存，这种配置下，看不出 Table 布局和 Div 布局在页面渲染上有任何速度差别，其实这点差别即使有，相对网络本身的延迟也可以忽略。
第3条：不利于搜索引擎优化
如果你尽可能使用 CSS 而不是 Table 的属性，前面说了，产生的代码和 Div 的差别也不会很大，搜索引擎会歧视 <table> 标签吗，这种说法的依据我至今并没有找到。
第4条：可访问性差
这是 Table 固有的缺陷，不过多数 Div + CSS 的拥趸似乎并不是基于这个原因才排斥 Table。
第5条：不够语义
语义 Web 的含义要深远得多，并不是仅仅在 Table 和 Div 上纠缠，即使 W3C，也并没有规定 Table 只能用来显示表格数据，很多在 Table 的语义上进行纠缠的人，其实不妨再等等 HTML 5，那才是真正的语义。
本文的目的不是让你丢弃 Div 投身 Table，相反，如果 Div 能满足你的设计需要，Div 仍是首选，但没必要避讳 Table，否则会走入另外一个极端。很多使用 Div 无法简单实现的设计，仍可以使用 Table，当然，不管使用什么，都应该用 CSS 将内容与修饰分离。Div + CSS 和 Table + CSS 都是合法的设计，谁更简单就用谁。根据我的经验，当你能预见你的内容的格式，对你即将加入的内容有能力完全控制其显示格式时，应当使用 Div + CSS；当你即将加入的内容是不固定的，你无法预见其格式，如果不想让页面坍塌，使用 Table + CSS 是一种保险的做法。
❼ Div+Css和Table功能实现各有什么优缺点
DIV与TABLE本身并不存在什么优缺点，所谓web标准只是推荐的是正确的使用标签，好比说：DIV用于布局，而TABLE则本来就是转二维数据的。让TABLE做该做的事，并不是说页面里不出现TABLE就是多么多么牛。
用DIV进行排版的优势就是我不说，大家应该都比较清楚。DIV是标准，是大势所趋，但并不意味着所有的页面都适合用它来做。
中国的门户和国外的有很大的区别，中国网民并不喜欢信息量少的页面，YAHOO到了中国页面上的内容就多了不少，而上次改为简洁的页面后访问量下降的厉害以至于没过几天就又改了回来。正式由于中国的国情造就了搜狐、新浪这样门户。
为什么DIV不适合他们？下面我从几个方面来逐一说明：
精简代码：
大家都说DIV的布局精简代码，但是用DIV替代TABLE所节约的代码又被CSS（样式）所占用，而这些样式大多用于控制DIV的排版布局。那你会说了，CSS可以放在外部重用啊，要想得到这个问题的答案请往下看。
重用性与下载量：
统一使用一个.css的样式表文件，可以实现修改一次，全站修改的效果，这样使得维护的成本更低。但是请大家换一个角度想，如果所有页面在加载时都要访问一个文件，那这个文件每天的下载量，特别时在搜狐、新浪的网站平台上将达到几亿次，这就需要后面有很多台前端web服务器在做支撑，那后台的成本无形中也提高了很多。如果后台支撑没有做好，那么页面就会出现花屏，之前所作的工作也是白费。很多人会问，这样的几率太小了。我们所作的工作就是为了避免这一两次意外的发生，如果意外发生了，对于门户后果将是不堪设想的。
HTTP通讯：
统一的样式表文件采用外部调用的形式，这样每次加载单个页面都会多一次对服务器的http请求服务器都会增加一次响应，这样对前端web服务器会是很大的消耗。而原来很长时间都是将css和js写在页面前端（大家可以看看sohu和sina的页面，大多都是采用这样的形式），而不是作为外部调用的形式，也是为了尽量避免给服务器增加消耗。
页面缓存：
每次用户访问的页面，都会在浏览器缓存中保存一定时间，以保证用户下次再访问该页面时能够大大提高页面显示速度。而每次修改都会使页面重新下载，对于每个外部导入的样式文件也是如此，如果CSS文件修改，那么访问网站的每一个页面都会重新下载，而以往的将样式写在页面中的方式，只是修改的页面需要重新下载。
兼容性：
对于CSS（样式表）并不是所有浏览器的所有版本都支持的很好，比如IE5以前的浏览器对于CSS的支持就不是很好。而现在使用IE5以前版本浏览器的用户不在少数，这样就使得在页面制作的过程中需要针对不同浏览器版本进行测试，以保证兼容性，无形中也增加很多工作量（至少我接触的开发人员制作div页面比table页面的标准时间要长一些）。
横切与延展性：
横切——传统的布局方式为了使页面下载的更快，把页面自上而下分成若干个块，但是往往采用DIV进行布局的页面都会出现这样的情况，由于每块中间栏或者其他栏内容条数不固定导致两边栏目没有同时自适应，而出现留白。
相比之下传统的table方式更容易规避这样情况的发生。
以上我们只是讨论某一技术在某一领域的可用性，而非技术本身。
说了这么多并不是说DIV这种布局方式不好，而是说我们应该正确的看待Table在以内容为基础的大型门户中的作用，而不是人云亦云。之所以DIV的布局方式没有在大型网站应用，不是说门户没有用DIV是技术落后，是里面的人没有前瞻性，而是多种原因决定的。网易之所以全部采用DIV的方式是因为内容并不是他们主攻方向。而对于其他门户来说，这样的决策是要靠时间来验证的。只是现在这个时机还不成熟而已。
❽ 为什么 Web 前端开发不抛弃 HTML 和 CSS，用纯 JavaScript 开发
首先要确定，即使抛开游戏不论，一般的Web应用或者网站，完全用JavaScript开发也是可行的。比如ExtJS、webOS的Enyo等。但是主流Web开发很少采用全JS的方案。原因大体有以下几点：
1. 注重考虑那些无法运行JS的用户代理。
用
户使用不支持JS的浏览器（比如较老的手机浏览器），或者禁用脚本。当然你可以选择忽略这一小撮用户，尤其是现在绝大多数网站和应用也是如此选择的，但是
至少我们应该对坚持考虑无JS情况的开发者予以基本的尊重。此外，如 Mobile
Transcoder或某些手机浏览器的“极速模式”是基于服务器端对网页的解析和重组，是否能支持JS很够呛。
更重要的因素是SEO friendly。如果是全JS生成的网页，搜索引擎无法索引内容。这一点对于许多网站是性命攸关的。
注意，有人提到screen reader。但绝大多数读屏软件是根据DOM来的，因此全部由JS生成DOM也不会有问题。然而这前提是JS所生成的DOM是符合accessibility要求的。
2. 注重HTML/CSS本身的优点。
诚然JS本身也可以通过精心设计的框架和库来实现分离等所有HTML/CSS模型的优点。但是存在许多不确定因素：
1) 有足够好的框架和库吗？
要
考虑是否能满足你的业务需求，还可能要考虑性能、可扩展性、之前提到的accessibility、学习曲线、工具链，乃至此框架和库的长久的生存（有人
维护，修bug、加新功能比如对HTML5新API的支持之类的）。关键是，理论上说JavaScript具有更高的弹性，但是更大的自由度未必能得到更
好的
2) 框架和库给出的抽象模型和HTML/CSS模型的阻抗是否匹配？
假如该框架或库本质上仍然使用HTML/CSS模型，只是改变了语法（比如从markup改为json），那么其提供的好处在哪里？仅仅是语法统一？
如
果该框架或库有自己独立的抽象层，比如widget/component等，那么它是建筑在HTML/CSS之上的额外抽象层（即最终映射到HTML
/CSS），还是仅仅以HTML/CSS为纯粹实现工具？对于前者，实际上最终会回归HTML/CSS模型。而后者，可以参考的经验教训就是http://ASP.NET WebForm和JSF。
3) 框架和库所设定的约束能否在开发中一以贯之的执行？
无
论是理论或者现实，HTML/CSS模型都算不上完美。但是至少是清晰和较容易被一致的执行的。但是单一语言即使提供分层机制，也容易被绕过——尤其是框
架和库本身不够好的情况下，可能由于不能满足需求、有bug等情况而倾向于hack之，更不要说deadline紧迫时。
3. 注重性能。
须
知，最终Web应用、页面是在浏览器中执行，而浏览器完全是按照HTML/CSS所设计。抛开Canvas不论，纯JS的实现最终还是要生成DOM。从性
能的角度看，纯JS生成DOM自然赶不上直接的markup。同样的道理，就算用CSS预处理器也都会在部署时预先编译——尽管在运行时可以做出更牛逼的
特性（然而实际上目前我不知道有任何CSS预处理器干了这样的事情——因为它们都是按照预编译的场景设计的），再如HTML/CSS是按照渐进显示优化的
（页面不用全下载完就可以看部分），而纯JS的架构没有精心设计是很难做到的（比如json数据全部下载完你才能parse，数据才可用，DOM才能生
成）。
［补充：尽管LESS是可以在运行时执行的，但是从性能的角度出发是不合适的，因为CSS通常必须在页面rendering之前就全部就位。而运行时产生CSS，
就要求在页面rending之前至少要先下载执行LESS的脚本，然后解析编译你的.less源代码。这个性能开销至少目前还不容忽视。］
［补
充：性能优化的另一点是基于HTML/CSS的声明性特点，即只表明high-level的目标，浏览器才能获得更大的优化自由度。比如CSS
transition/animation，与JavaScript通过修改style达到效果比，前者性能表现要好得多。］
4. 注重Web开发的独特特点。
1) HTML/CSS 都是声明式的，也就是其本身并不希望是程序员来编程。当然，一个编程语言能干所有的事情，但是即使考虑编程本身，为什么在通用编程语言之外还要有SQL、还有以各种语法写的配置文件？
2) HTML/CSS是基于标准的。这与http://ASP.NET WebForm、JSF、Flash/Flex等私有技术或一个语言和平台下的标准有天壤之别。具体就不展开了。
3)
Web开发和一般应用开发有个重大区别是，Web应用、网页的最终表现和行为，或者说Web的用户体验，并不是完全由开发者决定的，而是开发者和用户共同
决定的。用户选择不同的设备、不同的浏览器、不同的浏览器设置、不同的浏览器扩展等，都能影响结果。这是缺点，也是优点。看你如何体会了。这里具体不展
开。只是一点，纯JavaScript开发通常表示你想更多的控制用户体验，但这并非简单的多写代码就能做到。
❾ CSS 的预处理程序分别都有哪些优缺点
LESS/SASS优点：
开发速度提升；
代码优化效率提高（对开发者而言）；
代码更通俗易懂（对开发者而言）；
维护简单便捷；
代码更干净，优美；
功能更多更强，CSS做出JS的特效（其实就是JS）；
总而言之，LESS/SASS就是CSS里面的jQuery，简化，减少开发时间，提升开发者开发体验。
LESS/SASS缺点：
舍弃用户体验来提高开发的效率，可以查考Bootstrap的缺点；
舍弃网页打开速度换取开发效率提升；
需要一个学习的过程，用之不当反而弄巧反拙；
总而言之，LESS/SASS缺点就是需要多一个编译器来重新编译一次你的CSS代码，也就是给浏览器多了一道工序，网页显示的速度会减慢（网页显示顺序，从上至下，一般CSS放在头部，先HTML DOM元素-->CSS-->脚本文件-->页面元素如图片，视频，音频--->最后完全显示）
你在CSS工序加了一个步骤，速度自然慢，时间自然多了。
什么网站适合LESS/SASS，企业网站，个人网站，普通静态页。
如果淘宝用了LESS/SASS，估计淘宝每年会失去至少5千亿成交额