整合营销服务商

电脑端+手机端+微信端=数据同步管理

免费咨询热线:

「早读课」如何理解Display:None,Bloc

「早读课」如何理解Display:None,Block,Inline,Inline-Block

天的早读课,笔者将介绍Display的相关属性,主要涉及的内容包含:

  • display: none vs. visibility: hidden
  • display: block
  • display: inline
  • display: inline-block

Display: None vs. Visibility: Hidden

如下段代码所示,我们有三个红、蓝、绿的方块,如下段代码所示:

#box-1 {
 width: 100px;
 height: 100px;
 background: red;
}
#box-2 {
 width: 100px;
 height: 100px;
 background: blue;
}
#box-3 {
 width: 100px;
 height: 100px;
 background: green;
}
div {
 display: inline-block;
}
body {
 background: #efefef;
}
<div id="box-1"></div>
<div id="box-2"></div>
<div id="box-3"></div>

首先我们先使用 display: none 属性隐藏蓝色的方块,如下段代码所示:

#box-2 {
 display: none;
 width: 100px;
 height: 100px;
 background: blue;
}

如上图所示,使用Display: None,我们可以看出蓝色方块从中“删除”,中间的空位也被绿色的方块补位。

接着我们使用 visibility: hidden 属性隐藏蓝色方块,如下段代码所示:

#box-2 {
 width: 100px;
 height: 100px;
 background: blue;
 visibility: hidden;
}

从上图我们看出,使用Visibility: Hidden,我们实现了蓝色方块的“隐藏”,中间的位置空缺保留。

Block vs. Inline

Block块级元素默认填满父级元素内容区域,旁边不能有其他元素,最常见的块级元素就是<div>,<p>,<ul> 等。

Inline行内元素在一行文本内生成元素框,不打断所在的行。最常见的行内元素比如:<span>,<img>,<a>。首先我们下段没有CSS的Html代码:

<body>
 <p>I'm a paragraph</p>
 <p>I'm a paragraph too</p>
 <span>I'm a word</span>
 <span>I'm a word too.</span>
</body>

从上图我们看出:

两个<p>元素占了两行,两个<span>元素占了一行,由此可见每个Html元素都有个默认的display属性:block或inline。

以下是关于 Block 和 Inline 差异的总结:

Block

  • 默认100%占满父元素区域
  • 每个元素占一行
  • 可以设置width和height属性
  • 可以包含其他块级元素或行内元素。

如下代码示意:

p {
 height: 100px;
 width: 100px;
 background: red;
 color: white;
}

从中我们可以看出设置了元素的宽和高,每个红色方块会独占一行,如下图所示:

inline

  • 按需占用空间
  • 不断行,并排显示
  • width,height,top-bottom margin 等属性不起作用
  • 可以是其他行内元素的父级。

如下段代码所示,我们更改<p>标签display的默认属性,让其成为行内元素:

p {
 height: 100px;
 width: 100px;
 background: red;
 color: white;
 display: inline;
}

从上图所示,我们看出,<p>元素变成了行内元素,我们设置的宽和高并不起效,三个<P>元素排成一行。

Display: Inline-block

某些情况下,行内元素和块级元素并不能满足我们的设计需求,因此有了Inline-block这个属性,从属性的名字,我们就可以分析出其综合了两者的一些特征。

我们可以这样理解,这个属性是个行内属性,可以设置width和height或者我们可以理解成一个块级元素,不用换行。

为了理解这个属性,我们还是从一段代码开始,如下所示:

p {
 display: inline-block;
 height: 100px;
 width: 100px;
 background: red;
 color: white;
}

从上面的效果图,我们可以看出,使用此属性后,我们让行内元素具备了宽高属性。

小节

今天的早读课就到这里,希望通过本篇文章,你明白了display的这些属性。

更多精彩内容,请微信关注“前端达人”公众号!

HTML 中添加 onclick 事件时,可能会遇到事件没有反应的情况。这可能由多种原因引起,如错误的语法、事件绑定方式、作用域问题、元素状态问题、跨域安全性限制、网络连接问题等等。为解决这些问题,需要仔细检查代码、采取适当措施,如使用正确的事件绑定方式、检查作用域、避免跨域安全性限制等。如果仍无法解决问题,可以寻求其他开发者或社区的帮助,并使用调试工具和控制台来进一步分析和解决问题。使用现代的前端框架或库也可以帮助简化事件处理和交互逻辑,提高代码的可维护性和可重用性。

