一、html 系列 ⭐⭐⭐⭐⭐

1、H5新增特性和css3新增特性？

html5：

• ⾸先 html5 为了更好的实践 web 语义化，增加了 header，footer，nav,aside,section 等语义化标签，
• 在表单⽅⾯，为了增强表单，为 input 增加了 color，email,data ,range 等类型，还有一些属性，
• 在存储⽅⾯，提供了 sessionStorage，localStorage,和离线存储，通过这些存储⽅式⽅便数 据在客户端的存储和获取，
• 在多媒体⽅⾯规定了⾳频和视频元素 audio 和 vedio，另外还 有地理定位，canvas 画布，拖放，多线程编程的 web worker 和 websocket协议

css3新增特性：

1. 新的选择器：引入了多种新的选择器，如属性选择器、伪类选择器、伪元素选择器等，使样式选择更加灵活。
2. CSS3 边框如 border-radius，box-shadow 等;
3. CSS3 背景如 background-size，background-origin 等;
4. CSS3 2D，3D 转换如 transtion,transform 等;
5. CSS3 动画如 animation 等；

2、什么是HTML5，以及和HTML的区别是什么？

HTML5是HTML的新标准，其主要目标是无需任何额外的插件如Flash、Silverlight等，就可以传输所有内容。它囊括了动画、视频、丰富的图形用户界面等。

HTML5是由万维网联盟（W3C）和 Web Hypertext Application Technology Working Group 合作创建的HTML新版本。

区别:

1.从文档声明类型上看：

HTML是很长的一段代码，很难记住。如下代码：

HTML5却只有简简单单的声明，方便记忆。如下：

2.从语义结构上看：

HTML4.0：没有体现结构语义化的标签，通常都是这样来命名的

，这样表示网站的头部。

HTML5：在语义上却有很大的优势。提供了一些新的标签，比如：。

3、说说你对 Dom 树的理解？

1.什么是 DOM？

从网络传给渲染引擎的 HTML 文件字节流是无法直接被渲染引擎理解的，所以要将其转化为渲染引擎能够理解的内部结构，这个结构就是 DOM。DOM 提供了对 HTML 文档结构化的表述。

在渲染引擎中，DOM 有三个层面的作用：

• 从页面的视角来看，DOM 是生成页面的基础数据结构。
• 从 JavaScript 脚本视角来看，DOM 提供给 JavaScript 脚本操作的接口，通过这套接口，JavaScript 可以对 DOM 结构进行访问，从而改变文档的结构、样式和内容。
• 从安全视角来看，DOM 是一道安全防护线，一些不安全的内容在 DOM 解析阶段就被拒之门外了。

简言之，DOM 是表述 HTML 的内部数据结构，它会将 Web 页面和 JavaScript 脚本连接起来，并过滤一些不安全的内容。

2.DOM树如何生成？

HTML 解析器（HTMLParser）： 负责将 HTML 字节流转换为 DOM 结构。

那么网络进程是如何将数据传给HTML解析器的呢？

从图中我们可以知道，网络进程和渲染进程之间有一个共享数据通道，网络进程加载了多少数据， 就将数据传给HTML解析器进行解析。

HTML解析器接收到数据（字节流）之后，字节流将转化成DOM，过程如下：

有三个阶段：

• 通过分词器将字节流转化为Token。 分词器先将字节流转换为一个个 Token，分为 Tag Token 和文本 Token。注意，这里的Token并不是我们之前理解的Token，这里就是一个片段。
• Token解析为DOM节点。
• 将 DOM节点添加到DOM树中。

3.JavaScript影响DOM的生成？

我们知道，JavaScript可以修改DOM，它也会影响DOM的生成。

• 内嵌 JavaScript 脚本 比如我们嵌入了一段标签的代码，之前的解析过程都一样，但是解析到script标签时， 渲染引擎判断这是一段脚本，此时 HTML 解析器就会暂停 DOM 的解析， 因为接下来的 JavaScript 可能要修改当前已经生成的 DOM 结构。暂停解析之后，JavaScript 引擎介入，并执行标签中的这段脚本。 脚本执行完成之后，HTML 解析器恢复解析过程，继续解析后续的内容，直至生成最终的 DOM。
• 引入 JavaScript 文件 基本上跟之前是一致的，不同点在于，暂停解析之后执行JavaScript 代码，需要先下载这段 JavaScript 代码。

4、跨域时怎么处理 cookie？

