移动优先的设计方法很棒——它专注于对用户真正重要的东西,它被很好地实践,并且多年来一直是一种常见的设计模式。所以开发你的 css 移动优先也应该很棒……对吧?
嗯,不一定。经典的移动优先 CSS 开发基于覆盖样式声明的原则:您从默认样式声明开始您的 CSS,并在 min-width 为更大的视口添加断点时覆盖和/或添加新样式(有关详细概述,请参阅“什么是移动优先 CSS 以及它为何如此受欢迎? ”)。但是所有这些异常都会造成复杂性和低效率,这反过来又会导致测试工作量增加和代码库更难维护。承认吧——我们当中有多少人愿意这样做?
在您自己的项目中,移动优先的 CSS 可能仍然是这项工作的最佳工具,但首先您需要根据您正在处理的视觉设计和用户交互来评估它的适用性。为了帮助您入门,以下是我解决您需要注意的因素的方法,如果移动优先似乎不适合您的项目,我将讨论一些替代解决方案。
移动优先 CSS 开发的一些优点——以及为什么它长期以来一直是事实上的开发方法——很有意义:
发展层次。毫无疑问,您从移动优先中获得的一件事是一个很好的开发层次结构——您只需专注于移动视图并开始开发。
尝试和测试。这是一种久经考验的方法,多年来一直有效:它很好地解决了问题。
优先考虑移动视图。移动视图是 最简单 的,也可以说是最重要的,因为它 包含所有关键的用户旅程 ,并且通常占 用户访问的更高比例 (取决于项目)。
防止以桌面为中心的开发。由于开发是使用台式计算机完成的,因此最初专注于桌面视图可能很诱人。但是从一开始就考虑移动设备可以防止我们以后陷入困境;没有人愿意花时间改造以桌面为中心的网站以在移动设备上工作!
设置样式声明然后在更高的断点处覆盖它们可能会导致不良后果:
更复杂。你去的断点层次越远,你从较低的断点继承的不必要的代码就越多。
更高的 CSS 特异性。在类名声明中已恢复为其浏览器默认值的样式现在具有更高的特异性。当您想让 CSS 选择器尽可能简单时,这对于大型项目来说可能是一件令人头疼的事情。
需要更多的回归测试。在较低视图中对 CSS 的更改(例如添加新样式)需要对所有较高的断点进行回归测试。
浏览器无法优先考虑 CSS 下载。在更广泛的断点处,经典的移动优先 min-width 媒体查询不会利用浏览器按优先级顺序下载 CSS 文件的能力。
覆盖值本身并没有错。CSS 就是为此而设计的。尽管如此,继承不正确的值是没有帮助的,并且可能是繁重且效率低下的。当您必须覆盖样式以将其重置为默认值时,它还可能导致样式特异性增加,这可能会在以后引起问题,尤其是在您使用定制 CSS 和实用程序类的组合时。我们将无法将实用程序类用于已以更高特异性重置的样式。
考虑到这一点,我现在开发的 CSS 更多地关注默认值。由于没有特定的顺序,也没有要跟踪的特定值链,这让我可以 同时 开发断点。我专注于在封闭的媒体查询范围(即具有 max-width 集合的任何范围)中寻找常见样式并隔离特定异常。
这种方法开辟了一些机会,因为您可以将每个断点视为一张白纸。如果一个组件的布局看起来应该在所有断点处都基于 Flexbox,那很好,可以在默认样式表中编码。但是,如果 Grid 看起来更适合大屏幕,而 Flexbox 更适合移动设备,那么当 CSS 放入封闭的媒体查询范围时,这些都可以完全独立完成。此外,同时开发要求您预先对所有断点中的任何给定组件都有很好的理解。这有助于在开发过程的早期发现设计中的问题。我们不想陷入为移动设备构建复杂组件的兔子洞,然后在获得桌面设计时发现它们同样复杂且与我们为移动视图创建的 html 不兼容!
尽管这种方法并不适合所有人,但我鼓励您尝试一下。有很多工具可以帮助并发开发,例如Responsively App、Blisk等等。
话虽如此,我觉得订单本身并不是特别相关。如果你习惯于专注于移动端视图,对其他断点的需求有很好的理解,并且更喜欢一次在一台设备上工作,那么一定要坚持经典的开发顺序。重要的是识别常见的样式和异常,以便您可以将它们放入相关的样式表中——一种手动摇树的过程!就个人而言,我发现在跨断点处理组件时这会更容易一些,但这绝不是必需的。
在经典的移动优先 CSS 中,我们会覆盖样式,但我们可以通过使用媒体查询范围来避免这种情况。为了说明区别(为了简洁起见,我使用 SCSS),让我们假设有三种视觉设计:
举个简单的例子,块级元素的默认 padding 值为“20px”,在平板电脑上被覆盖为“40px”,在桌面上设置回“20px”。
经典min-width移动优先:
.my-block {
padding: 20px;
@media (min-width: 768px) {
padding: 40px;
}
@media (min-width: 1024px) {
padding: 20px;
}
}
封闭媒体查询范围:
.my-block {
padding: 20px;
@media (min-width: 768px) and (max-width: 1023.98px) {
padding: 40px;
}
}
细微的区别在于,移动优先的示例将默认设置padding为“20px”,然后在每个断点处覆盖它,总共设置了 3
次。相比之下,第二个示例将默认值设置padding为“20px”,并且仅在它不是默认值的相关断点处覆盖它(在这种情况下,tablet 是例外)。
目标是:
为此,封闭的媒体查询范围是我们最好的朋友。如果我们需要对任何给定视图进行更改,我们会在适用于特定断点的 CSS 媒体查询范围内进行更改。我们将不太可能引入不需要的更改,并且我们的回归测试只需要关注我们实际编辑的断点。
以上面的例子为例,如果我们发现 .my-block 桌面上的间距已经被该断点处的边距考虑了,并且由于我们想要完全删除填充,我们可以通过将移动设备设置 padding 在封闭的媒体查询范围内来做到这一点。
.my-block {
@media (max-width: 767.98px) {
padding: 20px;
}
@media (min-width: 768px) and (max-width: 1023.98px) {
padding: 40px;
}
}
我们块的浏览器默认值为“0”,因此我们可以将移动设备包装在封闭的媒体查询中 padding ,而不是添加桌面媒体查询并使用 unset 或“0”作为值(移动优先)因为它现在也是一个例外)所以它不会在更宽的断点处被拾取。在桌面断点处,我们不需要设置任何样式,因为我们需要浏览器默认值。 paddingpaddingpadding
过去,由于浏览器的并发请求数限制(通常约为 6 个),将请求数保持在最低限度非常重要。因此,图像精灵和 CSS 捆绑的使用成为常态,所有 CSS 一次性下载,作为具有最高优先级的一个样式表。
随着 HTTP/2 和 HTTP/3 的出现,请求的数量不再是过去的大问题。这允许我们通过媒体查询将 CSS 分成多个文件。这样做的明显好处是浏览器现在可以请求它当前需要的 CSS,其优先级高于它不需要的 CSS。这更高效并且可以减少页面呈现被阻塞的整体时间。
要确定您使用的 HTTP 版本,请访问您的网站并打开浏览器的开发工具。接下来,选择网络选项卡并确保协议列可见。如果“h2”列在Protocol下,则表示正在使用 HTTP/2。
注意:要在浏览器的开发工具中查看协议,请转到网络选项卡,重新加载页面,右键单击任何列标题(例如,名称),然后检查协议列。
此外,如果您的网站仍在使用 HTTP/1...为什么?!!你在等什么?对 HTTP/2有很好的用户支持。
将 CSS 分成单独的文件是一项有价值的任务。使用相关属性链接单独的 CSS 文件media允许浏览器立即识别哪些文件是需要的(因为它们是渲染阻塞的),哪些可以延迟。基于此,它为每个文件分配适当的优先级。
在以下在移动断点上访问的网站示例中,我们可以看到移动和默认 CSS 以“最高”优先级加载,因为当前需要它们来呈现页面。其余的 CSS 文件(打印、平板电脑和桌面)仍会下载以备日后需要,但优先级为“最低”。
使用捆绑的 CSS,浏览器必须先下载 CSS 文件并对其进行解析,然后才能开始渲染。
虽然,如前所述,将CSS 分成不同的文件,链接并用相关media属性标记,浏览器可以优先考虑它当前需要的文件。使用封闭的媒体查询范围允许浏览器在所有宽度上执行此操作,而不是经典的移动优先min-width查询,其中桌面浏览器必须以最高优先级下载所有 CSS。我们不能假设桌面用户总是有一个快速的连接。例如,在许多农村地区,互联网连接速度仍然很慢。
媒体查询和单独的 CSS 文件的数量将根据项目要求因项目而异,但可能类似于下面的示例。
捆绑的 CSS <link href="site.css" rel="stylesheet"> 这个单个文件包含所有 CSS,包括所有媒体查询,它将以最高优先级下载。 | 分离的 CSS <link href="default.css" rel="stylesheet"> 分离 CSS 并media在每个标签上指定一个属性值link允许浏览器优先考虑它当前需要的内容。在上面列出的五个文件中,将以最高优先级下载两个:默认文件和与当前媒体查询匹配的文件。其他将以最低优先级下载。 |
根据项目的部署策略,对一个文件( mobile.css 例如 )的更改只需要 QA 团队在该特定媒体查询范围内的设备上进行回归测试。将其与部署单个捆绑 site.css 文件的前景进行比较,这种方法通常会触发完整的回归测试。
移动优先 CSS 的采用是 Web 开发中一个非常重要的里程碑。它帮助前端开发人员专注于移动 Web 应用程序,而不是在桌面上开发网站,然后尝试对其进行改造以在其他设备上工作。
我认为没有人想再次回到那种开发模式,但重要的是我们不要忽视它所强调的问题:如果我们优先考虑一种特定设备(任何设备),事情很容易变得复杂且效率低下。其他。出于这个原因,专注于 CSS 本身,始终注意什么是默认设置和什么是异常,似乎是很自然的下一步。我已经开始注意到我自己的 CSS 以及其他开发人员的 CSS 进行了一些小的简化,并且测试和维护工作也更加简化和高效。
一般来说,尽可能地简化 CSS 规则的创建最终是一种比绕着覆盖循环更干净的方法。但无论您选择哪种方法,它都需要适合项目。移动优先可能会(也可能不会)成为所涉及内容的最佳选择,但首先您需要充分了解您要进行的权衡取舍。
来自:https://www.toutiao.com/article/7112054417645453824
有些机型有些app不能横屏:比如Android的微信就没有横屏模式,而ios的微信能开启横屏模式。解决办法就是在竖屏模式下,写一个横屏的div,然后设置rotate正(负)90度,把他旋转过来;而且如果用户切到横屏时,需要把rotate复原,要求也能正常展现。
在做移动端时间转化为时间戳时,遇到了一个问题,安卓手机上访问时,能拿到时间戳,从而正确转换时间,而在iOS上缺不能正常显示,显示的时间为:NaN-NaN-NaN ,例如getTime()在ios上拿不到时间戳显示NaN
因为对于一枚前端而言,天天和页面打交道(H5页面),那么布局的活总是少不了,这也将面临不同终端的适配问题。不知道你是否和我一样,页面布局总是或多或少会有一些蛋疼的事情发生。
移动端点透现象的解决办法:解决方案一:来得很直接github上有个fastclick可以完美解决;解决方案二:用touchend代替tap事件并阻止掉时A元素touchend的默认行为preventDefault(),从而阻止click事件的产生;解决方案三:延迟一定的时间(300ms+)来处理事件...
这篇文章主要总结移动端页面开发时需要注意的一些问题。比如:防止手机中网页放大和缩小、format-detection设置、上下拉动滚动条时卡顿慢 、禁止复制选中文本...
由于微信webvie内置了调整字体大小的功能,如果用户调整了这一设置,就会导致了网页中的字体比原本的尺寸偏大或偏小,使得网页可能出现排版错乱,或者字体太小看不清的情况发生
在移动端部分浏览器中点击了图片,变成了查看图片的效果,怎么防止img的图片被手机浏览器的图片查看器打开呢?下面整理了一些方法来实现:在img元素上添加 onclick=return false、背景图的方式插入、使用js事件阻止默认行为的方式
移动端浏览器在派发点击事件的时候,通常会出现300ms左右的延迟。也就是说,当我们点击页面的时候移动端浏览器并不是立即作出反应,而是会等上一小会儿才会出现点击的效果。
在 PC 端,视口指的是浏览器的可视区域,其宽度和浏览器窗口的宽度保持一致。在 CSS 标准文档中,视口也被称为初始包含块,它是所有 CSS 百分比宽度推算的根源,给 CSS 布局限制了一个最大宽度。而移动端则较为复杂,它涉及到三个视口:布局视口(Layout Viewport)、视觉视口(Visual Viewport)和理想视口(Ideal Viewport)
随着技术的飞速发展,当前lib-flexible适配方案也在逐渐被更新的适配方案所替代,但是截止目前为止,还没有发现哪种方案能完全满足适配各种机型的需要,也会有一些小的问题。lib-flexible是目前用到的比较成熟的适配方案
内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!