如果您已经确认您的 HTML 代码正确编写,但是 onclick 事件仍然没有任何反应,则可能有以下原因:

1、代码错误:请确保您的 onclick 事件代码正确,没有语法错误或拼写错误。您可以尝试将其替换为简单的 console.log 语句以确保事件绑定成功,并在控制台中查看是否有输出。

2、元素被覆盖:如果其他元素位于您的<span>元素上方,则可能会阻止您的 onclick 事件被触发。您可以尝试使用 z-index 属性将您的<span>元素置于其他元素之上。

3、CSS 问题:如果您的<span>元素被其他 CSS 样式影响,例如 display:none; 或 visibility:hidden;,则它可能不会显示在页面上,并且 onclick 事件将无法被触发。请检查您的 CSS 样式并确保它们不会影响您的<span>元素。

4、JavaScript 框架冲突:如果您的页面中使用了其他 JavaScript 框架或库,它们可能会干扰 onclick 事件的触发。您可以尝试使用纯 JavaScript 或禁用其他框架以解决问题。

5、浏览器兼容性问题:某些浏览器可能不支持某些 JavaScript 特性或事件,这可能会导致 onclick 事件无法被触发。您可以尝试在不同的浏览器中测试您的代码,或者使用 JavaScript 库或框架来处理浏览器兼容性问题。

6、安全性问题:如果您的 onclick 事件代码涉及到用户输入或数据传输,那么请确保您的代码已经进行了必要的安全性检查和过滤,以避免安全漏洞或攻击。

7、异步加载问题:如果您的<span>元素是通过异步加载或动态添加到页面中的,那么 onclick 事件可能无法被正确地绑定。在这种情况下,您需要使用事件委托或者在元素添加到 DOM 后再绑定 onclick 事件。

8、使用了禁用事件的 CSS 属性:某些 CSS 属性可能会禁用元素的默认事件处理行为。例如,使用 pointer-events: none; 将阻止鼠标事件的触发,这也会包括 onclick 事件。因此,您需要确保您的 CSS 样式不会禁用任何事件处理。

9、其他事件监听器或脚本的干扰:如果您的页面中存在其他事件监听器或脚本,它们可能会干扰 onclick 事件的绑定或触发。您可以尝试在页面上禁用其他事件监听器或脚本来诊断问题,或者使用 JavaScript 调试工具来查看代码的执行顺序和事件触发情况。

10、onclick 事件被其他元素覆盖:如果您的<span>元素被其他元素完全或部分覆盖,那么 onclick 事件可能会被覆盖或无法触发。您可以尝试更改元素的位置或层次关系,或者使用 z-index 属性将其置于其他元素之上来解决问题。

11、元素的尺寸或位置问题:如果您的<span>元素的尺寸或位置不正确,那么 onclick 事件可能会无法被正确触发。请确保您的元素在页面上显示正确,并且它们具有足够的大小和可点击区域以便用户能够点击它们。

12、原型链污染:如果您的页面中存在来自第三方库或插件的代码,并且它们可能污染了全局作用域或 JavaScript 原型链,那么 onclick 事件可能会受到影响。在这种情况下,您需要确保您的代码与其他库或插件不会产生冲突,并且您的代码使用了适当的命名空间和封装技术。

13、元素状态问题:如果您的<span>元素处于禁用状态、只读状态或其他状态,那么 onclick 事件可能会被阻止。请确保您的元素的状态正确设置,并且您的事件处理代码能够正确地处理这些状态。

14、跨域安全性限制:如果您的页面中存在来自不同域名或协议的内容,并且它们试图通过 onclick 事件来交互或传递数据,那么可能会受到浏览器的安全限制。在这种情况下,您需要了解并遵守浏览器的安全性限制,并使用跨域通信技术来传递数据。

15、使用了错误的语法或方法:如果您的 onclick 事件处理代码中存在语法错误或错误的方法调用,那么事件可能无法正确触发。请确保您的代码使用正确的语法和方法,以及正确的事件绑定方式。

16、其他 JavaScript 错误:如果您的页面中存在其他 JavaScript 错误,它们可能会影响 onclick 事件的绑定或触发。在这种情况下,您需要检查控制台中是否有其他错误消息,并修复这些错误。

