html5与传统html区别

Posted 2023-05-07

参考技术A

html5与传统html区别

　　 一. HTML5语法的改变

　　该知识点所说变化指的是基于HTML4基础上所定义的改变，主要有如下：

　　1.HTML5的文件扩展符(.html或.htm)与内容类型(text/html)保持不变。

　　2.HTML5中，刻意不使用版本声明，一份文档将会适用于所有版本的HTML。

　　3.从HTML5开始，对于文件的字符编码推荐使用UTF-8。

　　4.HTML5确保了与之前HTML版本的最大程度的兼容性。

　　为了保证兼容性，需从元素说起，在HTML5.中，元素的标记可以省略。其体来说，元素的标记分为“不允许写结束标记”、“可以省略结束标记”和‘“开始标记和结束标记全部可以省略”三种类型。

　　不允许写结束标记元素有：area、base、br、col.....

　　可以省略结束标记：li、dt、dd、p、rt......

　　开始标记和结束标记全部可以省略：html、head、body.....

　　 二.新增的结构元素

　　section元素表示页面中的一个内容区块，比如章节、页眉、页脚或页面中的其他部分；

　　article元素表示页面中的一块与上下文不相关的独立内容，譬如博客中的一篇文章或报纸中的一篇文章；

　　aside元素表示article元素的内容之外的、与article元素的内容相关的辅助信息；

　　header元素表示页面中一个内容区块或整个页面的标题；

　　hgroup元素用于对整个页面或页面中一个内容区块的标题进行组合；

　　footer元素表示整个页面或页面中一个内容区块的脚注。一般来说，它会包含创作者的姓名、创作日期以及创作者联系信息；

　　nav元素表示页面中导航链接的.部分；

　　figure元素表示一段独立的流内容，一般表示文档主体流内容中的一个独立单元，使用figcaption元素为figure元素组添加标题

　　2、新增的其他元素

　　audio元素定义音频，比如音乐或其他音频流；

　　embed元素用来插入各种多媒体，格式可以是Midi、Wav、AU、MP3等；

　　mark元素上要用来在视觉上向用户呈现那些需要突出显示或高亮显示的文字，典型应用就是在搜索结果中向用户高亮显示搜素关键词；

　　progress元素表示运行中的进程

　　ruby元素表示ruby注释(中文注音或字符)

　　rt元素表示字符(中文注音或字符)的解释或发音

　　rp元素在ruby注释中使用，以定义不支持ruby素的浏览器所显示的内容。

　　wbr元素表示软换行，而当宽度不够时，主动在此处进行换行

　　canvas元素表示图形，比如图表和其他图像

　　cammand元素表示命令按钮，比如单选按钮、复选框或按钮

　　details元素表示用户要求得到并且可以得到的细节信息

　　datagrid元素表示可选数据的列表，它以树形列表的形式来显示

　　keygen元素表示生成密钥

　　output元素表示不同类型的输出，比如脚本的输出

　　source元素为媒介元素(比如和)定义媒介资源

　　menu元素表示菜单列表

　　3、新增的input元素

　　email 类型表示必须输入E-main地址的文本输入框

　　url 类型表示必须输入URL地址的文本输入框

　　number类型表示必须输人数值的文本输入框

　　range 类型表示必须输入一定范围内数字值的文本输人框

　　HTML5拥有多个可供选取日期和时间的新型输入文本框:

　　date ——选取日、月、年

　　month ——选取月、年

　　week ——选取周和年

　　time ——选取时间(小时和分钟)

　　datetime ——一选取时间、日、月、年(UTC 时间)

　　datetime.local ——选取时间、日、月、年(本地时间)

　　 三.废除元素

　　1、能使用CSS替代的元素

　　对干basefont、big、center、font、s、strike、tt、u这些元素，由于它们的功能都是纯粹去画面展示服务的，而HTML5中提倡把画面展示性功能放在CSS样式表中统一编辑，所以这些元素废除了

　　2、不再使用frame框架

　　对于frameset元素、frame元素与noframes元素，由于frame框架对网页可用性存在负面影响，在HTML5中已不支持frame框架，只支持iframe框架，或者用服务器方创建的由多个页面组成的复合页面的形式，同时将以上这三个元素废除。

　　3、只有部分浏览器支持的元素

