Web UI 设计中交互与外观样式的取舍

  标题所指的“交互”与“外观样式”并非取舍关系,而是在这里将阐述两者各自的问题。这篇文章并不阐述技术细节,而是探讨应当如。

  并且本文没图片也没太多例子,有些文字描述的比较模糊和不仔细,嘛,就大概的交代下一些东西,能看到多少是多少。好的开始。

  如果你已经写过一段时间的 HTML 和 CSS 了,那么你应该接触过不少的特效和外部库了吧?

  我们先探讨“外观样式”方面的。

  样式的设计应当遵从一种事先整理好的概念模型,我们发现很多开源的样式库,或者一些大型企业(指国外)都遵宗这一道理(交互方面也是如此)。

  如果你确定了网页的整体颜色,接着你会确定一个或几个与其搭配的颜色,例如按钮,接着我们遇到的问题是,按钮需要几种色彩,多少种设计?例如:灰色、黑色、蓝色、红色、黄色、绿色,接着定义了两种外观:填充背景色的 和 缕空背景色(有线条轮廓)。

  接着我们遇到了一些类似按钮或就是按钮的东西,如果你没有系统的规划,你可能为它再单独的写一个样式。

  对此,我的建议是,如果 黑色 的按钮没有存在的必要(使用不到那么多颜色)那么可以取消它,而如果你只打算控制少数色彩,既按钮只需要留下 灰色、蓝色、绿色 这样三个即可,它们通常可以应付大多数情况。而外观,如果可以省掉 缕空背景色 的按钮设计,那么就取消它(缕空型的用于 tab 性质的按钮,通常两个连一起)。

  设计中的页面元素数量和我们经常看到的“你能控制3种颜色就足够了”是相同的道理,过多的色彩如果无法控制,页面会显得凌乱,而设计元素也是相同,当你设计了五彩缤纷,而或是有各种造型的按钮,它们同色彩一样,是一种很难控制的事情,又或者说,能少既少。除非,你能确信它的存在是非常必要的,这个按钮必须不同于之前的。

  对于其它模块也是如此。甚至对于一个按钮的细节。

  如果你还未系统的整理过 CSS 的规划方式,我的建议是去看看不同的样式库,它们往往都有规划(它们必须规划),它们会告诉你一个网站通常有哪些元素模块,接着你得学习如何将这些模块最有效的写出来,复用性,可以用在各种情况,并很好的将它们以代码的形式规划部署在你的代码文件里。

  接着我们再将“交互”中的取舍。

  我经常看到一些网站特效非常的多,的确 CSS3 和 JavaScript 为我们提供了非常多的动画和过滤效果。

  但你要比样式更注重一个问题:阅读成本。以及其中的 视觉中断 问题。

  任何一个交互过程,都会导致用户大脑的暂停,让他来响应你的交互效果。甚至你可以理解成,当鼠标经过一个超链接,如果只是改变背景色,那么用户的大脑接收到了这一改变,它只有一个信息:鼠标经过时该链接变成了某颜色。而如果你加了 0.2s 的缓冲,并且做了 :before 或直接的下划线。那么用户大脑所要处理的事情就不只是颜色了。虽然这个消耗成本或许并不大。但是你的确多给了用户很多信息,不是么?

  当一个交互涉及的内容比较大,那么会带来的结果是,用户的注意力被分散,暂停,又或者说被这个效果所吸引导致暂停。例如我们在一个 table 列中,让用户鼠标经过某行时,这行的背景色发生变化,当你做这件事时,并不应该把它当成一种效果,而是一种目的,目的在于让用户把这个变化作为视觉焦点,让用户更容易,或有意的让它锁定在这行。

  你会经常看见有一些导航菜单的设计,那么我来描述一个非常复杂的:页面载入时,导航以一种特效形式出现,接着当鼠标经过菜单中的某个时,该项会有一个比改变背景色更复杂的过滤效果,接着以一个特效列出了它的二级菜单,接着鼠标指针在不同的二级菜单列种游荡,每次经过菜单都会有一个 CSS 过滤效果,并且给它加了动画和装饰,而且每个项都有字体图标,再用户点击它的时候再来一个变化……

  非常高端,但是,有什么用呢?实际上如果你以用户的视角去体验,这些特效反而会使你觉得这设计真差!

  我们需要的是一个方便我们寻找和切换类目的菜单,这才是它的目的,如果没有缓冲的改变背景色太过直接,那么我们可以加上 0.x 秒的缓冲使过程显得柔和。安卓当前的设计即是如此,一切都非常简单,会有简单的过滤效果,最后在用户点击的时候背景色产生一个动画的原形扩散,它们本身都保持了样式外观上的简洁性。

  不必要的东西都可以不存在,每一项设计都存在着一个目的,以及用户的阅读成本,它都会带来一个利好,但都有其对应的消耗与相反的弊端。

  交互中的特效应当作为一种点缀,整个网站都不需要存在过多这种设计。

  网站的根本目的是在于用最好的方式展示出用户希望获得内容信息,以及我们有时希望用户聚焦的信息。

  如同我们用纯图标代替一个文字按钮,它除了美观,也是为了让用户可以更快速的了解这个按钮是做什么的。

  对于过程性的交互,简化它,很多时候,我们向用户表明的内容无非只有:账户菜单,内容分类,和正文。

  最后,一个鼠标经过缓冲效果应当最好是在 0.1 ~ 0.3 秒 最多 0.5 秒,交互中的展示和收纳也是如此 不要超过 0.5 秒,并且你应该将所有动画的缓冲时间规定在固定的几种,例如我的动画大部分都是两种:0.3 和有时候如果 0.1 太短 0.3 太长 会偶尔的有一个 0.15 0.2 0.25 之类的……

