让你的PC端网页也能任意缩放吧~

·  阅读 2480
让你的PC端网页也能任意缩放吧~

(小埋大小变镇楼)

关于移动端的网页适配方案,可以用媒体查询,em,rem,vw/vh,viewport等技术处理,这些大家只要接触过移动端网页开发,多多少少都会了解的。不过今天要聊的主题并不是移动端,而是pc端适配。

作为大屏幕网页场景,pc端的屏幕尺寸差距远比移动端要复杂,先是屏幕宽度差距,跨度可以在一千多像素(竖屏)到两千多像素,可以是大屏台式,也可以是笔记本/平板;不像移动端相对固定,窗口能最大化,或者任意宽度调整...

当你遇到需要对pc端网页进行缩放操作的时候,多半会比较头疼。要么告诉产品运营,这个做不了,不支持  ┑( ̄Д  ̄)┍;要么只能死些脑细胞,看看怎么实现。

那么来啦,惯例思维,先来捋一下思路

先说明,IE8不要出来,我不想见到它,也不打算兼容它~

网页适配,其实就是按屏幕大小调整页面元素/文字的大小,尽可能完整的展示内容。

那么,无论是pc还是移动端,思路都是一样的,可以用媒体查询渐进式调整,可以用font-size等css单位控制大下,还能用整体缩放实现,以下依次梳理。

先来看看一号选手【媒体查询】的表现。

关于它是啥我就不解析了,通过媒体查询实现pc适配的经典代表就是Bootstrap的栅格系统,当年这真是一把锋利无比的杀猪刀,从后台到网站,到处都是它的身影,时至今日,我们很多人仍受惠于它。

虽然思想很好,但奈何现实不太美丽。

首先它的存在就会影响美术放飞自我。强行要求一个美术理解为什么要把页面分成等宽格子,板块需要按格子调整,本身就是不大现实的事情。部分美术甚至连同一组按钮的尺寸间距都没能做到统一,更别提要求他们按不同屏幕尺寸标准做出数套设计图。

此方案很难顺利达成,现在基本都是后台在用,其他地方也有少量用到【媒体查询】做调整。

接着是二号选手【font-size】。

这里就不说vw/vh这些了,我知道按照屏幕宽度变化尺寸很美,现实是移动端都未必能兼容,pc端真可以直接打死了。着重说rem吧,这个比较好用~

rem本身解析就是“font size of the root element”,也就是相对于根元素字体大小而变化的单位。好处我就不提了,具体实现可以百度一下~

一般来说都是用在移动端上的,不过近年来的浏览器发展也蛮快的,pc端直接用问题不大,我们康康它的兼容性。

上图一片绿油油,搭配自动转换工具,标准可行方案,简直美滋滋~

再次吐槽一下,美术作图不规范,开发泪两行...

这个方案需要建立在美术【能做到】的基础上。我们接到的设计稿出现10多像素大小的文字屡见不鲜,且死不悔改的人一抓一大把,要知道移动端文字最小只能去到10像素,pc端大多只能去到12像素。移动端按图稿能用transform缩放个别文字勉强实现,但pc端就~~ ╮(╯▽╰)╭

最后迎来三号选手【缩放】。

和移动端一样,只要整体缩放到视图合适大小,基本就是我们想要的效果了,妥妥的。

不过到了具体实现方案的时候,这个让我觉得有点一言难尽。

因为它没有完美的实现方案.... _(´ཀ`」 ∠)_

网上能翻得到的方案,我基本去印证过,大概说明一下战斗过程。

  1. viewport。这个是个假方案,我其实以前就知道可能性不大,在移动端用着OK,但pc端我印象中是不可行的。这次再次实践,得出结论是放弃。不要问为啥,问就是不支持,真相可以去查一下文档,增加知识储备~

  2. css zoom属性。这个真的是炒鸡爽,一个zoom设置好,网页整个按比例缩放展示,无需额外调整,真正实现一步到位~
    可惜有个叫Firefox的憨憨抵死不从,一直不跟随大众步伐,全线飘红...

  3. css transform scale。这可以说是最兼容的方案了,作为几乎全绿的靓仔,transform 属性被广泛使用,旋转,缩放,移动,倾斜,位移,几乎囊括所有交互变化,移动端pc端都能为所欲为。

    在我们的需求场景中,它也似乎是胜任的,一个缩放轻松搞定整个页面适问题~
    别高兴得太早,回忆一下transform的特点:transform并没有让元素脱离标准流。可能是出于性能考虑,避免造成回流,无论元素如何transform变换,仍占有原来的空间大小。
    这意味着如果要做常规布局的缩放,你需要裁剪掉缩放后多出来的空白,或者补上放大后缺少了的空间。
    此外,transform后,内部元素如果有fixed定位的子元素,那么这个子元素将不再相对于根元素定位,变成了父元素,类似absolute的存在。テ_デ

完美是不可能的,这世界就没有尽善尽美的事,我只能安慰我自己,我不能既要有要还要...

综上所述,进行小结。

  • 如果美术给力,或者网站属于功能性站点,可以比较刻板,媒体查询即可完成需求。

  • 如果美术给力,设计有规范,字体问题能把控得住,拥抱rem,一切都会很和谐。

  • 没有上面的如果,可选择范围就变得很小了,你只能在不完美中找到出路。

最后说下我实践可行的transform方案吧。

经过上面的说明可以知道,transform缩放方案不适用于单个元素(如按钮)的缩放,也不适用语根元素缩放。它应该是作用在一个块,一个章节上的,且避免在含有fixed定位的子元素上套用。

这条件听着有点苛刻,但这实际已经包含了绝大多数的使用场景的了,并不是小众场景。基本网页都是按版面分块的,而悬浮于页面上的导航,侧边栏也是独立的块,它们内部也可以进行独立的缩放处理。

思路说明:

设置一个外壳元素,用于裁剪/扩张。获取被缩放的块元素的真实尺寸(即使transform缩放了,元素大小仍不会变化的),按缩放比例计算,得到缩放尺寸,直接套用样式,即可去除多余空白/弥补不足空间。

再者就是自动缩放的问题:

监听resize事件(可节流优化),计算缩放比例之后触发新的样式计算。设置样式的的操作可整合成多个小函数方便调用,避免代码重复臃肿。

代码我就不发了,这说透了其实是个稍微花几分钟就能码出来的小功能,没show的价值。

本文到此结束,如果还有其他好的方案,欢迎浏览讨论哦~~

分类:
前端
标签:
分类:
前端
标签:
收藏成功!
已添加到「」, 点击更改