css关于解决苹果手机底部小黑条适配问题

html-css016

css关于解决苹果手机底部小黑条适配问题,第1张

iPhoneX 取消了物理按键,改成底部小黑条,这一改动导致网页出现了比较尴尬的屏幕适配问题。对于网页而言,顶部(刘海部位)的适配问题浏览器已经做了处理,所以我们只需要关注底部与小黑条的适配问题即可(即常见的吸底导航、返回顶部等各种相对底部 fixed 定位的元素)。以下是处理前后效果图:

安全区域指的是一个可视窗口范围,处于安全区域的内容不受圆角(corners)、齐刘海(sensor housing)、小黑条(Home Indicator)影响,如下图蓝色区域:

更详细说明,参考文档: Human Interface Guidelines - iPhoneX

iOS11 新增特性,苹果公司为了适配 iPhoneX 对现有 viewport meta 标签的一个扩展,用于设置网页在可视窗口的布局方式,可设置三个值:

contain: 可视窗口完全包含网页内容(左图)

cover:网页内容完全覆盖可视窗口(右图)

auto:默认值,跟 contain 表现一致

注意:网页默认不添加扩展的表现是 viewport-fit=contain,需要适配 iPhoneX 必须设置 viewport-fit=cover,这是适配的关键步骤。

更详细说明,参考文档: viewport-fit-descriptor

env() 和 constant()

iOS11 新增特性,Webkit 的一个 CSS 函数,用于设定安全区域与边界的距离,有四个预定义的变量:

safe-area-inset-left:安全区域距离左边边界距离

safe-area-inset-right:安全区域距离右边边界距离

safe-area-inset-top:安全区域距离顶部边界距离

safe-area-inset-bottom:安全区域距离底部边界距离

这里我们只需要关注 safe-area-inset-bottom 这个变量,因为它对应的就是小黑条的高度(横竖屏时值不一样)。

注意:当 viewport-fit=contain 时 env() 是不起作用的,必须要配合 viewport-fit=cover 使用。对于不支持env() 的浏览器,浏览器将会忽略它。

在这之前,笔者使用的是 constant(),后来,官方文档加了这么一段注释(坑):

这就意味着,之前使用的 constant() 在 iOS11.2 之后就不能使用的,但我们还是需要做向后兼容,像这样:

注意:env() 跟 constant() 需要同时存在,而且顺序不能换。

更详细说明,参考文档: Designing Websites for iPhone X

了解了以上所说的几个知识点,接下来我们适配的思路就很清晰了。

新增 viweport-fit 属性,使得页面内容完全覆盖整个窗口:

前面也有提到过,只有设置了 viewport-fit=cover,才能使用 env()。

这一步根据实际页面场景选择,如果不设置这个值,可能存在小黑条遮挡页面最底部内容的情况。

类型一:fixed 完全吸底元素(bottom = 0),比如下图这两种情况:

可以通过加内边距 padding 扩展高度:

或者通过计算函数 calc 覆盖原来高度:

注意,这个方案需要吸底条必须是有背景色的,因为扩展的部分背景是跟随外容器的,否则出现镂空情况。

还有一种方案就是,可以通过新增一个新的元素(空的颜色块,主要用于小黑条高度的占位),然后吸底元素可以不改变高度只需要调整位置,像这样:

空的颜色块:

像这种只是位置需要对应向上调整,可以仅通过外边距 margin 来处理:

或者,你也可以通过计算函数 calc 覆盖原来 bottom 值:

写到这里,我们常见的两种类型的 fixed 元素适配方案已经了解了吧。如果我们只希望 iPhoneX 才需要新增适配样式,我们可以配合 @supports 来隔离兼容样式,当然这个处理对页面展示实际不会有任何影响:

注:文章出处: https://aotu.io/notes/2017/11/27/iphonex/ (本人仅参考收藏)

随着前端技术的发展,安全问题已经从服务器悄然来到了每一个用户的的面前,盗取用户数据, 制造恶意的可以自我复制的蠕虫代码,让病毒在用户间传播,使服务器当掉. 更有甚者可能会在用户不知觉得情况下,让用户成为攻击者,这绝对不是骇人听闻。富客户端的应用越来越广,前端的安全问题也随之增多,今天就简单介绍下一些常见的攻击方式和预防攻击办法。

常见攻击

XSS (Cross Site Script) ,跨站脚本攻击。它指的是恶意攻击者往Web页面里插入恶意html代码,当用户浏览该页之时,嵌入的恶意html代码会被执行,从而达到恶意用户的特殊目的。XSS属于被动式的攻击,因为其被动且不好利用,所以许多人常呼略其危害性。但是随着前端技术的不断进步富客户端的应用越来越多,这方面的问题越来越受关注。举个简单例子 : 假如你现在是sns站点上一个用户,发布信息的功能存在漏洞可以执行js 你在 此刻输入一个 恶意脚本,那么当前所有看到你新信息的人的浏览器都会执行这个脚本弹出提示框 (很爽吧 弹出广告 :)),如果你做一些更为激进行为呢 后果难以想象。