一个请求从发出到返回，需要浏览器和服务端的协调配合。浏览器要把自己的请求参数带给服务端，服务端校验参数之后，除了返回数据，也可能会顺便把请求是否缓存，cookie等信息告诉浏览器。当请求是跨域请求的时候，这个过程还要复杂一些。接下来咱们就看看跨域会有什么问题，又需要前后端进行怎样的配合。

1.普通跨域

我有一个朋友，叫小王。前端小王和后端同事小马准备联调一个登录的api。假设是/login;小王在把登录账号和密码都准备好之后，愉快的发起了post提交。结果很意外，请求的响应被浏览器拦截了，浏览器还贴心的在console上抛出了一个错误。

小王翻译了一下，原来是被CORS策略拦截掉了。这个策略大概意思是说，服务端如果允许不同origin的请求，那就需要在返回的response header里面带上Access-Control-Allow-Origin这个header。否则浏览器在拿到响应并发现响应头里没有这个header时，就会把响应给吞掉，而不会交给js进行下一步处理。

小王把这个事情告诉了小马，然后小马在返回的header中加上了

1Access-Control-Allow-Origin: *

现在小王终于可以拿到返回的结果了。

这里要注意，浏览器不是在请求阶段就对请求进行拦截，而是正常发出请求，拿到服务端的响应之后，开始查看响应header里面有没有Access-Control-Allow-Origin这个header，如果没有，响应的结果就不会到js那里去。

2.非简单请求的跨域

后来小王觉得在post中发送表单格式的body太麻烦，希望使用JSON格式的请求体提交。小马觉得就是几行代码的事，就同意了。但是小王改成JSON的消息体之后发现又被CORS拦截了，并抛出了下面的错误：

在上面的报错中，我们看到了 preflight 的单词。那这又是怎么回事呢？原来，修改请求体之后，这个跨域请求不再是简单请求了，需要在发起请求之前先进行 preflight 请求。那么什么是简单请求呢？

• 请求方法包括GET, HEAD, POST
• response header里面不能包含cors安全header以外的header。
• Content-Type 只限于text/plain, multipart/form-data, application/x-www-form-urlencoded

由于json数据的content-type导致这个post请求不再是简单请求，而对于非简单请求，之前允许所有域名跨域访问是被禁止的。所以还是要修改Access-Control-Allow-Origin为特定的请求域名。在开发模式下，可能是http://localhost:3000之类的。

小马在重新修改Access-Control-Allow-Origin，小王又拿到了登录成功的结果。可以联调下一个api了。

3.带cookie的跨域

登录是基于session的，也就是说，登录成功后，server会通过set-cookie，将cookie设置到浏览器中，这样，下次访问同源下的api时，cookie就会被带上。

然而，奇怪的是，小王发现登录成功后，调用别的接口，cookie并没有被带上，导致server无法识别出用户信息，最终返回错误（状态码为401）。

4.withCredentials

原来，浏览器发起跨域请求的时候，是不会主动带上cookie的，如果一个请求需要cookie，需要开发者设置一个选项，以fetch api为例：

fetch('http://baidu.com:3000', {
    // ...
  credentials: 'include'
})

如果使用xhr api来请求，则需要这样写：

var invocation = new XMLHttpRequest();
var url = 'http://bar.other/resources/credentialed-content/';
function callOtherDomain(){
  if(invocation) {
    invocation.open('GET', url, true);
    invocation.withCredentials = true; // 带上cookie
    invocation.onreadystatechange = handler;
    invocation.send();
  }
}

小王在设置请求之后又发起了一次请求。却发现cookie还是没有带上去。小王只好在MDN继续查看资料，发现在set-cookie时需要带一个sameSite的属性。

5.sameSite

sameSite是为了防止csrf攻击而产生的属性，如果不知道啥是CSRF攻击，可以自己先去查一下。

由于我们需要在请求中带上cookie，所以需要在set-cookie时将cookie的sameSite设置为none；又由于将sameSite设置为none时，也需要将Secure设置上，所以请求需要基于https;

小王最后一次请求小马对api进行了上诉更改，服务器终于认出请求来自谁，并返回了正确的结果，跨域的踩坑之旅算是告一段落。

6.总结

很多时候，我们可能只会关注请求体是什么，响应有没有正确返回，而忽略了header部分。殊不知，header在缓存，web安全，浏览器正确解析结果中发挥了重要的作用，比如本文中的一系列Access-Control-Allow-*的header。

为了让web更安全，CORS还在不断地更新，比如这个提案，规定从公网到私网，或者从私网访问local network时，需要设置跨域头，Access-Control-Allow-Private-Network。