Web 设计中关于 DPI 的一些事情

  我经非常提及设计的一些细节问题,今天要讨论的是关于 DPI 这个细节,也许你已经注意到了一些问题。

  iOS 设备,从 iPhone 到 iPod,的分辨率放大方式,从初代的 1:1 到后来的 2:1 接着 iPhone6P 的 3:1,我们观察到它都是成倍数的放大,一个整数。

  而市场上很多的安卓设备却并非如此,它们的放大方式早期存在很多的 1.5:1,直至今日,我想你能找到 2.5:1 的设备。

  这件事的结果在于,当我们在代码中绘制 1px 抵达 2:1 设备实际绘制的是 2px 实际分辨率,而在 1.5:1 的屏幕上则绘制的是 1.5px,这也就造成了内容渲染结果的模糊。

  如果你使用过这些安卓设备,尤其是在 Web 上这个问题尤为突出,因为任何像素单位设计之初都是以整数绝对像素来定义的,即便是 rem 换算成像素点也是如此,而系统或浏览器无法处理好这种结果。

  它在 App 的设计也有表现,安卓 QQ 的一些版本有一些缕空的按钮(背景色透明有边框线条),这时线条所描绘的就是一个 1.5 像素,你会感觉到它显示的有些模糊,或者说有些问题。

  而系统 UI 自身则很少有这种问题,安卓自身在设计的时候考虑到这个情况就可以将原本的 1px 在 1.5:1 的设备上处理成 1px 或者 2px 而不取 1.5px。这体现在某些应用程序上也同样适用,或者拿字体和图标举例,如果字体并非对 1.5 放大倍率做过调整,或者图片形式的图标没有对这个中间值进行过特别优化,那么它的显示结果就不如倍数放大的设备。

  对于厂商来说需要注意这个问题,当然,对于一些设备而言可能硬件上有难题无法处理,如果取 1:1 内容显示的太小,而 2:1 则太大(显示范围非常小),但无论如何,这样做都是不好的。

  iOS 设备的精湛之处或许并不在于屏幕的色彩和 DPI 有多高,它一开始就知道放大倍率带来的结果,这个结果的影响力大于你的屏幕参数具体有多高,即便再出彩的屏幕,如果存在着非倍数放大的 DPI 设定,那将是毁灭性的,任何形式的 UI 与 文本 都会受此影响,结果是相当糟糕的。