17、网络连接问题:如果您的页面中包含需要从服务器加载的资源,例如脚本文件或图像,那么网络连接问题可能会影响 onclick 事件的绑定或触发。在这种情况下,您需要确保您的网络连接正常,并且您的页面能够正确地加载所有需要的资源。

onclick 事件没有反应可能会由多种原因引起,包括错误的语法、事件绑定方式、作用域问题、元素状态问题、跨域安全性限制、网络连接问题等等。您需要仔细检查您的代码,并采取适当的措施来解决这些问题。如果您无法解决问题,您可以寻求其他开发者或社区的帮助,并使用调试工具和控制台来进一步分析和解决问题。使用现代的前端框架或库可以帮助您简化事件处理和交互逻辑,并提高代码的可维护性和可重用性。

一篇文章我们将来学习安全防范这一块的知识点。总的来说安全是很复杂的一个领域,不可能通过一篇文章就学习完。在这里,我们主要学习常见的一些安全问题及如何防范的内容。在当下,其实安全问题对前端开发已经越来越重要,已经逐渐成为前端开发必备的技能了。

XSS

涉及面试题:什么是 XSS 攻击?如何防范 XSS 攻击?什么是 CSP?

XSS 简单点来说,就是攻击者想尽一切办法将可以执行的代码注入到网页中。

XSS 可以分为多种类型,但是总体上我认为分为两类:持久型和非持久型

持久型也就是攻击的代码被服务端写入进数据库中,这种攻击危害性很大,因为如果网站访问量很大的话,就会导致大量正常访问页面的用户都受到攻击。

举个例子,对于评论功能来说,就得防范持久型 XSS 攻击,因为我可以在评论中输入以下内容

这种情况如果前后端没有做好防御的话,这段评论就会被存储到数据库中,这样每个打开该页面的用户都会被攻击到。

非持久型相比于前者危害就小的多了,一般通过修改 URL 参数的方式加入攻击代码,诱导用户访问链接从而进行攻击。

举个例子,如果页面需要从 URL 中获取某些参数作为内容的话,不经过过滤就会导致攻击代码被执行

<!-- http://www.domain.com?name=<script>alert(1)</script> -->
<div>{{name}}</div> 

但是对于这种攻击方式来说,如果用户使用 Chrome 这类浏览器的话,浏览器就能自动帮助用户防御攻击。但是我们不能因此就不防御此类攻击了,因为我不能确保用户都使用了该类浏览器。

对于 XSS 攻击来说,通常有两种方式可以用来防御。

转义字符

首先,对于用户的输入应该是永远不信任的。最普遍的做法就是转义输入输出的内容,对于引号、尖括号、斜杠进行转义

