以下是 Dirk Lüth 的一篇客座文章。Dirk 对响应式布局有独特的见解。它使用媒体查询断点来像我们习惯的那样重新排列元素,但流体列宽以rem
单位而不是百分比设置,并且font-size
根据屏幕宽度使用JavaScript动态调整。结果产生了一种“缩放”效果,向上或向下,直到下一个媒体查询生效。我让他来详细介绍一下。
简介
我相信我们都同意,响应式网页设计在过去几年中一直是最重要的主题之一,并且随着移动设备的增长将继续发展。作为一名资深的前端和后端开发人员,我对公司内部的研究和开发有着浓厚的兴趣,我负责评估RWD等技术。每当我收到一个指向全新CSS网格系统的链接时,我都会越来越怀疑。它们对我来说感觉“不对劲”,但我不知道为什么。
然后,我偶然发现了一篇由Ian Yates撰写的很棒的文章,名为“960px之外的生活:为大屏幕设计”,它向我介绍了“屏幕空间”这个术语。在此之前,我使用CSS中的rem
单位进行了一些更深入的研究,这是一个幸运的巧合。突然间,我知道哪里感觉不对劲了。
当谈到RWD时,我们主要讨论的是低于我们布局目标宽度的设备。但是更大的屏幕呢?你们大多数人都会同意,目标宽度为960px的非RWD网站在这种屏幕上看起来有点奇怪或显得格格不入。当我们谈论人们使用60英寸电视访问我们的网站时,情况变得更加明显。当然,这些电视机很可能仍然只有全高清分辨率。但请记住,坐在电视机前的人可能距离屏幕至少4米/10英尺。
现状
无论我们先做移动端、平板电脑端还是桌面端——我们大多数人最终都会至少有3个具有不同布局的媒体查询断点。或者我们会使用一个网格系统,它会自动更改我们网站内容元素的构成。或者两者兼而有之。如果我们要支持越来越多的不同分辨率和不同的观看情况,这两种方法都有其缺点。
- 更多断点 = 更多布局 = 更多工作
- 难以平衡元素的灵活性和比例
- 元素重新堆叠时的卡顿感
- 受用于填充视口内容量的限制
- 网格的艺术不仅仅是Photoshop中的某些指南
无论我们选择哪种最合适的方式:**实际内容(包括每个元素)都不会按比例缩放。**
概念验证
我想到的是一个完全基于font-size
的rem
驱动布局。如果这个想法有效,我可以通过简单地更改<html>
元素上的font-size
轻松缩放所有内容。这个概念将解决最大的挑战:**布局在其边界内几乎完美地缩放。**
请记住,rem
仅在IE9+和所有其他当前浏览器中受支持。对于旧版浏览器,可以使用基于px
的回退。请参见下面的示例混合。
我开始使用我自己的网站进行一些概念验证工作。在我开发了一些将像素单位(直接从布局中获取)转换为基于我决定使用的14px font-size
的rem
单位的LESS混合之后(参见示例),静态版本运行得非常好。
LESS混合
这里有两种类型的混合:一种用于单个参数属性(如font-size
),另一种用于具有多个参数的属性(如border
)。两者都依赖于必须定义的两个LESS变量。
@remuxFontsize: 14px; // base font size
@remuxFallback: false; // switch to include px fallback
.remux(font-size, @value) {
@processingRem: ((round((@value / @fontsize-base) * 10000000)) / 10000000);
.result(@value, @fallback) when (@fallback = true) {
font-size: ~"@{value}px";
font-size: ~"@{processingRem}rem";
}
.result(@value, @fallback) when (@fallback = false) {
font-size: ~"@{processingRem}rem";
}
.result(@value, @remuxFallback);
}
.remux(border, @value) {
@processingRem: ~`(function() { var base = parseFloat("@{remuxFontsize}"); return "@{value}".replace(/[\[\]]/g, '').replace(/([0-9]*[.]{0,1}[0-9]*px)/gi, function() { return ((Math.round((parseFloat(arguments[0]) / base) * 10000000)) / 10000000) + 'rem'; }); }())`;
.result(true) {
border: @value;
border: @processingRem;
}
.result(false) {
border: @processingRem;
}
.result(@remuxFallback);
}
使用混合非常简单。
/* Instead of this... */
font-size: 16px;
/* You use this */
.remux(font-size, 16px);
/* Instead of this... */
border: 7px solid #000;
/* You use this */
.remux(border, ~"7px solid #000");
当我将网站的CSS切换为使用rem
时,我已经能够通过开发人员工具更改<html>
元素的font-size
,并看到网站几乎完美地缩放了!
接下来我需要一个解决方案,以便在“resize”和“orientationchange”事件上通过JavaScript动态计算此值。基本计算非常简单。
;(function(window, document, undefined) {
'use strict';
var targetLayoutWidth = 980,
baseFontsize = 14,
htmlElement = document.getElementsByTagName('html')[0],
documentElement = document.documentElement;
function updateFontsize() {
var currentFontsize = baseFontsize * (documentElement.offsetWidth / targetLayoutWidth);
htmlElement.style.fontSize = currentFontsize + 'px';
}
window.addEventListener('resize', updateFontsize, false);
window.addEventListener('orientationchange', updateFontsize, false);
updateFontsize();
}(window, document));
在设置结果font-size
时,我意识到浮点数在浏览器四舍五入时会导致问题(参见示例)。因此,我最终不得不对font-size
进行floor
操作,这消除了任何四舍五入故障,但也使缩放不太“流畅”。不过,对我来说,它仍然感觉绰绰有余(参见示例)。
接下来,我在我的iPad 2上进行了一些扩展测试,并将HTML视口设置为“device-width”。我承认,当不仅在初始页面加载后一切正常,而且捏合缩放和设备方向更改也按预期工作时,我有点惊讶。
实现布局
现在我能够无限缩放我的布局,我开始实现断点。仍然需要断点,因为将font-size
缩小到零或放大到无限大实际上没有意义(尽管在技术上是可能的)。
我开始通过确定需要什么来规划未来布局对象的结构。这导致了以下JavaScript对象结构。
var layouts = {
'ID': {
width: 980, // designs target width
base: 14, // designs base font-size
min: 10, // minimum font-size
max: 18, // maximum font-size
breakpoint: 980 * (10 / 14) // minimum breakpoint
}
}
现在可以定义布局了,我必须将它们添加到更新函数中,这比我想象的影响要大一些(参见示例)。
;(function(window, document, undefined) {
'use strict';
var htmlElement = document.getElementsByTagName('html')[0],
documentElement = document.documentElement,
layouts = {
mobile: {
width: 420,
base: 14,
min: 10,
max: 23,
breakpoint: 420 * (10 / 14)
},
desktop: {
width: 980,
base: 14,
min: 10,
max: 18,
breakpoint: 980 * (10 / 14)
}
},
state = {
size: null,
layout: null
};
function updateFontsize() {
var width, id, layout, current, size;
width = documentElement.offsetWidth;
for(id in layouts) {
if(layouts[id].breakpoint && width >= layouts[id].breakpoint) {
layout = id;
}
}
if(layout !== state.layout) {
state.layout = layout;
htmlElement.setAttribute('data-layout', layout);
}
current = layouts[state.layout];
size = Math.max(current.min, Math.min(current.max, Math.floor(current.base * (width / current.width))));
if(size !== state.size) {
state.size = size;
htmlElement.style.fontSize = size + 'px';
}
}
window.addEventListener('resize', updateFontsize, false);
window.addEventListener('orientationchange', updateFontsize, false);
updateFontsize();
}(window, document));
我在Chrome、Safari、FF17+和IE9(REMux应该可以工作的地方)上测试了这个原型,并且它确实可以工作。
查看实际效果
前面已经提到,REMux 在我自己的网站上被大量(滥)用。除此之外,CodePen上还有一些Pen,它们在整篇文章中都有链接。此外,还有一个Pen展示了我最终的结果。
我希望很快就能准备好一些文档——但代码本身并不难阅读。
接下来是什么?
REMux 运行得如此出色,以至于我决定将其作为我不断增长的JavaScript库的一部分,该库可以在GitHub上找到。在过去几周里,我还添加了一些此基本文章中缺少的其他功能。
- AMD兼容(require.js)
addLayout()
方法,用于在不更改脚本的情况下添加布局- 像素密度、缩放级别检测、字体大小、总数和图像的比率
getState()
方法,将返回所有大小和比率- 发出事件
ratiochange
和layoutchange
,并将当前状态作为参数传递 - 用于重复输入事件的防洪机制,以提高性能
- 可以通过对象扩展机制进行扩展
REMux 的独立版本可以在我的GitHub存储库的“packages”文件夹中找到,大小约为4kb(压缩并gzipped)。它不依赖于jQuery或任何其他大型库。它对我的库中其他组件的依赖项都包含在包中。我的JavaScript库的所有组件都是根据MIT和GPL许可证双重许可的。
随时下载并在您的项目中使用它,但请记住提供反馈并报告错误,以便我能够使其变得更好!
即使我不是特别喜欢将JavaScript用于布局问题,我也必须说你的方法非常令人印象深刻。
它不仅运行得非常完美,而且能够解决复杂的问题。
迪尔克,干得非常好!太棒了。
我也没有,雨果,但作为一个实验,它运行得如此出色,我无法抗拒诱惑 :)
事实上,我不确定是否应该把它展示给我们的美术部门——他们肯定会争辩说,我们开发人员通常的抱怨总是被夸大了……而最终,REMux 或多或少地解决了他们作为设计师的问题,而不是我们开发人员的问题。
迪尔克
嗨,迪尔克,
他们可能已经告诉过你了,但在 Mac 上的 Firefox 浏览器中,你的网站在视网膜设备上有点问题(不知道其他配置怎么样,但在这种情况下它肯定无法正常工作)
这是我从你发布的链接中截取的屏幕截图。
顺便说一句,文章写得不错!
我的上网本 1024×768 win7 FF 18 上也出现了类似于胡安霍的结果。
@胡安霍
我现在也有一台 15 英寸的视网膜 MBP,并在上面测试了新版本 REMux 2.0。它看起来应该没问题,但放大仍然会导致问题,因为 Firefox 中的缩放实现完全很奇怪。
到目前为止,我只知道,与其他所有浏览器不同,FF 18+ 将当前的缩放级别包含在 window.devicePixelRatio 中,可以通过 JS 访问。现在我了解到,此外,浏览器缩放级别也反映在媒体查询中的“min-resolution”中。因此,在视网膜设备上,你期望媒体查询 @media (min-resolution: 192dpi) {} 始终匹配 FF 18,但如果浏览器被放大,它就不会匹配(但会匹配高于 210dpi 的内容)。
除此之外,我还了解到,如果连接了第二个显示器,在 FF 18.1 中,视网膜 Mac 上的 devicePixelRatio 默认情况下始终为 1。
总的来说,我感觉 Firefox 的实现使其在当前状态下完全不可用。团队意识到了这些问题,但似乎不愿意改变当前(完全有 bug 的)行为 :(
作为一名日常工作中会关注移动/响应式设计的人,我绝对有兴趣了解更多关于这方面的信息。
这是一个不错的方法。JavaScript 发挥着重要的作用。
不错的解决方案 :)
我之前为一个客户做了一个原型站点布局,使用了类似的想法,但保持简单,没有使用 JS。
在样式表中将 html 字体大小重置为 10px,然后你可以使用 rem 来表示任何想要随显示器缩放的尺寸。然后设置媒体断点以重置基本字体大小。
这样做的优点是它将布局代码保留在 css 中,并且易于维护/调整/自定义不同断点的尺寸(或响应式地重构)。某些元素(通常是 js 组件)可能需要使用 JS 进行一些微调,但总的来说,它在跨浏览器方面运行良好。
你能就此发布一篇文章吗?
谢谢
我很乐意!但现在有点缺时间。
迪尔克做了我做的很多事情,但我认为我的方法有所不同,因为
为了保持简单(例如,使用它来保持缩放时的纵横比),我将基本字体大小设置为 10px。这使得所有宽度和高度的设置都易于计算,然后事物将按比例缩放(大约!),但这可能不是缩放网络字体的最佳方法(某些字体在某些尺寸下会变得杂乱)。
我坚持使用媒体查询(迪尔克在 remux 的 v2 中可以选择性地使用),并且使用的媒体查询比他在 v2 中使用的少得多。为了平滑“跳跃”,我使用了过渡(transition: 0.5s all;)来动画化尺寸变化。警告 - 我不建议将此用于所有解决方案,复杂的页面可能会变得笨拙。
某些 JS 驱动的功能在缩放方面存在真正的问题 - 我使用的滑动轮播在跨浏览器方面是一个噩梦,而且我“仅仅”让它在主要的最新浏览器中运行。
我认为这是一项有用的技术,但在正确的场景下使用。一种通用的缩放方法(插入代码并忘记它)是一个糟糕的主意,尤其是在小型设备上。
当显示器尺寸大于“标准”屏幕尺寸时,此技术真正发挥作用。在此尺寸以下使用标准响应式设计,在此尺寸以上使用字体缩放技术。
如果放大,网站在大型屏幕上看起来可能很棒,但要注意像素化 - 这与支持视网膜显示器类似。也许如果你超过标准阈值,你可以(使用 JS)加载更高分辨率的图像……?
@胡安霍 和 @suprsidr
您是否介意在 FF18 中打开以下链接并打开调试控制台,并将您应该看到的控制台日志发送给我?
http://www.qoopido.com/404/
遗憾的是,我没有权限访问视网膜 Mac,但我有一个想法可能是什么原因……
提前感谢!
迪尔克
我尝试过类似的技术,并且通常使用 REM 作为尺寸和字体大小,因为它在编写媒体查询时减少了所需的 CSS 量。不过有一点很突出,这篇帖子的共识似乎围绕着按比例缩小布局。我自己的实验都是关于在较小的设备上放大字体大小,因此缩放效果相反。或者为具有较大 CSS 像素大小的移动设备(但物理尺寸不大 - 例如 Galaxy s3 或 HTC 1x)放大字体大小,然后为 iPhone 等 320px 设备再次缩小字体大小。结果是在桌面设备上调整大小时看起来很奇怪,但在各种设备上提供了最佳的布局优化。我不明白为什么有人会争论在手机上缩小字体大小。
@克里斯·鲍斯
它可以双向缩放。你只需根据转换为 REM 的 px 测量值定义布局,并在布局将被放大或缩小的范围内定义字体最小/最大限制。对于某个特定布局,你的基本字体大小很可能介于最小和最大限制之间。
谢谢迪尔克,我明白它可以双向缩放。我想我只是想知道关于字体是否应该为移动设备放大或缩小的普遍共识是什么。在较小的屏幕上放大字体大小可以使它们更易读 - 链接更容易点击等(尤其是在 720px 宽的移动手机上) - 但这在桌面网站上感觉很奇怪,因为你希望设计在调整屏幕大小时缩小。我还没有时间正确地使用你的脚本(稍后会期待它),但我正在考虑是否会尝试将其与检查设备像素密度结合使用,以确定设备是台式机还是移动设备,然后切换每个设备的字体缩放方式。希望这说得通,如果我没有完全理解 REMux,请原谅我,我现在处于周一早上“快速浏览”模式。
不客气 @克里斯·鲍斯 - 我非常清楚你所说的“周一早上快速浏览模式”的意思 :)
如果你问我,我会说,总的来说,移动设备会尽其所能提供最佳效果。
如果你计划进一步调查 devicePixelRatio,请记住,例如,视网膜显示屏的 iPhone 4s 在视口设置为 device-width 时仍然会给你 320px。手机本身随后会缩放网站以适应其 640px 的物理分辨率。因此,字体大小为 10px 的文本实际上将具有 20px。
有一些关于观看距离、屏幕物理尺寸和字体大小如何关联的很好的信息来源 - 如果你有兴趣,我可以查找这些链接……
嗨,迪尔克。一切顺利,我对理解视网膜屏幕和像素密度之间的差异非常了解,在 CSS 媒体查询中使用像素密度的要点是台式机设备不返回 CSS 像素密度,从而使其成为区分台式机和移动设备的非常简单的方法,而无需诉诸 UA 检测。
我更关心的是为大型手持设备的用户提供与使用 iPhone 的人相当的用户体验。我看到很多响应式设计在 iPhone(视网膜或其他)上运行良好,但在 720px 宽的 Android 设备上,文本内容太小,而且通常会采用针对平板电脑等设计的较大两栏布局。这些设备的 CSS 像素大小是 iPhone CSS 宽度(如你所说 320px)的两倍多,但你手中的物理尺寸却几乎只大了半英寸,因此文本和布局看起来小得多,链接变得更难点击。当谈到使用比桌面版本更大的字体大小时,我指的是这些设备,而在这里使用 REM 技术进行缩放真正发挥了作用。
尽管如此,每一天都会带来新的挑战,这就是我们都在这里的原因。:) 期待稍后尝试 REMux。
@克里斯·鲍斯
但要小心这一点。
视网膜 Macbook 的 devicePixelRatio > 1。
Mozilla 在 FF18 中决定(出于某些模糊的原因)将浏览器缩放级别包含到 devicePixelRatio 中,这意味着那里可能会出现一个相当大的数字。
我怀疑第二个要点是 Juanjo 上面报告的错误的原因。
说得对。感谢你的提醒。我当然不知道 FF18 的问题..哎呀。
我们需要 JS 来做这个吗?如果你已经为所有内容使用了相对单位(em、rem 等),那么随着视口大小每增加 10%,我们能否不将字体大小增加 10%(向上/向下到某个合理的最小/最大值)。我个人是从移动优先开始,然后从那里向上扩展。
然后所有内容都将根据视口的宽度按预期缩放。这甚至应该保留文本换行到多行等的地方!我在这个 BBC 关于响应式设计的演示文稿 中得到了这个提示。
第二句失败了!它应该写成
“那么,随着视口大小每增加 10%,我们能否不将字体大小增加 10%”
@Nick Williams
小心,REM 不是相对单位,而是绝对单位,它始终与 HTML 元素本身的字体大小相关,而不是 body。
如果你只使用 EM,你提出的方法就会起作用。但是 EM 会使事情变得非常复杂,因为需要进行必要的父/子计算。因此,如果你必须更改任何字体大小,事情就会开始变得非常复杂。
所以,我决定尽可能减少媒体查询的使用 :)
我认为这并不完全正确。一个值是相对的,因为它的值是根据其他东西定义的。而
rem
的确是相对于另一个值定义的,在这种情况下是根字体大小。你甚至自己也说过“它始终**关联**到 HTML 元素的字体大小” ;-) 只要你用 rem 定义了所有内容,上述技术就可以完美地工作,只需调整 html 的字体大小,而不是 body,并在查询中使用 rem 而不是 em。至于 em,你多久会整体调整容器元素的字体大小一次?我从未需要说类似
.sidebar { font-size: 2em;}
的话(其中.sidebar
是一个<div>
或<aside>
或其他内容),相反,你只需调整文本节点本身的字体大小(<h1>
、<p>
等)。至少在我经过深思熟虑和改进之后,我的工作方式就是这样。也不要担心多个媒体查询,我尝试使每个媒体查询都非常细化并具有特定的目的,而不是少数几个处理所有内容的查询。这是一种感觉不对劲的事情,但使用它没有任何问题——性能或其他方面。我将其比作切换到使用非常细化、单一用途/职责的类,这意味着你将多个类应用于每个标签。感觉不对劲,但没有问题。
一篇很棒的文章,让我思考了很多:http://trentwalton.com/2013/01/07/flexible-foundations/
抱歉最终听起来有点苛刻,不是故意的 :) 只要任何人都能从中获得一些东西,我就完全满意了!正如我在文章中已经说过的,这是一个双面故事。一个是关于只为 CSS 使用 REM,另一个是使用它进行一些 JS 乐趣……
我会把你的链接放在我的口袋阅读列表中,保证!
不用道歉,你一点也不苛刻,只是有礼貌和客气 :) 我只是在享受一场有趣的讨论。
真的不要错过 Trent 的文章,它很短(5 分钟读完),但非常有见地!对我来说,这是那些像闪电一样击中你的顿悟时刻之一。
刚刚读了它,完全同意——有趣的是——这正是我想到的,尽管以前没有读过这篇文章。我确实很难总结 REMux 方法有什么“不同”,但这篇文章确实描述得非常好!
本质是一样的:当已经有完美满足你所有需求的解决方案时,为什么要以多种方式使网站的某些部分具有响应性?
我很有可能会在不久的将来尝试一个纯 CSS 版本!
哈哈,相信我,自从文章发表以来,几乎没有一天我没有把它转发给某人作为兴趣点!这篇文章启发了我的思想,就像天使在我的耳边低语了生命的意义!好吧,也许没有那么夸张,但它彻底改变了我的思维,并将我脑子里一些模糊的想法整合了起来。
我正在(缓慢地)根据这个原则构建我的个人网站,很高兴看到所有内容都按比例缩放(边距、宽度、字体大小等),只需简单地调整 body 的字体大小!
我想就此发表一下我的意见,因为我完全同意 Nick 的观点。你有一个 4Kb 的 JavaScript 文件,它基本上做了 Nick 建议的事情(除了字体大小应该应用于
HTML
元素,正如你已经指出的那样)。这种技术使用纯 CSS 可以完美地工作。而且我认为使用媒体查询块来实现这一点没有任何问题……尤其是在这意味着我不必使用 JavaScript 进行布局的情况下。然后是我的布局样式。
还有一些 LESS。
注意:16 可以替换为
@variable
,但是我假设大多数用户没有更改浏览器的默认字体大小——它几乎总是 16px。我将美学字体大小应用于 body 标签并保持根标签完整,以便我始终可以依靠 16 为基础的 REM 计算。今天有一些空闲时间,所以开始尝试。
静态部分很容易。
只需计算字体大小切换的所有断点并将其作为媒体查询实现。我之前已经将断点作为媒体查询用于布局切换——所以没有变化。
首页上的像素化耳机。
它只是随着字体大小缩放,字体大小与 REMux 的 JS 部分耦合——解耦很容易……
幻灯片和单个图像中的响应式图像。
这个让我很头疼,因为它们不仅与 devicePixelRatio 相关,还与字体大小因素相关,而且(最成问题的部分)还与当前布局相关。由于我在 html 元素上丢失了布局类,所以我暂时将其省略了。因此,现在以前“移动”布局中的图像加载了更高的字体大小因子,而没有考虑更窄布局引起的大小因子。不确定如何解决这个问题——但会继续思考……
联系表单的模态覆盖层。
需要在移动/桌面布局之间切换位置,现在在打开覆盖层时完成。仍然需要在“调整大小”和“方向更改”事件上实现对此的检查,但之后就会没问题了。
我很有可能会彻底修改 REMux 以反映减少的需求(之后只会提供一些常见比率),这将使其变得更轻量级——并且不需要使纯静态网站变得具有响应性。
迪尔克
感谢你的反馈,Dirk,很高兴看到你如何处理这种方法。
我怀疑幻灯片之类的东西总是非常特定于实现的,因为变量太多。
至于模态,除非我误解了你的意思,否则你是否仍然需要 JS?对于移动设备,你不能只将其设置为全屏(或几乎全屏,在边缘留一些边距),这将允许它适应所有屏幕尺寸。然后对于更大的屏幕,媒体查询使其变小(相对于屏幕尺寸)?
附注:如果在关闭评论后你想进一步讨论,请在 Twitter 上联系我
@WickyNilliams
这个想法之前已经被讨论过了,我在我的几个项目中也用过它。
Trent Walton 大约一个月前写过关于所谓的“灵活基础”的文章,我相信他不是第一个发现它的人。
基本思想是 Nick Williams 刚刚提到的。你使用 @media 查询在某些断点(如果你愿意,可以有多个)更改
font-size
。不需要 JavaScript。在 win phone 7.x/IE9 上出现了一个有趣的错误:网站比例非常大。当我尽可能地缩小缩放比例时,我几乎无法将你徽标中的字母“Q”容纳在屏幕上。当放大缩放时,我可以用“i”上的那个点轻松地将屏幕填充为白色。好吧,所有酷炫的东西总是在这个浏览器中崩溃,而 WP8 则使用 IE10。希望他们能在 WP7 上更新到 IE10……
我承认我没有在 Windows Phone 7 上使用 IE9 进行测试,可能有很多原因可能与 REMux 本身相关或不相关,但也可能与网站本身相关 :(
向你致敬,Dirk,基于字体大小的 rem 驱动的布局的想法永远不会出现在我的脑海中 :)
有趣的想法,但是,除非我遗漏了什么,否则这会带来一些重大的可访问性问题——本质上你阻止了用户缩放你的网站。
我尝试了缩放,它会自动重置回默认大小——这正是你的脚本预期的功能——再次缩放——它又缩小了。再按几次Ctrl+,它突然变得非常大(但没有水平滚动条,所以我无法移动它来查看所有内容)。
这让我觉得最好让用户决定他们想要如何查看你的网站,放弃我们能够完全控制视口的想法。
这很可惜,因为这种方法有很多优点,而且我想它在大型设备(例如电视)上会运行得非常好。
你是否尝试过在任何演示或我的网站上直接放大/缩小,以及在哪个浏览器/操作系统上?我在我的网站上使用的最终JS中实现了缩放检测,但它可能存在错误,因为对于每个浏览器来说,检测方式完全不同,甚至是不可能的。
是在你的实际网站上。
Win XP / Chrome。
你说得对,可以重现它,并且已经找到了错误。我需要考虑如何最好地实现修复,但这只是一个小的改动。希望今天晚上有时间……
无论如何,非常感谢你的报告!
太棒了——如果缩放问题在跨浏览器/操作系统/设备上得到可靠修复,我可以看到这对于某些设计来说是一个非常有用的脚本。
应该已经修复了——但请记住,缩放检测总是有点“hacky” :(
我对该网站的性能并不满意。当然,人们通常不会在网站加载后调整大小,但它非常容易出错。
你有没有看到标题中写着“实验性”?你是否认真仔细地查看过它?是否有人说它是神圣的、永不失败的圣杯?除了说“非常容易出错”之外,你是否费心提供了任何建设性的反馈,并省略了哪些内容无法正常工作以及在哪个操作系统/浏览器上?
简单的答案:没有,你没有……
……至少从你的评论来看,我无法判断。
抱歉有点严厉,但这种评论很烦人——这里大多数人很可能会同意。
@Dirk 对于如此实验性的东西,你似乎对我的评论感到非常不安。“元素的抖动重新堆叠”是你走上这条道路的原因。这就是我评论它有错误的原因。在任何(支持的)浏览器中调整大小并观看[我在 Mac OS 10.8.2 上]。除了偷懒并让 JavaScript 库为你完成工作之外,我不认为这有什么优势。
我明白这是由于必须对字体大小取整造成的。我仍然对性能不满意。在所有现代浏览器中。这是我的意见。你不必关注它。
这项研究有趣吗?绝对的。它是否使开发人员的工作更容易?可能在非常特定的情况下,并且可能在未来越来越多。
我今天不会使用它(是的,我读到它是“实验性的”,但它仍然必须与今天相关),因为有些人可能会在运行时调整浏览器窗口大小,我不想让他们看到这种情况。此外,如果由于任何原因有人没有启用 JavaScript,我仍然必须为他们创建带有字体大小更改的媒体查询(以及任何旧版 IE 浏览器)。为什么要用两种方法做呢?
嗨,Merne :) 我并没有真正生气,只是错过了你提到的任何问题细节。这导致我得出(显然是错误的)结论,即你甚至没有更详细地查看。
如果你像现在这样用你的回答写出来,那就完全没问题了。建设性批评总是一件好事,我也知道这个解决方案虽然对我来说运行得很好,但并不完美。
但我的主要目标是使其变得更好和可用,以便最终有一天或另一天适合生产应用!
在准备响应式设计以满足移动设备和平板电脑的需求时,这将使生活更轻松。
我希望它能做到,至少对你们中的一些人来说 :)
很棒的文章Dirk,用它来实验会很有趣。
我尝试过一种类似于Nick Williams描述的方法,我只需在
html
元素上设置字体大小并在不同的断点处缩放它。填充、边距和边框等内容的比例缩放方式确实是一件赏心悦目的事情。我传统上使用百分比来衡量我的容器,em
用于填充、边框和边距,以及rem
用于字体大小。作为一个实验,我将考虑使用百分比来表示容器,并使用
rem
来表示大多数其他内容。不过,我对 JavaScript 的使用仍然感到有点不安。太棒了!
以下是使用 FF20.0a2 在 Retina Macbook 上的控制台报告
[01:06:46.391] 布局:桌面
[01:06:46.392] 宽度:2470
[01:06:46.392] 比例 - 设备:1
[01:06:46.392] 比例 - 图像:1.5
[01:06:46.392] 比例 - 尺寸:1.2857142857142858
[01:06:46.392] 比例 - 总计:1.2857142857142858
[01:06:46.392] 比例 - 缩放:2
[01:06:46.392] 非常感谢你的帮助!
感谢你的报告,这帮助很大。问题是,正如预期的那样,FF18+ 的 window.devicePixelRatio 与任何其他浏览器不同,它包含浏览器缩放级别,并且此行为的临时“修复”在 devicePixelRatio 默认情况下大于 1 时会导致问题。
你是否介意再次打开http://www.qoopido.com/404/并打开 Firebug 控制台并发布结果?我更改了一些调试输出以检查是否有任何可能绕过 window.devicePixelRatio 的方法……
此致
迪尔克
这样做的好处是它将布局代码保留在 CSS 中,并且易于维护、调整或自定义不同断点的尺寸。
令人印象深刻!我可以完全地说移动图形正在朝着最好的方向发展。我还可以说 JavaScript 在此过程中发挥着非常重要的作用。感谢这篇文章!我绝对想了解更多关于响应式网页设计的知识。
如果正确理解概念和流程,网页设计过程并不难。尤其是在响应式设计(以及未来的上下文设计)方面。
这就是为什么这个行业能够持续发展的原因。像这样的新概念、想法和流程让每天的工作都充满乐趣。
感谢你们所有人的精彩评论和反馈!如上面评论中所述,我已经开始改进 REMux,使其在整体上更加通用,并使 JS 部分成为可选的(因此,如果需要,您仍然可以将其用于响应式图像)。
我目前的计划是将 REMux 移到它自己的 GitHub 存储库中,并完全发布我的 LESS 混合库以及新的 JS 部分(它很可能最多只有当前版本的一半大小)。
敬请关注并继续在此处发表评论,或者如果您愿意,直接联系我!
这是一种非常有趣的技术。我认为以这种方式工作可能会极大地提高那些不在浏览器中进行设计的人的工作流程,因为该网站对于大多数分辨率来说只是缩放。
我想我会在未来的项目中尝试类似的东西(可能只使用 CSS 解决方案)。
这太棒了!尽管尝试在没有 LESS 的情况下使用它并使用 em 代替 rem 会非常令人沮丧。我将不得不尝试 LESS,感谢“启发”和文章 :)
我认为有一天可以使用“CSS 设备适配”和新的 @viewport 规则来实现所有这些(假设桌面浏览器有一天会实现视口支持)。你可以这样做
这个想法是将大屏幕的视口固定在 980px。这应该会自动缩放所有内容。当然,你也可以对其他断点做类似的事情。
我应该在这里留下一个注释,说明 CSS 中的 vw/vh 单位与这些想法密切相关,并且在未来将是另一种非 JS 处理方式:https://css-tricks.cn/viewport-sized-typography/
我在实现此登陆页面时采用了类似的方法:http://educa.tive.pro 它主要使用图像和 div,但我也尝试了字体大小的概念(请参阅“即将推出……”div,无论如何字体大小不能真正成比例地缩放,因为它只有高度)
我的理念试图在您调整视口大小时保持黄金比例的div。
@Chris 是的,我认为CSS绝对需要与视口相关的单位,谢谢Chris,我一直在等待这个!所以我们现在可以编写一个JavaScript polyfill了!!太棒了!
这太棒了!我也在尝试做同样的事情。
嗯,有趣。在一月份开始了一个项目,采用了与Nick开始时几乎相同的方法。但我受到了wordpress twentytwelfe wordpress主题的影响。我使用rem类似于
默认字体大小 16px;
.class {
…
width: 10px;
width: .625rem;
…
}
宽度px作为回退,并通过html > font-size调整媒体查询。
干杯。
只是想让你们都知道
我一直在开发的REMux新版本现在已在我的网站上上线
http://www.qoopido.com
我将尽快调整关于REMux的文章以反映这些更改!
感谢您为此付出的所有努力。很棒的工作。
我们只需“将其放入”它就会“正常工作”以满足大多数用例,而不是人们发现的特定问题?
谢谢,Tom
已经在我的个人网站上使用的最新版本应该尽可能地像直接插入一样。而且它没有本文中提到的那个版本仍然存在的一些特定问题……
我将在接下来的几天内将新版本发布到其自己的GitHub存储库中,包括未压缩的源代码(当然)以及我使用的mixin文件……
这是一个令人印象深刻的解决方案!对于那些对无需任何编码的工具感兴趣的人,很乐意听到您对Froont的意见,我们正在开发一个响应式设计工具!我们正在向注册用户推出私人测试版,您可以在http://www.froont.com上注册,或直接向我索取邀请。
只是想让你们知道
我终于在GitHub上发布了REMux 2.0,并在我的网站上添加了一篇关于如何使用它的新文章
REMux 2.0:最大程度地减少
非常感谢您撰写这篇精彩的文章。这篇文章为我打开了思路。响应式设计的理念确实打动了我,我不得不在我最近的工作中尝试一下。我认为响应式网站设计可能会成为一种很好的方式,即使是小预算项目也可以逐步增强移动设备的功能。