在设计中会带来的一些 BUG:

  第一个是上面提到的像素模糊问题;

  第二个是因为 1.5 这种值的存在,相邻色彩块中间可能出现 0.5px 的断裂,当两个纯色模块靠在一起,本身是没有间距的,然而在这种设备下中间会有 0.5px 错位出来的显示结果,如同早期 IE 中经常遇到的 1px 莫名其妙的溢出。解决方法是将块元素 margin 减去 1px 加上其它代码调整成一个在两种 DPI 下都能正常显示的结果。选一些重点的调整即可。

  第三个问题是模糊,这可能跟浏览器有关,但目前普遍使用的 WebKit 一直存在这个问题,如果某个元素存在着透明度或不固定形式,那么在某种情况下会导致该块区域显示结果模糊。解决方法是针对它取消透明度,或者更多的调试也许可以获得一个既保持透明度又没问题的结果(例如文本区透明度,那么我们不让它透明,而改变文字本身的颜色灰度好了)。

  强调一下,除了 Web 在 App 设计中这个问题也存在,而在 Web 中问题更突出,并有第二和第三个或更多问题。

  如果你更改了安卓的 DPI 让它以 2:1 整数倍数放大,你会发现你的设备显示结果清晰无比……

在移动端用 Touch 事件以拖拽手指实现伪 hover

2015-11-02

然后有一个非常简单的方式实现

在需要的元素或者整个 body & html 根上绑定 touchstart 事件。放弃以下的蹩脚方法!

—-

前言:

  我们知道触屏设备,移动端浏览器它没有 hover 的动作效果,其次我们知道 iOS 的 Safari 与 Chrome 是不会对 hover 做出反馈的(它会在手指点击的时候瞬间执行一次 hover 效果,但随即便进入 a 标签的超链接,而假设不为 a 标签则就完全不会显示 CSS 中设定的 hover 效果),而 Android 系统下则会将触摸判断为 hover 并显示,但是它有一个严重的问题,即是 hover 状态会一直停留不取消,当我们不停的挪动手指触摸到不同位置将会看到一个非常糟糕的体验。(iOS 下的 Opera 和 搜狗 等浏览器的默认设定与 Safari 和 Chrome 不同,它的默认设定和 Android 相同)。

  以上便是这篇文章所要解决的问题,我们需要一个 hover 效果,与此同时不同的移动端浏览器或不同系统下的,使它们达到相同的交互显示效果。

正文:

  我们要实现一个怎样的 hover 效果?

  在这里的显示效果是这样的,这里的陈述将根据 iOS Safari 为基础:当我们的手指触摸到某个需要 hover 的元素,它将展示 hover 的效果(通常情况下如果触摸为点击而非拖拽挪动手指,则会直接触发 a 标签的超链接,而当我们点触的同时并挪动手指,则 a 标记的超链接则不会触发),那么我们要利用的便是这种状况,利用挪动,或者非 a 标签直接实现 hover。接着当手指松开的时候 hover 效果取消。


【触摸模块时 hover】

