七小时带你入门HTML+CSS网页设计，知识准备与开发工具（一）

家好，我会用大概七个小时的时间同大家一起入门HTML+CSS网页设计，其实全部系列加起来也就1个小时左右，剩下的时间是让大家复习知识和练习写代码的，俗话说的好，七小时入门，成神靠个人。所以希望大家学习后一定要自己多练习，多练习，多练习。

本篇主要内容是给大家介绍HTML+CSS的基础知识和开发工具的推荐

HTML是什么：

html是一种描述网页的标记语言（记住，不是编程语言），我们用浏览器打开的网页都是用html来编写的。它的组成部分是由一对尖括号包围，如：<html>、<body>等，通常是成对出现，有开头就有结束，结束用斜线区分，如：<html>内容</html>等。

html是一种描述网页的标记语言

CSS是什么：

css是用来控制html网页的样式和布局的，比如网页的颜色，尺寸和轮廓，写法也很简单。

css是用来控制html网页的样式和布局

那么html与css的相互作用是什么？说小白一点，html就像一个毛坯房，只有房子的基础框架，而css就像房屋装修，同样的html结构用不同的css能设计出各种各样的网页样式。

html+css效果图

开发工具：

这里给大家推荐notepad++，操作简单而且还免费，非常适合新入门的同学使用，浏览器可以选择谷歌浏览器或者360安全浏览器等，我这里使用谷歌浏览器为大家做演示。

notepad++

下面给大家贴上常用的HTML+CSS标签，不要去死记硬背，后面多练习自然就会了：