　　对于applet、bgsound、blink、marquee等元素，由于只有部分浏览器支持这些元素，特别是bgsound元素以及marquee元素，只被Internet Explorer所支持，所以在HTML 5中被废除。其中applet元素可由ernedd元素或object元素替代，bgsound元素可由audio元素替代，marquee可以由javascript编程的方式所替代

　　4、其他被废除的元素：

　　废除rb元素，使用ruby元素替代

　　废除acronym元素，使用abbr元素替代

　　废除dir元素，使用ul元素替代

　　废除isindex元素，使用form元素与input元素相结合的方式替代

　　废除listing元素，使用pre元素替代

　　废除xmp元素，使用code元素替代

　　废除nextid元素，使用GUIDS替代

　　废除plaintext元素，使用“ text/plian” MIME类型替代

　　 四.新增属性和废除属性

　　一、新增属性

　　1、与表单相关属性

　　新增autofocus属性，它以指定属性的方式让元素在画面打开时自动获得焦点；

　　新增placeholder属性，它会对用户的输入进行提示，提示用户可以输入的内容；

　　新增form属性，声明它属于哪个表单，然后将其放置在页面上任何位置，而不是表单之内；

　　新增required属性，该属性表示在用户提交的时候进行检查，检查该元素内一定要有输入内容；

　　2、与链接相关属性

　　增加media属性，该属性规定目标URL是为什么类型的媒介/设备进行优化的，只能在href属性存在时使用；

　　增加hreflang属性与rel属性，以保持与a元素、link元素的一致；

　　3、其他属性

　　属性reverend，它指定列表倒序显示；

　　为script元素增加async属性，它定义脚本是否异步执行；

　　二、废除属性

　　能被CSS样式表替代的属性全部废除掉；

　　多余属性，例如：target、profile、version等被废除掉；

　　五.全局属性

　　在HTML5中，新增了一个’‘全局属性“的概念。所谓全局属性，是指可以对任何元素都使用的属性。

　　1、contentEditable 属性

　　该属性允许用户编辑元素中的内容，可以获得鼠标焦点，属性为布尔值，可被指定为true或false。另外，该属性还有个隐藏inherit状态，为true时，允许编辑，为false时，不允许编辑，未指定时，由inherit决定。

　　2、designMode 属性

　　该属性用来决定整个页面是否可编辑。有两个属性“on”与"off"。属性为"on"时，可编辑，为“off”时，不可编辑。

　　3、hidden属性

　　所有元素都允许使用一个hidden属性，该属性类似于input元素中的hidden元素，功能是通知浏览器不渲染该元素，使该元素处于不可见状态。该属性值为布尔值，为true时，不可见，为false时，可见。

　　4、spellcheck属性

　　该属性是HTML 5针对input元素(type=text) 与textarea这两个文本输入框提供的一个新属性，主要对用户输入内容进行拼写与语法检查。属性值为布尔值，书写时必须明确声明属性值为true或false书写方式如下：

　　详解form属性

　　在HTML4中，表单内的从属元素必须书写在表单内部，但是在HTML5中，可以把他们书写在页面上任何地方，然后给元素制定一个form属性，属性值为该表单单位的id，这样就可以声明该元素从属于指定表单了。

　　input元素从属于表单，它呗书写在表单内部，用不着再对它制定form属性。textarea元素呗书写在表单之外，但它从属于表单，所以表单的id制定给textareea元素的form属性。

　　这样做的好处是当需要给页面中的元素添加样式时可以更方便地添加，因为它们不是被分散在各表单之内的了。

;

Redis与Memcached的区别