CSRF(Cross Site Request Forgery),跨站点伪造请求。顾名思义就是 通过伪造连接请求在用户不知情的情况下,让用户以自己的身份来完成攻击者需要达到的一些目的。csrf 的攻击不同于xss csrf 需要被攻击者的主动行为触发。这样听来似乎是有“被钓鱼”的嫌疑哈哈。

多窗口浏览器这这方面似乎是有助纣为虐的嫌疑,因为打开的新窗口是具有当前所有会话的,如果是单浏览器窗口类似ie6 就不会存在这样的问题,因为每个窗口都是一个独立的进程。举个简单例子 : 你正在玩白社会, 看到有人发了一个连接,你点击过去,然后这个连接里面伪造了一个送礼物的表单,这仅仅是一个简单的例子,问题可见一般。

cookie劫持,通过获取页面的权限,在页面中写一个简单的到恶意站点的请求,并携带用户的cookie 获取cookie后通过cookie 就可以直以被盗用户的身份登录站点。这就是cookie 劫持。举个简单例子: 某人写了一篇很有意思的日志,然后分享给大家,很多人都点击查看并且分享了该日志,一切似乎都很正常,然而写日志的人却另有用心,在日志中偷偷隐藏了一个对站外的请求,那么所有看过这片日志的人都会在不知情的情况下把自己的cookie 发送给了 某人,那么他可以通过任意一个人的cookie 来登录这个人的账户。

我们该怎么做?

大致可以分为两类 1 一般用户 2网站开发人员。

首先我们来说说做为一个一般的web产品使用者,很多时候我们是被动的,是在不知情的情况下被利用的。那么我们可以:

1 对于安全级别较高的web应用访问 需要打开一个独立浏览器窗口。

2 对于陌生人发布的链接最好也是复制然后在新开的窗口中打开,当然最好的办法就是无视 – -。

对于开发人员来说我们得从相对详细的一些角度来分析:

对于xss 攻击 特点是攻击者的代码必须能获取用户浏览器端的执行权限,那么代码是从哪里来的呢,想要杜绝此类攻击出现 其实可以在入口 和出口 进行严格的过滤,这样的双保险应当说99% 的类似问题就被我们解决掉了,另外的1% 是那些蹩脚的浏览器带来的后遗症,相信在未来这种问题会越来越少的。

这里我对xss漏洞的形式作了一些整理

恶意代码值被作为某一标签的内容显示 (如果输入的是html 则html会被解析)例如你输入用户名 更新后用户名会显示到页面中的某一个标签内 如果你输入的是

popper.w<script src="hack.js" type="text/javajscript"></script>

那么如果不做过滤直接显示到页面, 会引进一个第三方的js 代码并且会执行。

策略:在不需要html输入的地方对html 标签 及一些特殊字符( ” < > &等等 )做过滤,将其转化为不被浏览器解释执行的字符

恶意代码被作为某一标签的属性显示(通过用 “ 将属性截断来开辟新的属性 或恶意方法) 这种情况往往是是开发人员为了实现功能可能会在某些dom标签上记录一些用户输入的信息例如你输入的用户名 会在页面中的标签中以 title 的形式出现 这时候 如果 你输入的是精心设计的内容 那么 看看 这个

<a title="popper.w" onclick="alert(1)">popper.w" onclick="alert(1)</a>

这里我实际上输入的内容是“popper.w” onclick=”alert(1)”,当然你可以在上边写更多的内容。

策略:对属性中可能存在截断的一些字符进行过滤 属性本身存在的 单引号和双引号都需要进行转码。

恶意代码被作为html代码本身显示 (常见的html编辑器) 这种情况存在的问题最多,不再这里举例子了。

策略:最好对用户输入的html 标签及标签属性做白名单过滤,也可以对一些存在漏洞的标签和属性进行专门过滤。

恶意代码被作为一段json字符串显示 (通过 变量截断 创造新的 恶意的js 变量 甚至是可执行的代码) 这个问题的关键是用户输入的信息可能会成为页面中js 代码的一部分。

策略:对属性中可能存在截断的一些字符进行过滤 属性本身存在的 单引号和双引号都需要进行转码。

对于crsf 和cookie 劫持

特点 隐蔽性比较高 有些时候是先利用xss 漏洞 然后再做 欺骗的

策略

通过 referer、token 或者 验证码 来检测用户提交。

尽量不要在页面的链接中暴漏任何与用户唯一号(用户id)有关的信息。

对于用户修改 删除 提交的操作最好都使用post 操作 。

避免全站通用的cookie 严格的设置cookie的域。

ok 就写到这里~

上边讲的都是一些比较常见的安全问题,主要是从js hack 方面来讲的,随着前端技术的不断发展进步,更多的安全问题可能会展现在我们面,对于开发者来说大多数的问题是可以在开发阶段避免的,所以可怕的不是hack 可怕的是我们对自己的产品安全的松懈

1、首先在电脑中打开一个需要获取CSS数据的网页。

2、在网页的空白处点击鼠标右键,选择“审查元素”的选项。

3、点击后在页面的下方会打开一个网页元素代码窗口。

4、在该窗口的右侧小窗口可以点击“style”,其中就是需要的CSS代码了。