IMG_0636
【松开手指时 取消 hover】

  注意上面这个结果,无论在 iOS 或是 Android 它们的效果是相同的,同时“稍后观看”按是 :hover 而非我们制造的 .hover 所以 它会停留住,即便你松开了手指(因为在这里我们需要这个按钮在 hover 之后可点击),图中第1个和第3个模块是没有任何操作情况下的常态。这样就达到了一个复杂的效果。

  我们知道 js 无法直接操作 css 中的 :hover 写法,那么显然,没错,我们要自动的为触摸到的元素添加 class 使用 .hover 来塑造一个 :hover 效果。而以下我们将介绍两种情况下做这件事的方案。

  首先第一种情况,是一个完整的全新的设计时可以用的:

  此时发生的事情和 CSS 需要相应做的事是:body 中的任意标签 在 hover 与 拖拽时均会给该元素添加一个 .hover class,所以我们的 CSS 当中,将用 .hover 完全的取代 :hover(:active :focus 等保持原本写法),如此一来无论桌面系统的鼠标 hover 还是触摸时 hover 的表现结果是相同的这点不用担心。上面的代码我们分别定义了 touch 事件的 触摸 拖拽 为 添加 class,而结束时 删掉这个 class。

  第二种情况是你的项目已经开发到了比较完善的程度,此时无法完全的使用 .hover 取代 :hover(其实改改应该也不难),又或者你只希望这种动作只发生在某些特别的位置:

  以上的代码将 body * 选择器写成了 class(这是你需要指定的位置),当然的你可以指定多个 class,不同之处在于,因为你的 CSS 本身已经设定了 :hover 代码,这个时候当你将 :hover 需要效果的部分同时增加上 .hover 会造成两种同时存在的结果。所以我们需要每一个动作都有一个反向的 .no_hover,同时你需要对 .no_hover 添加上反向的 CSS 代码(即未触发 hover 时的样式 还原回效果)。

  我推荐第一种方法,但它的开销可能大一些,每次 hover 都会对 dom 进行操作,因为第二种方法需要写的 CSS 内容会多很多,但如果只是很局部的使用则第二种比较好。推荐第一种的原因在于,如果浏览器的默认设定得到了改善,到时候你只需要批量的将 CSS 中的 .hover 字样替换成 :hover 一切就会恢复成通常的方式了。

  这是非常值得尝试的一种效果,它让 Web 在触屏设备上拥有了如同 APP 一样的交互效果,不要小看它,虽然代码并不复杂,要知道越是基础的东西,越是看似简单的东西,越为重要,比起复杂炫酷的特效,我们在屏幕上操作最多的这种基本动作反而更影响体验,着显细节。

末尾:

  你恐怕要着一段代码阻止移动设备长按浏览器而弹出的菜单,这是必须的,iOS 下的代码很简单,只有一段 CSS 就可以做到,而 Android 要麻烦一些(我暂时没有找到方法 过往的 js 似乎对 Android 5.x 的 Chrome 就不起效)。如果你有对安卓的方法,请多指教。

-webkit-overflow-scrolling: touch; 隐藏滚动条

如果你不知道 -webkit-overflow-scrolling: touch; 是什么意思,它是用在移动端 webkit 内核浏览器的一个滚动条效果,通常我们的页面滚动(body 会默认采用这种方案无需代码声明)当手指触摸滑动时,它是不会以一种惯性,带回弹效果的滚动,而这段代码即是让它拥有这种像 App 一样的效果(很显然它是非常有必要的,完全可以全局的变成默认行为),历史就不写了。

在我使用这段代码的时候它随即带来了一个问题,-webkit-overflow-scrolling: touch; 所带来的滚动条在未滚动的时候是隐藏状态,而当手指尝试去滑动滚动条就会显示出来,然而这个控件的样式并非像桌面浏览器可以自定义,也就是说无法隐藏。我尝试在互联网上搜索中英文解决方案,但是都没有结果。最后通过 Google 的手机版找到了这个方案。

首先我们假设这样一个结构:

或者你可能用的是 div 而不是 nav,这里并没有关系。首先 li 层也没有关系。

那么你设计的滚动部分可能在 ul,假设你的 ul 设定高度为 40px,并且隐藏了纵向(Y)滚动条,且允许横向(X)滚动;至此 nav 可能并没有做什么设定,又或者你也对它设定了一些参数。

隐藏这个 ul 所产生的横向滚动条的方法是:将 ul 的高度提升为 51px(增加 11px 左右),而后锁定 nav 的高度为 40px,并且对 nav 也做 x y 轴的滚动条隐藏(让超出的 11px 不会产生纵向滚动,而滚动条则位于 overflow-y: hidden; 所遮挡的部分,这样就达到看不见的目的了)。

对于自动变化高度的横向滚动条暂时好像这个方案并不能解决,不过一般都是固定高度吧?