传统MySQL+ Memcached架构遇到的问题
　　实际MySQL是适合进行海量数据存储的，通过Memcached将热点数据加载到cache，加速访问，很多公司都曾经使用过这样的架构，但随着业务数据量的不断增加，和访问量的持续增长，我们遇到了很多问题：
　　1.MySQL需要不断进行拆库拆表，Memcached也需不断跟着扩容，扩容和维护工作占据大量开发时间。
　　2.Memcached与MySQL数据库数据一致性问题。
　　3.Memcached数据命中率低或down机，大量访问直接穿透到DB，MySQL无法支撑。
　　4.跨机房cache同步问题。
　　众多NoSQL百花齐放，如何选择
　　最近几年，业界不断涌现出很多各种各样的NoSQL产品，那么如何才能正确地使用好这些产品，最大化地发挥其长处，是我们需要深入研究和思考的问题，实际归根结底最重要的是了解这些产品的定位，并且了解到每款产品的tradeoffs，在实际应用中做到扬长避短，总体上这些NoSQL主要用于解决以下几种问题
　　1.少量数据存储，高速读写访问。此类产品通过数据全部in-momery 的方式来保证高速访问，同时提供数据落地的功能，实际这正是Redis最主要的适用场景。
　　2.海量数据存储，分布式系统支持，数据一致性保证，方便的集群节点添加/删除。
　　3.这方面最具代表性的是dynamo和bigtable 2篇论文所阐述的思路。前者是一个完全无中心的设计，节点之间通过gossip方式传递集群信息，数据保证最终一致性，后者是一个中心化的方案设计，通过类似一个分布式锁服务来保证强一致性,数据写入先写内存和redo log，然后定期compat归并到磁盘上，将随机写优化为顺序写，提高写入性能。
　　4.Schema free，auto-sharding等。比如目前常见的一些文档数据库都是支持schema-free的，直接存储json格式数据，并且支持auto-sharding等功能，比如mongodb。
　　面对这些不同类型的NoSQL产品,我们需要根据我们的业务场景选择最合适的产品。
　　Redis适用场景，如何正确的使用
　　前面已经分析过，Redis最适合所有数据in-momory的场景，虽然Redis也提供持久化功能，但实际更多的是一个disk-backed的功能，跟传统意义上的持久化有比较大的差别，那么可能大家就会有疑问，似乎Redis更像一个加强版的Memcached，那么何时使用Memcached,何时使用Redis呢?
 
如果简单地比较Redis与Memcached的区别，大多数都会得到以下观点：

1  Redis不仅仅支持简单的k/v类型的数据，同时还提供list，set，zset，hash等数据结构的存储。

2  Redis支持数据的备份，即master-slave模式的数据备份。

3  Redis支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用。

抛开这些，可以深入到Redis内部构造去观察更加本质的区别，理解Redis的设计。

在Redis中，并不是所有的数据都一直存储在内存中的。这是和Memcached相比一个最大的区别。Redis只会缓存所有的 key的信息，如果Redis发现内存的使用量超过了某一个阀值，将触发swap的操作，Redis根据“swappability = age*log(size_in_memory)”计 算出哪些key对应的value需要swap到磁盘。然后再将这些key对应的value持久化到磁盘中，同时在内存中清除。这种特性使得Redis可以 保持超过其机器本身内存大小的数据。当然，机器本身的内存必须要能够保持所有的key，毕竟这些数据是不会进行swap操作的。同时由于Redis将内存 中的数据swap到磁盘中的时候，提供服务的主线程和进行swap操作的子线程会共享这部分内存，所以如果更新需要swap的数据，Redis将阻塞这个 操作，直到子线程完成swap操作后才可以进行修改。

使用Redis特有内存模型前后的情况对比：
VM off: 300k keys, 4096 bytes values: 1.3G used
VM on:  300k keys, 4096 bytes values: 73M used
VM off: 1 million keys, 256 bytes values: 430.12M used
VM on:  1 million keys, 256 bytes values: 160.09M used
VM on:  1 million keys, values as large as you want, still: 160.09M used

当 从Redis中读取数据的时候，如果读取的key对应的value不在内存中，那么Redis就需要从swap文件中加载相应数据，然后再返回给请求方。 这里就存在一个I/O线程池的问题。在默认的情况下，Redis会出现阻塞，即完成所有的swap文件加载后才会相应。这种策略在客户端的数量较小，进行 批量操作的时候比较合适。但是如果将Redis应用在一个大型的网站应用程序中，这显然是无法满足大并发的情况的。所以Redis运行我们设置I/O线程 池的大小，对需要从swap文件中加载相应数据的读取请求进行并发操作，减少阻塞的时间。

如果希望在海量数据的环境中使用好Redis，我相信理解Redis的内存设计和阻塞的情况是不可缺少的。
 