function escape(str) {
 str=str.replace(/&/g, '&')
 str=str.replace(/</g, '<')
 str=str.replace(/>/g, '>')
 str=str.replace(/"/g, '&quto;')
 str=str.replace(/'/g, ''')
 str=str.replace(/`/g, '`')
 str=str.replace(/\//g, '/')
 return str
}

通过转义可以将攻击代码 <script>alert(1)</script> 变成

// -> <script>alert(1)</script>

escape('<script>alert(1)</script>')

但是对于显示富文本来说,显然不能通过上面的办法来转义所有字符,因为这样会把需要的格式也过滤掉。对于这种情况,通常采用白名单过滤的办法,当然也可以通过黑名单过滤,但是考虑到需要过滤的标签和标签属性实在太多,更加推荐使用白名单的方式。

以上示例使用了 js-xss 来实现,可以看到在输出中保留了 h1 标签且过滤了 script 标签。

CSP

CSP 本质上就是建立白名单,开发者明确告诉浏览器哪些外部资源可以加载和执行。我们只需要配置规则,如何拦截是由浏览器自己实现的。我们可以通过这种方式来尽量减少 XSS 攻击。

通常可以通过两种方式来开启 CSP:

  1. 设置 HTTP Header 中的 Content-Security-Policy
  2. 设置 meta 标签的方式 <meta http-equiv="Content-Security-Policy">

这里以设置 HTTP Header 来举例

  • 只允许加载本站资源
Content-Security-Policy: default-src ‘self’
  • 只允许加载 HTTPS 协议图片
Content-Security-Policy: img-src https://*
  • 允许加载任何来源框架
Content-Security-Policy: child-src 'none'

当然可以设置的属性远不止这些,你可以通过查阅 文档 的方式来学习,这里就不过多赘述其他的属性了。

对于这种方式来说,只要开发者配置了正确的规则,那么即使网站存在漏洞,攻击者也不能执行它的攻击代码,并且 CSP 的兼容性也不错。

CSRF

涉及面试题:什么是 CSRF 攻击?如何防范 CSRF 攻击?

CSRF 中文名为跨站请求伪造。原理就是攻击者构造出一个后端请求地址,诱导用户点击或者通过某些途径自动发起请求。如果用户是在登录状态下的话,后端就以为是用户在操作,从而进行相应的逻辑。

举个例子,假设网站中有一个通过 GET 请求提交用户评论的接口,那么攻击者就可以在钓鱼网站中加入一个图片,图片的地址就是评论接口

<img src="http://www.domain.com/xxx?comment='attack'"/>

那么你是否会想到使用 POST 方式提交请求是不是就没有这个问题了呢?其实并不是,使用这种方式也不是百分百安全的,攻击者同样可以诱导用户进入某个页面,在页面中通过表单提交 POST 请求。

如何防御

防范 CSRF 攻击可以遵循以下几种规则:

  1. Get 请求不对数据进行修改
  2. 不让第三方网站访问到用户 Cookie
  3. 阻止第三方网站请求接口
  4. 请求时附带验证信息,比如验证码或者 Token

SameSite

可以对 Cookie 设置 SameSite 属性。该属性表示 Cookie 不随着跨域请求发送,可以很大程度减少 CSRF 的攻击,但是该属性目前并不是所有浏览器都兼容。

验证 Referer

对于需要防范 CSRF 的请求,我们可以通过验证 Referer 来判断该请求是否为第三方网站发起的。

Token

服务器下发一个随机 Token,每次发起请求时将 Token 携带上,服务器验证 Token 是否有效。

点击劫持

涉及面试题:什么是点击劫持?如何防范点击劫持?

点击劫持是一种视觉欺骗的攻击手段。攻击者将需要攻击的网站通过 iframe 嵌套的方式嵌入自己的网页中,并将 iframe 设置为透明,在页面中透出一个按钮诱导用户点击。

对于这种攻击方式,推荐防御的方法有两种。

X-FRAME-OPTIONS

X-FRAME-OPTIONS 是一个 HTTP 响应头,在现代浏览器有一个很好的支持。这个 HTTP 响应头 就是为了防御用 iframe 嵌套的点击劫持攻击。

该响应头有三个值可选,分别是

  • DENY,表示页面不允许通过 iframe 的方式展示
  • SAMEORIGIN,表示页面可以在相同域名下通过 iframe 的方式展示
  • ALLOW-FROM,表示页面可以在指定来源的 iframe 中展示

JS 防御

对于某些远古浏览器来说,并不能支持上面的这种方式,那我们只有通过 JS 的方式来防御点击劫持了。

<head>
 <style id="click-jack">
 html {
 display: none !important;
 }
 </style>
</head>
<body>
 <script>
 if (self==top) {
 var style=document.getElementById('click-jack')
 document.body.removeChild(style)
 } else {
 top.location=self.location
 }
 </script>
</body>

以上代码的作用就是当通过 iframe 的方式加载页面时,攻击者的网页直接不显示所有内容了。

中间人攻击

涉及面试题:什么是中间人攻击?如何防范中间人攻击?

中间人攻击是攻击方同时与服务端和客户端建立起了连接,并让对方认为连接是安全的,但是实际上整个通信过程都被攻击者控制了。攻击者不仅能获得双方的通信信息,还能修改通信信息。

通常来说不建议使用公共的 Wi-Fi,因为很可能就会发生中间人攻击的情况。如果你在通信的过程中涉及到了某些敏感信息,就完全暴露给攻击方了。

当然防御中间人攻击其实并不难,只需要增加一个安全通道来传输信息。HTTPS 就可以用来防御中间人攻击,但是并不是说使用了 HTTPS 就可以高枕无忧了,因为如果你没有完全关闭 HTTP 访问的话,攻击方可以通过某些方式将 HTTPS 降级为 HTTP 从而实现中间人攻击。

小结

以上就是我们平时开发过程中一些常见的前端安全方面的知识以及我们应该如何防御这些攻击。但是安全的领域相当大,这些内容只是沧海一粟,如果大家对于安全有兴趣的话,可以去网上多进行拓展学习,深入原理。