我发布这篇文章的时候 谷歌的搜索主页(搜索结果菜单)是以这种方式解决这个问题的,你可以更改浏览器 UA 尝试看下它的源码。

其实这是一个很初级的 CSS 使用思维,但是我零零散散花了很长时间去解决这个问题,起初的思路是寻找有没有哪句代码可以直接隐藏掉它,随后我打算用 js 去做这件事代替 -webkit-overflow-scrolling: touch; 但是想想这挺蠢的。末尾无意间闪过 Google 的工具条……

另外一个小地方,如果你把 -webkit-overflow-scrolling: touch; 定义在了 body 可能出现标签页白屏的问题,所以你应该这样做:

不要定义在 body(body 和 html 会自动带有这种效果),而定义在,你的滚动条多半只可能出现在的几种类型,例如 nav div 和 ul。

目前为止 iOS 8.4 中的 Safari 不会白屏,但其它浏览器如果定义在 body 均会白掉。

HTML5 标准结构 结构化标签 基础

很多时候我们可能会将内容 页头 与 页脚 中间的内容区包裹在一个 div 当中,这样上中下内容相对分明一些,div 也会有其它用途,加上 id 或者 class 描述。

网站标题是否需要带有网站名称?网站标题分隔符 2015

网站标题是否需要带有网站名称?网站标题分隔符 2015 年对此的看法。

在过去我们经常这样做:我的页面 – 我的网站

现在我们依旧需要搜索结果中带有 – 我的网站

So!

但是,你在谷歌的搜索结果会看到:我的页面- 我的网站

注意少了一个空格,于是我去寻找这个问题是怎么来的。

你会发现那些空格正常的网站很多都是不带 – 我的网站,而搜索结果中的是 Google 加上去的。

你并不需要在页面之后跟着画一个 – 我的网站,Google 会给你写上。

你可以参考以下结果:Goolge site:meiri.tv

在几年前其实貌似就这样了 ← ←,一直没注意,OpenCart 很早就不带网站名称标记,对于页面只有页面的 Title 信息。

当然对于访问时的习惯可能喜欢看到跟着一个后缀,但是这在移动端看上去其实并不友好,标题老长。

如果用户需要你的主网站名信息,那么它收藏的应该是你的主页,而如果收藏的是页面,网站名称标记也不是必要的。

于是我就都去掉了。

对于分隔符,空格-空格 的形式经常会在搜索结果中漏掉空格,和网站名称标记一样,呃,所以就跟着百度的风格推荐使用 _ 吧?

是否需要写多种浏览器兼容CSS

我会说:不需要!

当然,你需要判断一些问题。

我在 13年 14年早期的时候还会在 CSS 中写入各种兼容代码,一个默认值,一个 -webkit-,一个 -moz-,一个 -o-,甚至会有 -ms-(说的好像 IE 是外人一样)。

到 15年,我重新需要使用过去自己写过的代码,我拿了一些 13年 和 12年底的代码,这个时候我发现这件事是多么的没有必要。

在不久之后火狐会直接支持默认形式,而-o-(欧鹏)已经直接换成了 webkit 内核,IE 的更新迭代在 IE9 已经支持基础常用的 CSS3,因为这个家伙有些特殊性呃,我们还现在说总体代码的区分,对于 IE 的特殊错位当然是得做兼容的,但并不是 -ms-,这点可以参考 针对 IE 的 CSS 写法,只对 IE 生效的 CSS写法

跑题了。

之后我去修正了这个问题,只留下默认形式,其余的兼容前缀都去除。

仅仅是过了一年多,两年,就完全没有意义了这些兼容代码。

你需要判断,Chrome 会率先去除 -webkit- 前缀,它一定会支持默认形式,除了它专用的部分(即 CSS3 标准里并没有的),其它浏览器也会很快的跟进。除了 IE 这个特殊存在,没有自动升级,也跟系统版本挂钩。

尽量少的使用各种特殊前缀,除非你知道这段代码只有这个浏览器会运行,在将来几年也是如此。

