人生第一次写博客，看了看掘金写文章规范的文章，说是不能写入门教程，不知道学习笔记能不能写，很慌。分类也不知道投阅读还是前端。
开始学习前端也有两个星期了，把 MDN 的 CSS 教程看完，JS 教程和 HTML 教程看了一半，本来是先看 HTML 的，结果看到一半教程让我先把 CSS 和 JS 看懂再看后面的。
按照 GitHub 上的这个路线图学习，很直观，比很多意义不明的为了画思维导图而画思维导图的学习路线好太多了。
这个笔记就记录每天学的东西吧，前期写的估计有点杂，希望之后能写一些有帮助的文章。
因为在家自学，所以很多知识都是搜索学习到的，很多东西也许搜出来的博客本身就是错的或者不全面，如果有错，希望能指出来。
1. GET, POST 编码相关
GET 和 POST 的区别网上一大堆，今天刚好看教程对这个感兴趣去查了查，然后有一篇文章提到 GET 只能 URL 编码，而 POST 可以有多种方式编码。然后刚好看 HTML 教程看到 enctype 这个参数。两者之间有关系吗，很好奇，去查了一下。
大概自己理解了一下，不知道有没有错误。
1.1 GET 方法参数在 URL 上，会被 ASCII 编码，英文字符保持原样，其他字符比如说"="以及中文字符等会被编码成 % 分隔的 16 进制字符。这样是为了防止歧义，不然无法区分 = 号， % 号这种字符作为表单参数的值。
1.2 POST 方法参数在请求体上，编码方式可以被 <form> 的 enctype 参数或者 和 <input> 的 formaction 参数指定，默认是application/x-www-form-urlencoded，如果是传输文件用multipart/form-data。其中这个默认application/x-www-form-urlencoded其实就是 GET 方法对 URL 的 ASCII 编码方式。如果用 chrome 的开发者工具打开看，会默认把 POST 的请求体里的参数给解码了，刚开始就是这里让我疑惑为什么 POST 没有被编码。
2. Forms suck
MDN 里推荐了这个 PPT (作者：Jeffrey Wegesin)，是关于介绍如何设计表单，让用户尽量少反感。
1. 以购物网站为例子，用户买东西要注册。
1.1 然而即使是只要填 3 个框的表单，用户都不想填，因为去超市实际购物的时候你什么都不用填。
1.2 现实不仅如此，实际上要填的更多，比如说勾选用户协议，电话号码，姓名，性别，用户填着填着就不想填了直接离开网站。
2. 然后 PPT 开始讲一个叫完形心理学（又叫格式塔，gestalt）的东西，还花了好几张 PPT 解释。
2.1. 理论搞得神乎其神的，其实道理很浅显，就是说人们一眼就能看到在许多规则的东西中那一两个不规则的东西，再来张图，好，讲完了。
上面这个图，你一眼就知道哪里不规则，那么这个现象要怎么运用到表单设计中呢？
是这样的，上面的图，你会认为这个图有两个部分，你会觉得“哦，我要填的东西只有两个部分啊“，但是如果这些东西每个都不规则，你会觉得卧槽我要填这么多部分吗，不填了不填了。
**2.2. ** 然后 PPT 举了个反例嘲讽任天堂，每一个输入框看起来都像单独的一部分，用户一看卧槽我要分别填完十几个部分，根本不想填了。
2.3. 还有一个看起来好像要好一点，但是实际要你填的时候还是很反感。
2.4. 虽然右边的输入框看起来像一部分了，左边的字却又像是各自独立一样。这好吗？这不好。
2.5. 左边的字对齐后，好多了。
2.6. 但是这个更好，把文字放在上面，据说是best practice。
（注：PPT 里没提到的一点我觉得很重要的是，不是说让你把所有的东西都弄同一长度，你看上面的例子，前 4 个关于个人信息的输入框的长度和中间 2 个确认密码的输入框右边的长度是不一样的，这依然是为了让人能快速分组好，一眼就知道“哦，前四个是一组，中间两个是一组”，如果你把所有的东西都弄一个长度，让人觉得这只有一个部分，而这个部分包含 8 个输入框，那依然很不好，这太长了。最终目的是为了让人眼 快速 且 正确 地把这些东西分组）
2.7. 那么为什么这样分组就好呢？因为用户不用思考，你已经帮他分好组了，一眼望去很舒适。
3. 下一个技巧就是那些不必要的信息不用这么早填。
这个技巧很简单，连我都知道。比如说生日什么的，完全可以之后需要的时候再填。
4. 再下一个技巧是关于按钮的，不要依靠按钮上的文字信息。
4.1 还是任天堂的那个例子，不看文字的情况下，你一眼能看出哪个按钮是提交，哪个是返回吗？但是下面这个例子就很好，你一眼就知道哪个是提交，不懂日文都知道。你甚至不用看图，你就看着这一行字，用余光看下面的图你都知道哪个是提交。
4.2. 从上到下，越来越好。（第四个为什么比第三个好，请往下看）
4.3. 懂了吧，因为你眼睛焦点只要一直向下就行，你甚至不用向右看。
5.不要写意义不明的提示，多用标签。
下图中，下面的框明显比上面的框好。谁知道MMM是month，就算知道，你也不知道别人要写JAN还是jan还是Jan。（而且下面的框的文字是在上面，前面的技巧）
6. 不要给用户太多限制，能灵活就灵活地写。
上面的图，不要粗暴地告诉用户必须按照什么格式。
（注：这个我不敢说是好的，因为对于我自己的话，其实我还是很想看到网站告诉我应该怎么填，不然我都有点没有把握，我会想“我这么填不会出问题吧“）
7. 边填边验证。
这个太真实了，填完全部，提交的时候才告诉我哪里错了，我原地爆炸。
8. 提供建议选项。
没什么好说的。
9. 提供例子。
这 PPT 前面才说不要限制用户，我还吐槽了，后面自己又说要有例子限制，佛了。（我是边看边写笔记的，当时没看到这里）
10. 最后 PPT 提供了两个比较好的例子的网址，然后这两个网址都失效了。
3.表单数据验证
1. input 的 type 验证。
2. required， 是否必填。
3. 正则表达式，pattern=“”。
4.输入的长度限制，minlength, maxlength 对于数字来说还有 min , max 控制最大最小值。
5.通过 setCustomValidity 设置错误。
6.使用约束校验 API。
4.自定义表单小部件
跟着MDN教程写一个select表单小部件以下是成果。
5.继续学习HTML又要JS的知识，所以又去继续学习JS。
今天学到了对象，JS的oop和别的不一样，主要围绕着构造器和原型链。并且构造器函数看起来完全就是普通的函数嘛。
于是查了一下，果然构造器函数也可以当普通函数用（不用new去实例化），只是会有问题，如果函数里有this，那么这个this其实会变成window，那么this.name（也就是window.name）其实就是定义了一个全局变量name，这好吗，这不好。
所有的函数都是构造器函数，都有一个prototype属性，这个属性是一个对象，这个对象就叫做原型,也叫原型对象。
然后这个对象有一个属性叫constructor，指的是这个构造函数（也就是说又指回去了，即Person.prototype.constructor === Person）。
还有一个属性叫__proto__（这个属性是浏览器提供的），__proto__指的也是原型，但是这个只能给对象用的（也就是说构造函数和用这个构造函数实例化的对象都可以指向这个函数的原型，但是对象只用能__proto__，函数只能用prototype），比如说我们有一个实例化对象叫做Person1，那么我们有Person1.__proto__ === Person.prototype（注意一个是Person1，另一个是Person）。
（比较重要的一点是构造函数和这个构造函数实例化的对象是同级的, 只论原型方面甚至是毫不相关的两个东西）
此外，事实上所有的构造函数的原型都是Object的实例化对象，那么我们其实有Person.prototype.__proto__ === Object.prototype
而原型链指的是另一回事，是指对象可以继承上层的原型的属性和方法，即Person1可以用Person.prototype的属性和方法，Person.prototype又可以用Object.prototype的属性和方法。当然了，由于浏览器提供了__proto__属性，所以可以很直观的看到原型链。
Person1 → Person1.__proto__ → Person1.__proto__.__proto__