补充的知识点：
memcached和redis的比较
1 网络IO模型
　　Memcached是多线程，非阻塞IO复用的网络模型，分为监听主线程和worker子线程，监听线程监听网络连接，接受请求后，将连接描述字pipe 传递给worker线程，进行读写IO, 网络层使用libevent封装的事件库，多线程模型可以发挥多核作用，但是引入了cache coherency和锁的问题，比如，Memcached最常用的stats 命令，实际Memcached所有操作都要对这个全局变量加锁，进行计数等工作，带来了性能损耗。

(Memcached网络IO模型)
　　Redis使用单线程的IO复用模型，自己封装了一个简单的AeEvent事件处理框架，主要实现了epoll、kqueue和select，对于单纯只有IO操作来说，单线程可以将速度优势发挥到最大，但是Redis也提供了一些简单的计算功能，比如排序、聚合等，对于这些操作，单线程模型实际会严重影响整体吞吐量，CPU计算过程中，整个IO调度都是被阻塞住的。
　　2.内存管理方面
　　Memcached使用预分配的内存池的方式，使用slab和大小不同的chunk来管理内存，Item根据大小选择合适的chunk存储，内存池的方式可以省去申请/释放内存的开销，并且能减小内存碎片产生，但这种方式也会带来一定程度上的空间浪费，并且在内存仍然有很大空间时，新的数据也可能会被剔除，原因可以参考Timyang的文章：http://timyang.net/data/Memcached-lru-evictions/
　　Redis使用现场申请内存的方式来存储数据，并且很少使用free-list等方式来优化内存分配，会在一定程度上存在内存碎片，Redis跟据存储命令参数，会把带过期时间的数据单独存放在一起，并把它们称为临时数据，非临时数据是永远不会被剔除的，即便物理内存不够，导致swap也不会剔除任何非临时数据(但会尝试剔除部分临时数据)，这点上Redis更适合作为存储而不是cache。
　　3.数据一致性问题
　　Memcached提供了cas命令，可以保证多个并发访问操作同一份数据的一致性问题。 Redis没有提供cas 命令，并不能保证这点，不过Redis提供了事务的功能，可以保证一串 命令的原子性，中间不会被任何操作打断。
　　4.存储方式及其它方面
　　Memcached基本只支持简单的key-value存储，不支持枚举，不支持持久化和复制等功能
　　Redis除key/value之外，还支持list,set,sorted set,hash等众多数据结构，提供了KEYS
　　进行枚举操作，但不能在线上使用，如果需要枚举线上数据，Redis提供了工具可以直接扫描其dump文件，枚举出所有数据，Redis还同时提供了持久化和复制等功能。
　　5.关于不同语言的客户端支持
　　在不同语言的客户端方面，Memcached和Redis都有丰富的第三方客户端可供选择，不过因为Memcached发展的时间更久一些，目前看在客户端支持方面，Memcached的很多客户端更加成熟稳定，而Redis由于其协议本身就比Memcached复杂，加上作者不断增加新的功能等，对应第三方客户端跟进速度可能会赶不上，有时可能需要自己在第三方客户端基础上做些修改才能更好的使用。
　　根据以上比较不难看出，当我们不希望数据被踢出，或者需要除key/value之外的更多数据类型时，或者需要落地功能时，使用Redis比使用Memcached更合适。
　　关于Redis的一些周边功能
　　Redis除了作为存储之外还提供了一些其它方面的功能，比如聚合计算、pubsub、scripting等，对于此类功能需要了解其实现原理，清楚地了解到它的局限性后，才能正确的使用，比如pubsub功能，这个实际是没有任何持久化支持的，消费方连接闪断或重连之间过来的消息是会全部丢失的，又比如聚合计算和scripting等功能受Redis单线程模型所限，是不可能达到很高的吞吐量的，需要谨慎使用。
　　总的来说Redis作者是一位非常勤奋的开发者，可以经常看到作者在尝试着各种不同的新鲜想法和思路，针对这些方面的功能就要求我们需要深入了解后再使用。
　　总结：
　　1.Redis使用最佳方式是全部数据in-memory。
　　2.Redis更多场景是作为Memcached的替代者来使用。
　　3.当需要除key/value之外的更多数据类型支持时，使用Redis更合适。
　　4.当存储的数据不能被剔除时，使用Redis更合适。