现在我的代码基本只有两个例外:一些很少的 -webkit- 特殊效果或动画,以及从 IE9 开始 用 \0 \0\9 解决少数像素偏移问题。

你没有必要还考虑一年前的 Chrome 火狐 欧鹏 它们很快就会消失。你需要考虑将来一年,两年,用户是否还需要这些多余的代码?未来这些浏览器是否还会不支持这些代码?

针对 IE 的 CSS 写法,只对 IE 生效的 CSS写法

呃,webkit 现在基本覆盖了大范围,所以我们就只还是 IE 的问题,这个方法也是从网上其它地方搜索到的,当时自己遇到了 IE 的问题。那么,还未发布的微软斯巴达浏览器不知道又是个什么鬼,现在就到 IE11 为止的兼容性吧。

因为 IE 经常就会有些问题偏移,或浮动的处理方式不同而导致错误。

\0
\0\9

这样写:

这个写法从 IE9 到 IE11 为止都是没问题的,IE8 忘了这个就不测试了。

针对 IE 的 CSS 写法,只对 IE 生效的 CSS写法,只有 IE 认识的 CSS 写法。

Web 网页设计 0.5 像素的应用 手机网页1px变粗为2px问题

过去一段时间开始在意这个问题,但一直没去实践尝试,目前为止我还没有留意到有注意并实施操作过这个问题的网站。

这是个值得重视的细节,它可以让你的 Web 页面真正像应用程序 UI 那样细腻。

(文中涉及的“网页”、“设备”、“浏览器”之类词汇均指 手机 与 Pad 类设备上的。)

我们设计的网页似乎总是粗一些,我是说,线条,它使整个页面看上去不够细腻。我们的浏览器地址栏的边框为 1px 1像素,但是我们的网页搜索框看上去却并不是 1px,当然,我们的代码中写的是 1px。

那么问题来了:请问挖掘机技术哪家强?

(对比图位于文章末尾)

我们看到的情况是这样的,这是一张 iOS 下的截图,当我们拿到电脑上去量的时候可以得出,原本在电脑浏览器上设定的 1px 则变成了 2px。

原因是手机类设备现在的发展速度快过 PC,以至于新出厂的笔记本或显示器都还停留在 1366×768 和 1440×900,而移动设备开挂了似的进化。

为了使小屏幕高分辨率下能看清楚屏幕中的元素,从 iPhone 开始 dpi 以及 2x 3x 这些概念和 响应式 Web设计的出现。


好的,熟悉 CSS 的人应该不用看也明白上面这些了,或者你也猜到解决方法了,那么问题来了那么进入正题:

解决粗细问题的方案便是:

将 1px 在手机和Pad(以下均简称手机)模式下写做 0.5px,因为是 x2 的放大,实际就会成为 1px。

例如:border: 1px solid #ccc;

我们在正常模式下的书写得区分它们,将 1px solid 与 颜色 拆分开:border: 1px solid; border-color: #ccc;

原因是在手机模式下你要更改的是 1px 这个数值,如果它们写在一起会导致 #ccc 失效(你需要重新去定义各个色彩)。

手机模式则写作,只影响线条粗细像素:border: 0.5px solid;

强制定义所需元素的边框宽度即可,之前写复杂了:

这样所有带 border 边的元素都会变成 0.5px 边,也不需要考虑颜色问题(是否使用 * 这个看习惯吧,* 代表所有元素,如果你的页面存在非 1px,例如 2px 10px 不需要缩小的,会导致一并变成 0.5 否则请指定需要的元素)。

0.5px 在 1x 桌面浏览器 是不会显示为 1px 的,为 0,所以还是得单独定义到移动模式去(我们无法保证所有访问者的移动设备都达到了 2倍 放大)。我们定义设备的 dpi 放大倍数至少为 2倍 才执行 0.5半像素:

会带来的问题:

dashed 虚线 目前的 webkit 内核浏览器是无法 0.5px 的;