<!--HTML标签-->
<h1>这是一个标题</h1> <!--标题-->
<p>这是一段文字</p> <!--段落-->
<a href="https://www.toutiao.com/" target="_blank"></a> <!--连接地址-->
<img src="http://tpt360.com/img/logo.png"> <!--一张图片-->
<div id="content" class="content"></div> <!--布局-->
<!--列表-->
<ul>
<li>列表1</li>
<li>列表1</li>
</ul>
<!--表格-->
<table>
<tr>
<th>姓名</th>
<th>年龄</th>
</tr>
<tr>
<td>小张</td>
<td>小明</td>
</tr>
<tr>
<td>6岁</td>
<td>8岁</td>
</tr>
</table>
<!--表单-->
<form>
<input type="text" name="mingzi">
<input type="text" name="nianling">
</form>
<!--视频-->
<video width="320" height="240" controls>
<source src="movie.mp4" type="video/mp4">
</video>
/*CSS标签*/
width: 100px; /*宽度*/
height: 100px; /*高度*/
line-height: 100px; /*行高*/
padding: 0px 0px 0px 0px; /*内边距*/
margin: 0px 0px 0px 0px; /*外边距*/
float: left; /*左浮动*/
float: right; /*右浮动*/
color: #000; /*字体颜色*/
background: #fff; /*背景颜色*/
font-size: 18px; /*字体大小*/
font-weight: 700; /*字体粗细*/
text-align: center; /*居中*/
a:hover {color: #FFF;} /*鼠标浮动字体变色*/
border-radius: 6px; /*边角大小*/
border: 1px solid #CDCDCD; /*全边框*/

下篇我将给大家具体介绍使用方法，谢谢观看！！！

网页展现的更快，官方说法叫做首屏绘制，First Paint 或者简称 FP，直白的说法叫做白屏时间，就是从输入 URL 到真的看到内容（不必可交互，那个叫 TTI, Time to Interactive）之间经历的时间。当然这个时间越短越好。

但这里要注意，和首屏相关的除了 FP 还有两个指标，分别称为 FCP (First Contentful Paint，页面有效内容的绘制) 和 FMP (First Meaningful Paint，页面有意义的内容绘制)。虽然这几个概念可能会让我们绕晕，但我们只需要了解一点：首屏时间 FP 并不要求内容是真实的，有效的，有意义的，可交互的。换言之，随便给用户看点啥都行。

这就是本文标题的玄机了：“看起来”。是的，只是看起来更快，实际上还是那样。所以本文并不讨论性能优化，讨论的是一个投机取巧的小伎俩，但的确能够实实在在的提升体验。打个比方，性能优化是修炼内功，提升你本身的各项机能；而本文接下来要讨论的是一些招式，能让你在第一时间就唬住对手。

这所谓的招式就是我接下来要谈的内容，学名骨架屏，也叫 Skeleton。你可能没听过这个名字，但你不可能没见过它。

骨架屏长什么样

这种应该是最常见的形式，使用各种形状的灰色矩形来模拟图片和文字。有些 APP 也会使用圆形，但重点都是和实际内容结构近似，不能差距太大。

如果追求效果，还可以在色块表面添加动画（如波纹），显示出一种动态的效果，算是致敬 Loading 了。

在图片居多的站点，这将会是一个很好的体验，因为图片通常加载较慢。如上图演示中的占位图片采用了低像素的图片，即大体配色和变化是和实际内容一致的。

如果无法生成这样的低像素图片，稍微降级的方案是通过算法获取图片的主体颜色，使用纯色块占位。

再退一级，还可以使用全站相同的站位图片，或者直接一个统一颜色的色块。虽说效果肯定不如上面两种，但也聊胜于无。

骨架屏完全是自定义的，想做成什么样全凭你的想象。你想做圆形的，三角形的，立体的都可以，但“占位”决定了它的特性：它不能太复杂，必须第一时间，最快展现出来。

骨架屏有哪些优势

大体来说，骨架屏的优势在于：

1、在页面加载初期预先渲染内容，提升感官上的体验。

2、一般情况骨架屏和实际内容的结构是类似的，因此之后的切换不会过于突兀。这点和传统的 Loading 动图不同，可以认为是其升级版。

3、只需要简单的 CSS 支持 (涉及图片懒加载可能还需要 JS )，不要求 HTTPS 协议，没有额外的学习和维护成本。

4、如果页面采用组件化开发，每个组件可以根据自身状态定义自身的骨架屏及其切换时机，同时维持了组件之间的独立性。

骨架屏能用在哪里

现在的 WEB 站点，大致有两种渲染模式：

前端渲染

由于最近几年 Angular/React/Vue 的相继推出和流行，前端渲染开始占据主导。这种模式的应用也叫单页应用（SPA, Single Page Application）。

前端渲染的模式是服务器（多为静态服务器）返回一个固定的 HTML。通常这个 HTML 包含一个空的容器节点，没有其他内容。之后内部包含的 JS 包含路由管理，页面渲染，页面切换，绑定事件等等逻辑，所以称之为前端渲染。

因为前端要管理的事情很多，所以 JS 通常很大很复杂，执行起来也要花较多的时间。在 JS 渲染出实际内容之前，骨架屏就是一个很好的替补队员。

后端渲染

在这波前端渲染流行之前，早期的传统网站采用的模式叫做后端渲染，即服务器直接返回网站的 HTML 页面，已经包含首页的全部（或绝大部分） DOM 元素。其中包含的 JS 的作用大多是绑定事件，定义用户交互后的行为等。少量会额外添加/修改一些 DOM，但无碍大局。

此外，前端渲染的模式存在 SEO 不友好的问题，因为它返回的 HTML 是一个空的容器。如果搜索引擎没有执行 JS 的能力（称为 Deep Render），那它就不知道你的站点究竟是什么内容，自然也就无法把站点排到搜索结果中去。这对于绝大部分站点来说是不可接受的，于是前端框架又相继推出了服务端渲染（简称 SSR, Server Side Rendering）模式。这个模式和传统网站很接近，在于返回的 HTML 也是包含所有的 DOM，而非前端渲染。而前端 JS 除了绑定事件之外，还会多做一个事情叫做“激活”（hydration），这里就不再赘述了。

不论是传统模式还是 SSR，只要是后端渲染，就不需要骨架屏。因为页面的内容直接存在于 HTML，所以并没有骨架屏出场的余地。

骨架屏怎么用

讨论了一波背景，我们来看如何使用。首先先无视具体的实现细节，先看思路。

实现思路

大体分为几个步骤：

往本应为空的容器节点内部注入骨架屏的 HTML。
骨架屏为了尽快展现，要求快速和简单，所以骨架屏多数使用静态的图片。而且把图片编译成 base64 编码格式可以节省网络请求，使得骨架屏更快展现，更加有效。

<html>
 <head>
 <style>
 .skeleton-wrapper {
 // styles
 }
 </style>
 <!-- 声明 meta 或者引入其他 CSS -->
 </head>
 <body>
 <div id="app">
 <div class="skeleton-wrapper">
 <img src="data:image/svg+xml;base64,XXXXXX">
 </div>
 </div>
 <!-- 引用 JS -->
 </body>
</html>

在执行 JS 开始真正内容的渲染之前，清空骨架屏 HTML
以 Vue 为例，即在 mount 之前清空内容即可。

let app = new Vue({...})
let container = document.querySelector('#app')
if (container) {
 container.innerHTML = ''
}
app.$mount(container)

仅此两步，并不牵涉多么复杂的机制和高端的 API，因此非常容易应用，赶快用起来！

示例

我编写了一个示例，用于快速展现骨架屏的效果，代码在此。

index.html
默认包含了骨架屏，并且内联了样式（以 <style> 标签添加在头部）。
render.js
它负责创建 DOM 元素并添加到 <body> 上，渲染页面实际的内容，用来模拟常见的前端渲染模式。
index.css
页面实际内容的样式表，不包含骨架屏的样式。

代码的三个文件各司其职，配合上面的实现思路，应该还是很好理解的。可以在这里查看效果。

因为这个示例的逻辑太过简单，而实际的前端渲染框架复杂得多，包含的功能也不单纯是渲染，还有状态管理，路由管理，虚拟 DOM 等等，所以文件大小和执行时间都更大更长。我们在查看例子的时候，把网络调成 "Fast 3G" 或者 "Slow 3G" 能够稍微真实一些。

但匪夷所思的是，对着这个地址刷新试几次，我也基本看不到骨架屏（骨架屏的内容是一个居中的蓝色方形图片，外加一条白色横线反复侧滑的高亮动画）。是我们的实现思路有问题吗？

浏览器的奥秘：减少重排

为了排除肉眼的遗漏和干扰，我们用 Chrome Dev Tools 的 Performance 工具来记录刚才发生了什么，截图如下：（截图时的网络设置为 "Fast 3G"）

我们可以很明显地看到 3 个时间点：

1、HTML 加载完成了。浏览器在解析 HTML 的同时，发现了它需要引用的 2 个外部资源 index.js 和 index.css，于是发送网络请求去获取。

2、获取成功后，执行 JS 并注册 CSS 的规则。

3、JS 一执行，很自然的渲染出了实际的内容，并应用了样式规则（随机颜色的横条）。

我们的骨架屏呢？按照预想，骨架屏应该出现在 1 和 2 之间，也就是在获取 JS 和 CSS 的同时，就应该渲染骨架屏了。这也是我们当时把骨架屏的 HTML 注入到 index.html，还把 CSS 从 index.css 中分离出来的良苦用心，然而浏览器并不买账。

这其实和浏览器的渲染顺序有关。

相信大家都整理过行李箱。我们在整理行李箱时，会根据每个行李的大小合理安排，大的和小的配合，填满一层再放上面一层。现在突然有人跑来跟你说，你的电脑不用带了，你要多带两件衣服，你不能带那么多瓶矿泉水。除了想打他之外，为了重新整理行李箱，必然需要把整理好的行李拿出来再重新放。在浏览器中这个过程叫做重排 (reflow)，而那个馊主意就是新加载的 CSS。显而易见，重排的开销是很大的。

熟能生巧，箱子理多了，就能想出解决办法。既然每个 CSS 文件加载都可能触发重绘，那我能不能等所有 CSS 加载完了一起渲染呢？正是基于这一点，浏览器会等 HTML 中所有的 CSS 都加载完，注册完，一起应用样式，力求一次排列完成工作，不要反复重排。看起来浏览器的设计者经常出差，因为这是一个很正确的优化思路，但应用在骨架屏上就出了问题。

我们为了尽早展现骨架屏，把骨架屏的样式从 index.css 分离出来。但浏览器不知道，它以为骨架屏的 HTML 还依赖 index.css，所以必须等它加载完。而它加载完之后，render.js 也差不多加载完开始执行了，于是骨架屏的 HTML 又被替换了，自然就看不到了。而且在等待 JS, CSS 加载的时候依然是个白屏，骨架屏的效果大打折扣。

所以我们要做的是告诉浏览器，你放心大胆的先画骨架屏，它和后面的 index.css 是无关的。那怎么告诉它呢？

告诉浏览器先渲染骨架屏

我们在引用 CSS 时，会使用 <link rel="stylesheet" href="xxxx> 这样的语法。但实际上，浏览器还提供了其他一些机制确保（后续）页面的性能，我们称之为 preload，中文叫预加载。具体来说，使用 <link rel="preload" href="xxxx">，提前把后续要使用的资源先声明一下。在浏览器空闲的时候会提前加载并放入缓存。之后再使用就可以节省一个网络请求。

这看似无关的技术，在这里将起到很大的作用，因为预加载的资源是不会影响当前页面的。

我们可以通过这种方式，告诉浏览器：先不要管 index.css，直接画骨架屏。之后 index.css加载回来之后，再应用这个样式。具体来说代码如下：

<link rel="preload" href="index.css" as="style" onload="this.rel='stylesheet'">

方法的核心是通过改变 rel 可以让浏览器重新界定 <link> 标签的角色，从预加载变成当页样式。（另外也有文章采用修改 media 的方法，但浏览器支持度较低，这里不作展开了。我把文章列在最后了）这样的话，浏览器在 CSS 尚未获取完成时，会先渲染骨架屏（因为此时的 CSS 还是 preload，也就是后续使用的，并不妨碍当前页面）。而当 CSS 加载完成并修改了自己的 rel之后，浏览器重新应用样式，目的达成。

不得不考虑的注意点

事实上，并不是把 rel="stylesheet" 改成 rel="preload" 就完事儿了。在真正应用到生产环境之前，我们还有很多事情要考虑。

兼容性考虑

首先，在 <link> 内部我们使用了 onload，也就是使用了 JS。为了应对用户的浏览器没有开启脚本功能的情况，我们需要添加一个 fallback。（不过这点对于单页应用来说可能也无所谓，因为如果没有脚本，那页面实际内容也渲染不出来的）

<noscript><link rel="stylesheet" href="index.css"></noscript>

其次，rel="preload" 并不是没有兼容性问题。对于不支持 preload 的浏览器，我们可以添加一些 polyfill 代码（来使所有浏览器获得一致的效果。

<script>
/*! loadCSS rel=preload polyfill. [c]2017 Filament Group, Inc. MIT License */
(function(){ ... }());
</script>

polyfill 的压缩代码可以参见 Lavas 的 SPA 模板第 29 行。

加载顺序

不同于传统页面，我们的实际 DOM 是通过 render.js 生成的。所以如果 JS 先于 CSS 执行，那将会发生跳动。（因为先渲染了实际内容却没有样式，而后样式加载，页面出现很明显的变化）所以这里我们需要严格控制 CSS 早于渲染。

<link rel="preload" href="index.css" as="style" onload="this.rel='stylesheet';window.STYLE_READY=true;window.mountApp && window.mountApp()">

JS 对外暴露一个 mountApp 方法用于渲染页面（其实是模拟 Vue 的 mount）

// render.js
function mountApp() {
 // 方法内部就是把实际内容添加到 <body> 上面
}
// 本来直接调用方法完成渲染
// mountApp()
// 改成挂到 window 由 CSS 来调用
window.mountApp = mountApp()
// 如果 JS 晚于 CSS 加载完成，那直接执行渲染。
if (window.STYLE_READY) {
 mountApp()
}

如果 CSS 更快加载完成，那么通过设置 window.STYLE_READY 允许 JS 加载完成后直接执行；而如果 JS 更快，则先不自己执行，而是把机会留给 CSS 的 onload。

清空 onload

loadCSS 的开发者提出，某些浏览器会在 rel 改变时重新出发 onload，导致后面的逻辑走了两次。为了消除这个影响，我们再在 onload 里面添加一句 this.onload=null。

最终的 CSS 引用方式

<link rel="preload" href="index.css" as="style" onload="this.onload=null;this.rel='stylesheet';window.STYLE_READY=true;window.mountApp && window.mountApp()">
<!-- 为了方便阅读，折行重复一遍 -->
<!-- this.onload=null -->
<!-- this.rel='stylesheet' -->
<!-- window.STYLE_READY=true -->
<!-- window.mountApp && window.mountApp() -->

修改后的效果

修改后的代码在这里，访问地址在这里。（为了简便，我省去了处理兼容性的代码，即 <noscript> 和 preload polyfill）

Performance 截图如下：（依然采用了 "Fast 3G" 的网络设置）

这次在 render.js 和 index.css 还在加载的时候页面已经呈现出骨架屏的内容，实际肉眼也可以观测到。在截图的情况下，骨架屏的展现大约持续了 300ms，占据整个网络请求的大约一半时间。

至于说为什么不是 HTML 加载完成立马展现骨架屏，而是还要等大约 300ms 才展现，从图上看是浏览器 ParseHTML 所花费的时间，可能在 Dev Tools 打开的情况下计算资源有限，不过可优化空间已经不大。（可能简化骨架屏的结构能起一些作用吧）

多骨架屏的支持

一般来说一个站点的所有页面不太可能是同一种展示类型。例如说首页和内部页面就展示风格而言会很有区别，另外例如列表页和搜索页比较接近（可能都有列表展示），但和详情页（可能是商品，服务，个人信息，博客文章等等）就会很不相同。但单页应用的 index.html 只有一个，所有的变化都源自前端渲染框架在容器节点内部进行改变。所以直接将骨架屏注入到 index.html中会导致所有的页面都用同一个骨架屏，那就很难达成“和实际内容结构类似”的目标了，骨架屏就退化为 Loading 了。

为了要支持多种骨架屏，我们需要在 index.html 里面进行判断逻辑（独立于主体 JS 之外），具体来说：

1、把所有种类的骨架屏的 HTML 和样式全部写入 index.html

2、在 index.html 底下新增内联的脚本 <script>，根据当前路由判断应该展示哪一个骨架屏

这样会导致 index.html 体积变大一点，但整体感觉依然是收益大于付出，我认为是值得的。

后记

这个优化点最早由我的前同事 xiaop 同学在开发 Lavas 的 SPA 模板中发现并完成的，Issue 记录在此。我在他的基础上，做了一个分离 Lavas 和 Vue 环境并且更直白的例子，让截图也尽可能易于理解，方便阅读。在此非常感谢他的工作！

另外骨架屏的编写我全部采用的是纯粹的手写 HTML 和 CSS，不止展现逻辑，包括开发流程也是独立于单页应用其他常规页面的。当然这可能给开发者带来一点不便，所以这时候需要推出 xiaop 同学的利器：vue-skeleton-webpack-plugin https://github.com/lavas-project/vue-skeleton-webpack-plugin。它的作用是把骨架屏本身也当成一个 Vue 组件，配上单独的路由规则来统一在 Vue 项目中的开发体验，最后使用 webpack 在打包构建的时候加以区分并注入，对于使用 Vue + webpack 开发的同学来说可以一试。

参考文章

让骨架屏更快渲染 https://zhuanlan.zhihu.com/p/34550387- xiaop 同学原作
Loading CSS without blocking render https://keithclark.co.uk/articles/loading-css-without-blocking-render/- 使用修改 media 的方式达成目的。
filamentgroup/loadCSS https://github.com/filamentgroup/loadCSS - 同样使用修改 rel 的方式，并提供了 preload polyfill

转自作者作者：小蘑菇小哥https://zhuanlan.zhihu.com/p/48601348

言

在前端开发的世界里，JavaScript如同魔法师手中的魔杖，而DOM（Document Object Model）则是施展魔法的舞台。掌握DOM，意味着能够动态地改变网页的结构、样式和行为，为用户带来丰富的交互体验。本文旨在带你深入了解DOM，从其基本概念出发，直至实战应用，帮助你成为前端领域的“魔法师”。

技术概述

定义DOM

DOM是一种树状结构模型，用于表示HTML或XML文档的结构。它将文档视为一个由节点组成的树，每个节点都是一个对象，可以是元素节点、属性节点、文本节点等。DOM允许JavaScript读取和修改页面的内容和布局。

核心特性与优势

可编程性：DOM提供了API，让开发者能够通过脚本动态地访问和修改文档。
兼容性：所有现代浏览器均支持DOM标准。
灵活性：能够创建、读取、更新或删除节点，以及处理事件和样式。

代码示例

// 获取元素节点
const element = document.getElementById('myElement');
// 修改内容
element.textContent = 'Hello, DOM!';

技术细节

DOM结构解析

DOM树的根节点通常是<html>元素，下面挂载着<head>和<body>等子节点。每个节点都有自己的属性和方法，如appendChild()、removeChild()等，用于操作DOM结构。

难点剖析

性能考量：频繁的DOM操作可能导致页面重绘和回流，影响性能。
异步处理：DOM操作往往与事件监听器或AJAX请求结合，需要理解异步编程。

实战应用

场景：动态加载内容

假设我们要在用户滚动页面时动态加载更多数据。

window.addEventListener('scroll', function() {
  if (window.scrollY + window.innerHeight >= document.body.scrollHeight) {
    loadMoreData();
  }
});

function loadMoreData() {
  fetch('/api/data')
    .then(response => response.json())
    .then(data => {
      data.forEach(item => {
        const newNode = document.createElement('div');
        newNode.textContent = item.title;
        document.getElementById('content').appendChild(newNode);
      });
    });
}

优化与改进

性能瓶颈分析

减少重绘和回流：批量操作DOM，利用文档片段DocumentFragment。
缓存查询结果：避免重复使用getElementById或querySelector。

代码示例

const fragment = document.createDocumentFragment();
data.forEach(item => {
  const newNode = document.createElement('div');
  newNode.textContent = item.title;
  fragment.appendChild(newNode);
});
document.getElementById('content').appendChild(fragment);

常见问题

如何高效选择元素？

使用ID选择器最快，其次是类选择器，避免使用过于复杂的选择器链。

如何避免DOM操作引起的性能下降？

使用requestAnimationFrame进行动画和DOM更新。
在隐藏元素中进行DOM操作，完成后显示元素。

总结与展望

DOM作为JavaScript与HTML文档交互的桥梁，其重要性不言而喻。掌握DOM，意味着能够灵活地控制网页的表现，提升用户体验。随着Web组件、Shadow DOM等新技术的出现，DOM的未来充满无限可能，期待你在前端领域施展更多的魔法，创造更多精彩的应用。

在线咨询

上一篇：1-html基本知识
下一篇：学做html5课件手机浏览不喜勿喷

您的项目需求

*请认真填写需求信息，我们会在24小时内与您取得联系。

整合营销服务商

七小时带你入门HTML+CSS网页设计，知识准备与开发工具（一）

言

技术概述

定义DOM

核心特性与优势

代码示例

技术细节

DOM结构解析

难点剖析

实战应用

场景：动态加载内容

优化与改进

性能瓶颈分析

代码示例

常见问题

如何高效选择元素？

如何避免DOM操作引起的性能下降？

总结与展望

您的项目需求