前言
最近学了winter老师的课程-重学前端,想一边学习课程一边梳理相关知识,重构自己的前端知识体系。
HTML相关
语义化
语义类标签是纯文字的补充,比如标题、自然段、列表等纯文字不能表达的,需要依赖语义标签。在代码中使用nav、p或者html5的新标签header、footer、section、article等就是语义化。
那么,不使用语义化,只使用div和span可以吗?
当今互联网产品中,HTML用于描述“软件界面”多过于“富文本”,而软件界面中,比如购物车功能中每个购物车里面的商品和文本中的列表,以及按钮和表单中的Button,其实已经相差很远了,
结论:支持在任何“软件界面”的场景中,直接使用div和span
语义化的优点
但是,在很多工作场景中,正确使用语义标签的好处也显而易见:
- 对开发者友好,便于与他人协作。使用语义标签增强了可读性,即使没有CSS,开发者也能够清晰的看出页面结构,便于团队的开发和协作。
- 让计算机能够快速的读懂内容,高效的处理信息,可以对搜索引擎(SEO)更友好。可以让搜索引擎爬虫更好的获取到更多有效的信息,有效提升网页的搜索量,并且语义类还可以支持读屏软件,根据文章可以自动生成目录。
爬虫下载到我们网页的 HTML 代码,搜索引擎如何更好地去理解网页的内容呢?
答:根据 HTML 既定的标签。
- h1标签就代表是标题
- p里面的就是段落详细内容,权重肯定没有标题高
- ul里面就是列表
- strong就是加粗的强调的内容
书写 HTML 时,恰当的使用语义化是非常重要的,是 W3C 辛辛苦苦制定出的标准。
不恰当的使用语义标签会产生副作用
误区:给所有的并列关系都套上ul -> 会导致大量冗余标签
正确使用:ul多数出现在行文中间,它的上文多数在提示:要列举某些项。
综上,错误的使用语义标签,会给机器阅读造成障碍、增加嵌套,给CSS编写增加负担。
态度:用对 > 不用 > 用错
重要的语义标签使用场景
-
自然语言表达能力的补充:ruby、rt、rp
-
没有该语义标签会产生歧义:em
-
文章标题摘要:hgroup、section+h1
-
适合机器阅读的整体结构:
场景:越来越多的浏览器推出“阅读模式”,以及各种非浏览器终端的出现,语义化HTML适合机器阅读的特性变得越来越重要。
应用了语义化结构的页面,可以明确地提示出页面信息的主次关系,它能让浏览器很好第支持“阅读视图功能”,还可以让搜索引擎的命中率提升,同时,它也对市场用户的读屏软件更友好。
正确的使用整体结构类的语义标签:
<body> <header> <nav> …… </nav> </header> <aside> <nav> …… </nav> </aside> <section>……</section> <section>……</section> <section>……</section> <footer> <address>……</address> </footer> </body>
类似报纸的多文章结构适合用article组织:
<body> <header>……</header> <article> <header>……</header> <section>……</section> <section>……</section> <section>……</section> <footer>……</footer> </article> <article> …… </article> <article> …… </article> <footer> <address></address> </footer> </body>
用语义类标签呈现网页
- 侧边栏aside:属于导航性质的工具内容
- 文章article:具有明确独立性的主体部分
- 缩写:abbr
- 很长的横线:CSS的border或hr
注:hr表示故事走向的转变或者话题的转变 - 黑体呈现:strong
- 引述:blockquote(段落级)、q(行内)、cite(作品名)
- 日期:time
- 表示与主文章相关的图像、照片等流内容:figure
- 包裹被定义的名词:dfn
- 导航:nav
- 内容是预先排版过的,不需要浏览器进行排版:pre
- 计算机程序的示例输出:samp
- 代码块:code
重要html标签补充说明
html标签Html5中除了新标签之外增加了哪些新特性
- 显著的性能优化 Web Worker
- XMLHttpRequest2
- WebSocket
- 多线程
- 新的DOCTYPE声明 <!DOCTYPE html>
- 完全支持css3
- video和audio
- 本地存储 Web Storage
- 高效地离线运行(离线资源、在线和离线事件、DOM存储、IndexDB、自web应用程序中使用文件[FileReader])
- 语义化标签
- canvas、webGL
- HistoryAPI
- requestAnimationFrame
- 全屏API和指针锁定API
- 新事件 如ondrag(拖放) onresize
- 新的表单控件,比如 calendar、date、time、email、url、search
- 移除了纯表现的元素,对可用性产生负面影响的元素
- 数据属性[data-min:"0"]
如何清除页面缓存效果
浏览器缓存文件更改,样式不变如何解决:
在引入的缓存文件链接后面添加时间戳或Math.radom()
defer和async
defer:渲染完在执行
async: 下载完就执行
JS 会阻塞后续 DOM 解析以及其它资源(如 CSS,JS 或图片资源)的加载。
- 由于现代浏览器都存在 prefetch(DNS预解析),所以 defer, async 可能并没有太多的用途,仅仅将脚本文件放到 body 底部就可以起到很不错的优化效果。
- defer 和 async 都是异步加载脚本文件:
- defer:加载后续文档元素的过程将和
script.js
的加载并行进行,但是script.js
的执行要在所有元素解析完成之后,DOMContentLoaded
事件触发之前完成。 - async:加载和渲染后续文档元素的过程将和
script.js
的加载与执行并行进行。 - 差别在于脚本下载完之后何时执行,显然 defer 是最接近我们对于应用脚本加载和执行的要求的
- defer:加载后续文档元素的过程将和
- 慎用 async,因为它完全不考虑依赖关系,只要下载完后就加载,不考虑此时页面样式先后的加载顺序,不过它对于那些可以不依赖任何脚本或不被任何脚本依赖的脚本来说却是非常合适的,最典型的例子:Google Analytics。
-
耗时较长的脚本代码可以使用 defer 来推迟执行。
defer和async
网友评论