整合营销服务商
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
智能手机成为当下最为主要的个人终端设备时，尽管大家已经越来越习惯于使用APP，但浏览器作为曾经带领用户接触互联网世界的窗口，也依然还在继续发光发热。日前，谷歌、微软、苹果和Mozilla基金会共同宣布。将努力提高浏览器的互操作性，以确保Chrome、Edge、Safari和Firefox带来同样可靠和一致的Web体验，为此推出了被称为Interop 2022的互操作性标准。
据悉，Interop 2022是一个为Web开发者服务的通用测试标准，其将以“浏览器引擎在15个重点领域和3个联合调查中的表现”为不同浏览器提供评分，分别为CSS层叠层、色彩空间和功能、C对话框元素、CSS子网格、排版和编码、滚动条控件、表单控件等。目前，这四方也公布了各自旗下Chrome、Edge、Safari和Firefox的一致性进展，以及具体的兼容性成绩。
苹果方面在WebKit的开发者博客中透露，“Interop 2022是一个不断发展的指标，由一组自动化测试生成，旨在评估对某些对Web开发人员最重要的Web标准的支持。Interop 2022将全年不断更新，显示浏览器工程师修复错误、实施新功能和改进测试的进展”。由此不难发现，目前的主流浏览器在兼容性问题“折磨”了开发者与用户二十年余年后终于达成一致，要坐下来解决问题了。
“可靠和一致的Web体验”，其实指的是浏览器之间互相不兼容的现象。相信大家或多或少都用过360、搜狗、QQ等浏览器，并且这些产品基本都是在IE 6于2006年被评为“有史以来第八糟糕科技产品”后，一到两年内诞生的。而这一批浏览器在宣传推广时所打出的一个共同的口号就是“双核浏览器”，通常都主打的是兼容IE与Chrome内核，可面对老的Web应用使用IE内核，面向新的网页则使用Chrome内核。
相信很多朋友在使用浏览器时，多少都遇到过各式各样的兼容性问题。比如说，某个网页在IE上是一个颜色，在Chrome上就变为了另一个颜色，或是网页的比例发生了变化；又或者说，许多学生朋友可能在填报志愿时，就遇到过网站上出现“浏览器不兼容，请使用IE11/IE10/IE9浏览器访问”的提示。
而所谓的浏览器兼容性问题，是指因为不同浏览器对同一段代码有着不同的解析，所造成页面显示效果不统一的情况。为此，解决浏览器兼容，也成为了跨浏览器开发的一个核心问题。而Web浏览器的架构，可以实现为一个进程包含多个线程，也可以实现为很多进程包含少数线程通过IPC通信。但如何做一款浏览器，却并没有统一的标准。
这一切的根源，其实是在互联网早期，也就是上世纪90年代主导浏览器市场的微软，与负责web技术标准的W3C组织并不是一条心、双方各自奉行不同的标准所致。要知道，在新兴市场形成的早期通常都是建立标准的最佳时机，但当时最终的结果却是微软凭借着Windows的超高市占率，让IE的标准成为了用户的事实标准。
由于当初微软放弃了进入W3C，导致这一组织在Web技术标准上空有权威性、却基本不存在强制力，而2004年诞生的WHATWG（网页超文本技术工作小组），也更是让W3C的权威性大损。早在2004年时，W3C试图抛弃HTML转向XHTML，导致了苹果、Opera、Mozilla的不满，三家甩开W3C建立WHATWG开发了Web Applications 1.0，也就是现在的HTML 5。
虽然到了2007年W3C接纳了WHATWG，并同时将HTML 5作为Web技术的新标准，但W3C也就此失去了制定“标准浏览器”的能力。
当初微软不加入W3C，使得后者不采用IE的方案，而在IE掉队，Chrome与Firefox崛起后，已经有大量开发者基于IE标准开发了大量的Web产品，让浏览器不得不用兼容模式来解决这一问题。再加上不同浏览器采用的内核不同，由于缺乏统一的开发标准，以及各大浏览器厂商为了凸显产品的特色，更是使得整个浏览器行业出现了百花齐放的状态。
在过去很长的一段时间里，跨浏览器开发、并解决浏览器的兼容问题，成为了前端开发者最为头疼却必须要解决的问题。而他们所要面临的问题，就是开发者的代码运行环境本身并不掌控在自己手中（服务器端）、而是在客户端（用户的浏览器），因此也不得不尽一切可能去协调各式各样的浏览器。
众所周知，在PC互联网时代，浏览器市场有四大内核，即微软IE浏览器的Trident内核、苹果Safari和谷歌Chrome的Webkit内核、Firefox浏览器的Gecko内核，以及Opera浏览器的Presto内核。不同内核代表着浏览器的渲染引擎不同，而渲染引擎又是负责取得网页内容（HTML、XML、图像）、整理信息（加入CSS样式等），以及计算网页显示方式，然后输出至显示设备的关键。
不同浏览器内核不同的情况下，渲染逻辑自然也就不一样，就会导致同一份代码有的浏览器显示的正常、有的就不正常。例如，不同浏览器对HTM标记所具有的内外边距属性就有着不同的定义，对同一个网页元素重复设置多种样式时、处理优先级不一样，图片的位置设置在不同浏览器中显示效果不同等等，都是极为常见的。
目前，业界最主流的解决方案是“css hack”，而css （层叠样式表）则是用来表现HTML或XML等文件样式的计算机语言，是控制网站样式和布局的关键，也就是大家在浏览器上看到的网页显示效果，其实就是由css负责。由于不同厂商浏览器或某浏览器的不同版本对css的支持、解析不一样，就要求开发者来编写相应的css code。简单来说就是大力出奇迹，用因地制宜来解决问题。
css hack将压力抛给了开发者，为此部分开发者会在网页上设置浏览器检测，针对某些（IE）浏览器甚至直接拒绝服务，以至于没有兼容模式的Edge（Trident内核）在遇到网页检测浏览器时，干脆就声称自己是Chrome。显然这不是一个完美的解决方案，但奈何W3C组织不给力、浏览器厂商又各有各的算盘，所以解决浏览器之间的兼容性问题也就被束之高阁了。
那么，为什么在移动互联网时代、APP已经动摇了浏览器市场地位的当下，谷歌、微软、苹果和Mozilla又要携手来解决这一问题呢？
其实这是因为导致浏览器兼容性问题的历史包袱，现在已经不存在了。微软的IE11以及Edge已经彻底“寿终正寝”了，同时Mozilla的Firefox市场份额已不到4%，Opera浏览器更是放弃了自己的Presto内核、改用Webkit内核，并且Webkit内核也基本上已经一统整个市场了。至于说，谷歌与Opera合力研发的Blink内核，则是Webkit内核的硬分叉产物，两者拥有同一个源流。
换句话来说就是，当初浏览器兼容性问题的出现，是因为浏览器厂商太多、浏览器内核太多，各家的标准让开发者无所适从。但现在随着微软Edge加入谷歌的Chromium生态、Firefox式微，以及苹果Safari圈地自萌，开放的生态让Chromium的标准成为了全球开发者都在遵循的行业标准。
简单来说，就是Chromium生态在事实上已经垄断了浏览器市场，只需要4家厂商就可以制定浏览器的事实标准了。
(1) cookie 数据⼤⼩不能超过4k
(2) sessionStorage 和 localStorage 虽然也有存储⼤⼩的限制，但⽐ cookie ⼤得 多，可以达到5M或更⼤
(1) localStorage 存储持久数据，浏览器关闭后数据不丢失除⾮主动删除数据
(2) sessionStorage 数据在当前浏览器窗⼝关闭后⾃动删除
(3) cookie 设置的 cookie 过期时间之前⼀直有效，即使窗⼝或浏览器关闭
说得简单点，在线HTML编辑器就是在网上发帖子、写博客的那个带编辑功能的框框，可以进行图文排版等操作。
当年本菜鸟做网站的时候，曾经自己用javascript编写过一个比较简单的在线HTML编辑器，用于文本内容的排版。但是因为水平有限，很多功能都无法实现。后来有了eWebEditor，功能确实强大，但这个编辑器是个收费的软件，并且正因为功能强大，也就显得过重，一些轻量的场合不是太适用。那有没有既免费、又功能强大、还能适应轻量场合的在线HTML编辑器呢？
答案肯定是有的。这首先要感谢这些年来有一批奉献精神的程序猿们不断推进共享软件的开发，让我们得以享受他们的成果。
UEditor是由百度web前端研发部开发所见即所得富文本web编辑器，具有轻量，可定制，注重用户体验等特点，开源基于MIT协议，允许自由使用和修改代码。特别要说的是，头条号后台发布文章的编辑器就是用的UEditor!
百度UEditor
UEditor还有一个轻量版的，叫做UMeditor，简称UM。UM是为满足广大门户网站对于简单发帖框，或者回复框需求所定制的在线HTML编辑器。 主要特点是容量和加载速度上的改变，主文件的代码量为139k，而且放弃了使用传统的iframe模式，采用了div的加载方式， 以达到更快的加载速度和零加载失败率。UM的第一个使用者是百度贴吧，以经受贴吧每天几亿的pv的考验，功能设计应当是最优化的了。 当然随着代码的减少，UM的功能对于UE来说还是有所减少，但也有增加，比如拖拽图片上传，chrome的图片拖动改变大小等。
百度UEditor界面
xhEditor是一个基于jQuery开发的简单迷你并且高效的可视化HTML编辑器，基于网络访问并且兼容IE 6.0+,Firefox 3.0+,Opera 9.6+,Chrome 1.0+,Safari 3.22+。
xhEditor完全基于Javascript开发，可以应用在任何的服务端语言环境下，例如：PHP、ASP、ASP.NET、JAVA等。可以在CMS、博客、论坛、商城等互联网平台上完美的嵌入运行，能够非常灵活简单的和您的系统实现完美的无缝衔接。
主要特点：
精简迷你：初始加载4个文件，包括：1个js(50k)+2个css(10k)+1个图片(5k)，总共65k。若js和css文件进行gzip压缩传输，可以进一步缩减为24k左右。
使用简单：简单的调用方式，加一个class属性就能将textarea变成一个功能丰富的可视化编辑器。
无障碍访问：提供WAI-ARIA全面支持，全键盘精细操作，全程语音向导，提供完美无障碍访问体验，充分满足残疾人的上网需求。
内置Ajax上传：内置强大的Ajax上传，包括HTML4和HTML5上传支持(多文件上传、真实上传进度及文件拖放上传)，剪切板上传及远程抓取上传。
Word自动清理：实现Word代码自动检测并清理，生成代码最优化精简，却不丢失细节效果。
UBB可视化编辑：支持UBB可视化编辑，在获得安全高效代码存储的同时，又能享受可视化编辑的便捷。
KindEditor 也是一个开源的在线HTML编辑器， 使用 JavaScript 编写，可以无缝地与 Java、.NET、PHP、ASP 等程序集成，比较适合在 CMS、商城、论坛、博客、Wiki、电子邮件等互联网应用上使用。本菜鸟感觉这个编辑器上手比较容易，功能也很强大，界面比较友好，很适合菜鸟使用。可惜的是最近好像停止更新了，官网好象也能不正常访问。
KindEditor界面
主要特点：
快速：体积小，加载速度快
开源：开放源代码，高水平，高品质
底层：内置自定义 DOM 类库，精确操作 DOM
扩展：基于插件的设计，所有功能都是插件，可根据需求增减功能
风格：修改编辑器风格非常容易，只需修改一个 CSS 文件
兼容：支持大部分主流浏览器，比如 IE、Firefox、Safari、Chrome、Opera
严格来说，KISSY不仅仅是一个在线HTML编辑器，而是由阿里集团前端工程师们发起创建的一个开源 JS 框架，具有跨终端、模块化、使用简单的特点。里面带有HTML编辑器这个模块。
阿里的KISSY
正因为KISSY采取模块化设计，因此具有高扩展性、组件齐全，接口一致、自主开发、适合多种应用场景等优点。KISSY 除了完备的工具集合诸如 DOM、Event、Ajax、Anim 等，KISSY 还面向团队协作做了独特设计，提供了经典的面向对象、动态加载、性能优化解决方案。作为一款全终端支持的 JavaScript 框架，KISSY还 为移动终端做了大量适配和优化，搞移动web开发的可以好好研究一下KISSY的运用。
关于菜鸟手记：
菜鸟最怕就是看大神的攻略，全是术语看头就头大！本人作为一名对啥都感兴趣的资深菜鸟，潜心研究各类技术二十余年，做网站、写程序、搞美工、练书法、学画画、作文章、抓管理、装逼格，属于搞IT里面最懂美工的，搞HR里面最懂画画的，搞文字里面最懂程序的，最终一事无成，博而不精，徒留一堆手记。从菜鸟角度写手记，同样的”白”更易懂，你值得拥有！感兴趣的，请别忘点右角关注菜鸟手记。
*请认真填写需求信息，我们会在24小时内与您取得联系。