input botton textarea 等类似的元素因为边框粗细的更改,肯能会导致手机模式下的 1像素 偏移,这个时候需要再定义手机模式下的高度以解决这个问题。以及它带来的连锁反应(手机模式下的 1px 的问题)。但总的来说纠正并不麻烦,涉及代码也不多。

未知的问题:

半年前就有什么4k手机了,我不知道它的放大倍数,那么假设它是4倍(偶数),我们的页面也依旧能正常显示,但也存在奇数倍的 dpi 倍数设定,以 iPhone 6 为例子 它和过去的 iPhone 设备一样是 2x 放大,但是 iPhone 6 Plus 则是 3x 放大,按照换算原来的 1px=0.5px,这个时候应该=0.333333333px,这怎么算?

(理论上应该是就当作 0.5 并以这个倍数去换算,并得出统一的粗细像素以显示,它会比1px细一些,并会比 iPhone 6 Plus 下的本身 UI 中的 1px 粗一些。)

因为没有高于 2x 的设备,我是不知道显示结果了。。。

你在使用 0.5px 的时候需要考虑一下这个问题,最好有设备可以实际运行下,除此之外,你还得考虑低端设备的显示结果(当然,它们会逐渐升级的)。

如果你能提供给我一张 iPhone 6 Plus 3x 下的截图或更高放大倍数的设备截图,非常感谢。

最后我们对比结果的差异(iPod 5 2x 显示环境):

使用 1px 显示结果

使用 0.5px 显示结果

关于 @media print { } 的一些建议,及 invert 做夜间模式

是作为类似 响应式 自适应 功能的代码,处理的是当浏览器执行打印命令的时候所要执行的代码(你可以在它里面再嵌套 自适应 代码 还能根据纸张尺寸打印出不同布局 ( ╯□╰)。

一般情况下我会用它去除网站的广告,一些无用元素,以配合打印的模板需求(在打印的时候隐藏)。

So,但打印会有一个问题是对于阴影的,这是以全局去除打印时候网站内的阴影元素:

代码比较简单,不过这是一个值得注意的细节。

对于参差不齐的打印机打印质量,并且打印结果也往往不是完全等于浏览效果。

似乎应该不会有什么网站会去设定打印……

@media print { }

还被用于防盗,一般我们的防盗措施是 js 禁止键鼠动作,以及另存为(这个貌似老了,不过另存为并没问题,要取出文本很麻烦),但是按 Ctrl+P 打印的话,就可以直接复制内容了。当然,浏览器也可以快捷关闭 js 的运行,比如 Chrome 的地址栏前面的书页图标。

那么防止打印键复制内容:

就是打印的时候隐藏掉内容。写了3个标签,* 号代表全部元素,html 和 body 则是因为在 html5 可以省略掉了,当然,网站有这些标签的话用 html 就好了。(用 body 的话,例如我的背景图一般都设定在 html,就…)

包含阴影元素:

去除阴影元素:


题外:夜间模式。

除了打印上可能需要去除阴影,这是一个严重的问题,当颜色反转后阴影变成白色即破坏了整个页面效果。

它可以作为另外一个用途是,我们用 invert 底片,反色方式将网站变成夜间模式的时候灰黑色的阴影会变成灰白色,这个反向是个问题。用它去除即可。(对于图片也一起)

用 invert 制造夜间模式会存在另一个问题,既是 图片 广告 视频 之类的元素也会反转成底片颜色。这个时候我们再去顶一次它(用相同的代码)即可再一次 invert 将这些元素色彩返回来。

例如这里我们对整个 html 标签进行 invert 而后,再对 img 以及一些嵌套和媒体做二次反转。(这里多放了个对比度)

不过可惜的是 滤镜 如果全局使用,无论在现在的 iOS 任何浏览器,或 安卓 的浏览器下均会:页面整个模糊掉(桌面系统浏览器没有这个 Bug)。导致这个最简单方案无法用 ←_← 于是还是得用复杂的工程,手动制造所有元素颜色。

另外是 IE 之类的兼容啦。