前言
如今网速不再成为适配移动端时选择响应式设计的限制因素,在资源充足的条件下,针对各端各自设计应用界面能达到应用最佳用户体验,毕竟不同类型的设备交互体验是不同的,但在团队前端资源拮据时,相比无脑自适应,响应式设计自然是最为经济适用的。
JS in CSS 与响应式
我们见过很多 CSS 特性 Polyfill 库是由 JS 编写的,却几乎没有反过来的情况,多数时候新特性出现的兼容问题,CSS 新特性必须等待浏览器厂商的跟进和用户自己本地升级来解决,而 JS 很容易利用特性判定的方式为不支持的内容做兼容,甚至是 JS 新语法都可通过各种工具编译到 ES5 来支持,其能力的边界远非 CSS 可及。
就拿近期大家最为期待的容器查询特性 @container
来说,这相比之前屏幕查询适配的方式更加灵活了,无疑是下一代响应式页面设计的利器,按惯例打开 caniuse 看下:
离大规模应用还有些距离。然而用 JS 的同等实现不过分分钟的事情,iofod 里仅需新建一个状态表达式借助模型变量实现:
default:$parentWidth < 800
响应式拓展
回到主流的响应式方案上,CSS 媒体查询也有不少毛病,容器查询普及后估计情况能得到改善(附带一波新语法~),于此同时,JS in CSS 表示一切正常,它的起点就是 CSS 未来的努力终点(误)。那么 JS in CSS 的方案如何支持主流方案的呢?
当下媒体查询基于屏幕去适配,因此我们首先需监听屏幕窗口的变动,保存屏幕尺寸值,接着在表达式里引用它们去计算即可。比如我们把屏幕值保存到 device 的模型变量 vw, vh 上,接下来我们响应屏幕的值去改变样式,如:
default:$vw<device> <= 1024
default:$vh<device> >