我,在过去的一年左右时间里: “rem
太棒了!我将用它们来调整所有元素的大小,这样我就可以调整根元素的字体大小,并且所有内容都将随之缩放!” 这是一个美好的梦想。并且它并不是一场灾难。 这就是我现在在 CSS-Tricks 上所做的事情,以及它在一个非常简单的场景中是如何发挥作用的

这本质上源于
/* Document level adjustments */
html {
font-size: 17px;
}
@media (max-width: 900px) {
html { font-size: 15px; }
}
@media (max-width: 400px) {
html { font-size: 13px; }
}
/* Type will scale with document */
h1 {
font-size: 3rem;
}
h2 {
font-size: 2.5rem;
}
h3 {
font-size: 2rem;
}
我承认我喜欢这种简洁性,但我开始认为它对于除最简单的网站之外的所有网站来说都有些过于理想化了。主要问题:你不能期望你在一个屏幕尺寸上设置的字体类型,仅仅通过完全按比例缩放下就能看起来完美无缺。大型字体在放大时可能会变得太大。小型字体可能会变得太小(一个常见的让我困扰的问题)。或者甚至反过来,大型字体可能不会变得足够小。
如果出现任何这些情况,那么你就会进行 @media 查询的特定调整,这不仅会让人感到困惑,而且效率不高(调整大小只是为了再次调整它来修复它)。
所以这是我的想法:你仍然可以在文档级别保留 px
大小调整,以便你可以轻松/高效地进行全局大小更改。但是页面上的每个模块都使用 rem
设置字体大小。实际的文本元素(h1、h2、p、li 等),如果你调整它们的大小,则使用 em 调整大小,因此它们相对于模块而言。
这样,你就可以在模块级别调整字体大小,这非常容易。单个模块内的字体类型具有良好的比例并可以很好地一起缩放的可能性很高。所以它将像这样发挥作用
你可以通过调整滑块来体验这个想法
查看 CodePen 上 Chris Coyier (@chriscoyier) 的作品 Em AND Rem。
在某个中等大小下,一切看起来都很好。放大时,你可以达到文章主体变得足够大的程度,但侧边栏内容不需要那么大。使用此系统,可以轻松地定位它们并将它们缩小。缩小时,这些侧边栏模块会过快地变得太小,因此你可以轻松地将它们放大。甚至可能存在你使内容大小一致的情况,因为你已经转为单列(或类似情况)。
这就是它将如何进行
/* Document level adjustments */
html {
font-size: 17px;
}
@media (max-width: 900px) {
html { font-size: 15px; }
}
@media (max-width: 400px) {
html { font-size: 13px; }
}
/* Modules will scale with document */
.header {
font-size: 1.5rem;
}
.footer {
font-size: 0.75rem;
}
.sidebar {
font-size: 0.85rem;
}
/* Type will scale with modules */
h1 {
font-size: 3em;
}
h2 {
font-size: 2.5em;
}
h3 {
font-size: 2em;
}
我在标题中加入了“想法”,因为我还没有实际构建一个使用此方法的网站,但它对我来说很有意义,我肯定会尝试它。
嗯……好计划。实际上我刚刚使用了 em 和百分比——没有像素(除非涉及边框)也没有 rem。这听起来更好。
绝对值得注意的是 rem 的浏览器支持。如果你需要支持 IE8 及更低版本,则根本无法考虑此想法。
它可以通过 rem 的 px 回退来实现。你只需要在你的 @media 声明中包含模块的 rem/px 回退。
给自己留一点空间,以便在不再需要支持 IE8 时可以移除它们,并且你今天就可以使用它。
幸运的是,XP 今天死了
@Legomushroom 这意味着什么,我们仍然需要支持那些用户。
当然我们支持,但这很快就会改变
我们是不是该停止支持 IE8 了?现在是 2014 年了。
是的,我们当然都可以停止使用 IE8,但太多其他人会继续使用它。如果你安装 Windows 7,甚至不是 XP,你最终可能会得到 IE 8 的普通版本,甚至可能是 IE 7,具体取决于你拥有的安装版本。还没有脱离困境 :)
我为一家公司工作,其客户是大型招聘公司,而这些公司本身又依赖于大型 IT 部门来处理所有技术支持。当进入这种规模的环境时,升级极其困难、耗时,最重要的是成本效益低。因此,我们一直支持 IE8 直到上个月。
一些政府机构仍在使用 IE6。想想看。
顺便说一句,英国政府刚刚花费了 550 万英镑来获得 XP 的扩展支持
http://ccs.cabinetoffice.gov.uk/i-am-buyer/categories/ict/special-agreements/custom-support
针对功能而非浏览器。一切都可以通过正确的回退来考虑。不要低估你能做的事情。规划未来,同时关注过去。
嗯。这听起来很有希望,我一直都在努力解决同样的问题。
我遇到的问题是,就像你说的,当你缩小时,大型文本不会变得足够小——我不确定这是否能解决这个问题。尽管我认为我只是偷懒了,只需要一个简单的标题 mq 调整就可以改变这个比例。
但在我的梦里,一切就像调整一个数字一样简单。
我非常喜欢这个想法。任何处理过模块化“小部件”的人都能看到它的好处。
结合在上下文中(侧边栏、主体)以不同方式设置模块样式的功能,它极大地减少了对重复 css 的需求。
谢谢,Chris!期待采用类似的方法。
我肯定会在我的下一个完整网站上尝试它。那位客户自己承认他是一个字体迷,所以他是完美的试验对象。
使用绝对单位在文档级别设置字体大小会覆盖用户的浏览器设置,因此可以肯定地说这是一种不好的做法。
相反,使用相对单位,例如:
html { font-size: 100%; }
。我同意 Tim 的观点,不要动 html。这是该观点的来源: http://filamentgroup.com/lab/how_we_learned_to_leave_body_font_size_alone/
他们还提到/链接了为什么你应该在媒体查询中使用 EM: http://blog.cloudfour.com/the-ems-have-it-proportional-media-queries-ftw/
那里最大的因素是,当浏览器缩放时,px 媒体查询不起作用,但 em 起作用,这现在已经不再是问题了。出于这个原因,我将所有媒体查询都切换到 em,这很好,但我认为总的来说,我更喜欢在那里使用 px。
Chris,停止使用 px 需要一些时间。这是从基于像素的整个设计,到相对于基本字体大小的整个设计的转变。
这是从绝对到相对的转变。与从 Photoshop 到 Illustrator 的转变相同。
+1,停止使用像素,这不好 :)。
它也可能对旧版 IE 造成可访问性问题,但主要问题是——正如 Tim 所说——它会覆盖用户默认值。尊重用户,使用百分比,或者什么也不使用 :)
@Nico
这些更改默认字体值的用户是谁?
我认识一些法律意义上的盲人。其中一人放大了整个屏幕(OS X ctrl + 鼠标滚轮)。其余的人使用 ctrl-+,它会放大所有内容,而不仅仅是字体。
是否有人对此有实际的统计数据?
在根元素使用 %——相同概念。
如果概念相同,请不要建议在根元素使用绝对单位,例如像素。
基本上,你是在建议开发人员破坏那些没有发现缩放选项的视力不好的人。
如果你不愿意更改它,至少在文章中提及百分比的好处。拜托。
我不同意这一点。是的,考虑用户的设置显然很好。但正确的答案要复杂得多。为什么?因为
可以安全地假设用户会增加文本大小,以便能够阅读 10px 的正文。但是,如果您的网站设置为 20px,则无法判断用户是否真的想要增加文本大小。
我真的很喜欢这个想法。我认为随着浏览器支持范围的扩大,这将是未来的发展方向。感谢您的见解。
一旦 rem 可用,我认为除了边框或分隔符之外,使用 px 用于任何其他用途都是错误的。它不应该再用于字体了。我的理由
Rem 使处理以下两者成为可能:浏览器缩放和用户字体大小设置。
– 使用缩放,我们希望使所有内容都更大。
– 使用字体大小更改,我们只希望字体更大。
使仅字体变大意味着布局不会变宽或变窄。
当更改字体大小设置时,所有“em”大小的内容都会更改,但 rem 不会更改。
据此,我制定了以下基本策略
– em 用于字体和任何与字体相关的元素。
– rem 用于宽度。所有在用户字体大小更改时不应更改的内容。因此,通常是布局宽度、列宽和块宽。通常,我们希望容器向下扩展,但不要变大。
-px 几乎被禁止,仅用于边框,因为我们通常希望这些边框的数值为整数。
超级简单的策略,在我的 IE9+ 浏览器上运行良好。
它还为以编程方式操作字体大小打开了大门。
是的,没错!
我已经这样做了大约 3 年了,除了我仅使用 em,因为当时 rem 还没有成为选项。边框、文本阴影和通常所有 1、2 像素的元素以及 border-radius 也使用像素。好吧,可以在 border-radius 上使用 em,但最好不要。
我最近一直在思考同样的事情!
使用 rem 来设置所有内容似乎是一个天才的想法,直到我开始在大规模网站上使用它们。使用 em,我可以只调整模块的父容器,其余的块会相应地调整大小。但是使用 rem,我必须为每个嵌套对象覆盖 rem。它基本上克服了 rem 的所有好处。
我肯定会在我的下一个项目中尝试这种新方法,因为它结合了我喜欢的 rem(仅依赖于根字体大小)和 em(更易于缩放)的所有优点。
有趣的想法——到目前为止,我一直避免使用 rem,更喜欢百分比和 em。不过我喜欢这个概念,我想我会在我的下一个网站上尝试一下。
谢谢 Chris!
很棒的想法。我切换到使用
rem
进行所有字体大小和间距的设置,但一直难以处理可扩展性。通过使用em
设置实际的font-size
,容器/模块可以真正确定大小,同时保持与rem
一致的间距。A+ 的想法。这真是太棒了!现在我需要去尝试一下。谢谢 Chris!
在我的当前项目网站上尝试了这种方法,并在我的当前设置中遇到了一些小问题。使用 LESS,我有一些用于字体大小的主要变量。
将 1rem 设置为 10px 可以轻松计算字体大小或边距/填充(基于 黄金分割和 REMS 的方法)
但是,当我切换到使用
em
进行font-size
和rem
进行margin
/padding
时,我需要进行一些修改。这使我能够回退到使用
@font-size-body
变量的固定大小,例如在使用 内联块网格 并将字体大小设置为 0.1px 以删除间距时,同时仍然允许轻松缩放模块或媒体查询的字体大小。只是好奇:为什么是
html {17px}
而不是16px
?我个人不太热衷于覆盖用户浏览器设置的默认字体大小。我想大多数用户甚至都不会更改此设置。因此,将其保留为
font-size: 100%
是我们能做的最好的事情。将
px
、rem
和em
结合起来设置字体大小的想法对于初学者来说可能有点难以理解。因此,作为替代方案,我仅使用em
来设置字体大小,这意味着我们可以通过简单地更改html
元素的font-size
来调整文本大小。以下是操作方法:
就是这样!通过简单地更改
html
元素中font-size
的百分比,我们可以根据媒体查询放大或缩小文本。垂直节奏和 Compass 等工具怎么样?如今我确实只使用 Compass 来处理这些问题(使用 gulp 来添加前缀)。如何使其可用?
关于 CSS-Tricks 的重新设计,为什么您要为小屏幕/移动设备减小字体大小?将其放大/更容易阅读不是更有意义吗?
我最初的想法也是一样,但这并没有考虑到移动设备通常比传统计算机更靠近用户的事实。http://ia.net/blog/responsive-typography-the-basics/
好主意。我想您还需要考虑垂直间距,例如边距和填充。在不使用“em”来设置这些属性的情况下增加模块的字体大小可能会导致一些有趣的结果。
到目前为止,我一直在使用百分比来放大或缩小字体大小。这种方法看起来很有趣。我会尝试一下。
在梦幻岛,EM 或 REM 用于所有内容!
对于 EM 的情况,我认为将字体大小应用于文本元素的父元素不是一个好主意。
有一天,我们应该考虑全面使用 EM/REM 进行设计。
1) 不要从用户那里夺走字体大小的控制权。许多残疾人会在 UA 中设置自己的基本字体大小。
2) 话虽如此,设计师们自古以来就一直在从用户那里夺取控制权。尽管如此,现在开始也为时不晚。
3) 我一直不明白 REM 的必要性。您在这里提出的建议可以用 EM 同样轻松地实现。
据我了解,rem 只是使计算更容易。如果我没记错的话,rem 始终基于 HTML 大小,因此无论您嵌套多少个元素,它的行为都相同且可预测。将其视为声明 em 用于其计算基础的范围。而嵌套 em 随着您嵌套越来越多的元素,可能会产生难以控制的后果。
在简单的网站中,这是一个无关紧要的问题,但在由很多人管理的一些更复杂的网站中,em 会变成一个真正的难题。
Rem 不受用户字体大小设置更改的影响。(并且没有复合)
这就是为什么我强烈建议将其用于所有宽度的原因。这样,用户可以请求更大的字体大小,而不会使网站变大。这样,字体更大,但没有水平滚动条。
@olivvv:也许我误解了您的意思,但
rem
确实会受到用户字体大小设置更改的影响,就像em
一样。这就是它们有用的原因。用户可以更改他们的字体大小,元素会相应地放大或缩小。这样,您就不会出现列太窄或太宽的情况,就像基于px
的布局一样。最重要的一点是,基于
rem
的布局也始终使用基于rem
或em
的媒体查询。Forrest Galloway 在下面的评论中提供了相关信息——当用户放大字体大小(或缩放设置)时,他们会获得平板电脑版本,然后是移动版本,这可能无论如何都是更好的用户体验。稍微偏离主题,但如果您要放大和缩小字体大小,您可能还想调整字母间距。
大字体可以——而且通常会——通过在字母之间留出较少的空格来显得更漂亮。它还可以提高可读性。
使用相对单位获得良好的效果,使用字体自闭症亚像素疯狂获得极佳的效果。
太棒了!喜欢它。
我们在最近重新设计http://www.nationalguard.com时使用了类似于这篇文章的技术。我们有一些PX声明,但大多数是EMs,它们非常适合模块和布局(用于缩放下述模块)!为了使网站具有响应性,我们使用了fittext的独立版本并将其仅附加到html元素上。字体大小级联效果非常好。
如果JS关闭,则在html元素上使用基于PX的字体大小,并在body上使用固定宽度。可以使用Sass mixin和MQ来模拟fittext的行为,不确定是否建议这样做,这将需要很多行的CSS。
它对辅助功能有一个有趣的益处/副作用,在浏览器中增加字体大小最终会显示带有大文本的移动体验,我们认为这比仅仅是一个放大的桌面体验更好。
我同意在断点处更改根em大小,但我仍然没有看到使用ems或rems调整组件大小的任何好处,对我来说是
Rems用于文本
Ems用于与该rem相关的元素(例如,按钮上的填充应相对于按钮的文本大小),以及基于文本的元素的边距
%用于布局
%或PX用于布局元素的间距/边距 - 例如,列之间的间距与<p>的大小无关
<
p>
这是我在我的网站上使用的一种方法
为:root设置一个基本视口单位(vw)字体大小,然后通过百分比更改所有其他大小,以下是一个示例
https://github.com/sparanoid/sparanoid.com/blob/master/_app/assets/less/app.less#L2
嗨,Chris - 我真的很喜欢这种紧凑的模块化方法,但我认为有一些非常重要的事情需要考虑
1) 用于媒体查询的EMs更可靠,因为某些浏览器/硬件组合(我听说三星触摸屏笔记本电脑就是其中之一)开始报告其高分辨率屏幕的实际分辨率 - 基于em的布局效果很好,但基于px的布局突然变成了邮票大小。我认为这种情况随着时间的推移只会越来越频繁,因此,鉴于两者之间相当容易的切换,可能值得继续使用EMs用于MQ。
2) Filament Group关于将正文文本保留为1EM是正确的。他们(设备/操作系统供应商)投入了大量精力来确定在他们的特定设备上什么是合适的可读大小,如果您将其保留为1EM,它将始终有效。
3) 在各处模块中对相对大小进行判断可能会导致设计体验真正碎片化。当相对大小差异很大时,用户理解哪个元素比另一个元素更重要的速度会减慢,因为这种层次结构没有得到维护。
并不是说模块化代码方法不聪明 - 但我认为考虑设计的整体性和凝聚力而不是专注于调整每个模块非常重要。当然,从编码的角度来看,我完全会采用这种方法,以使所有CSS模块更易于移植和“SMACSSy” - 但作为设计师,我只是想更多地考虑更改了多少内容以及在哪里更改。
好的。关于REMs与EMs的另一件事。我从未采用REMs,部分原因是IE8-(以及我用于RWD研讨会的所有示例代码都支持到IE6),但如果您确保不将字体大小更改应用于容器 - 仅应用于元素本身,则对REMs的需求就会大大减少。这样,您始终在根据基本HTML字体大小进行计算 - 并且您可以通过这种方式获得很多相同的整体灵活性来更改基准并使其产生连锁反应。
我们实际上在一个大型响应式项目中使用了类似的系统。首先,我们使用BEM类命名严格地将页面上所有UI组件模块化。然后,我们区分了对应于页面部分的模块和较小的模块。页面部分允许使用REM覆盖其字体大小。较小的模块(如按钮、表单元素、标题等)始终使用EMs进行大小调整。这样,我们就可以以非常灵活的方式在不同尺寸下使用小模块。大小调整通过页面部分模块及其REM基本字体大小进行控制。
最终结果是一个高度灵活且模块化的UI组件系统。
我喜欢
rem
单位,因为它们使数学更容易。那么,为什么不将根元素的
font-size
设置为10px
?这样1rem
=10px
,1.2rem
=12px
,等等。此外,我认为使用
px
单位覆盖用户的浏览器设置在社区中是不被认可的。这种理念改变了吗?或者,如果不关心简单的数学运算,为什么不直接使用
rem
单位设置根元素的font-size
并允许用户保持控制?我一直在我的公司的大型企业应用程序中使用此过程与原子设计一起使用。它很棒,因为您可以为模块定义一个Sass或LESS部分(在原子设计中,它们被称为分子或原子),默认为font-size: 1rem,然后在页面级别,我可以将其覆盖为font-size: 1.2rem,等等。
这样我就可以根据其上下文缩放应用程序中的小部件。
模块的字体大小使用
rem
,页面网格框架也使用rem
。我使用Susy,它以这种方式原生使用rems。它们非常适合网格框架,因为您希望确保整个页面上的列和间距保持一致,无论它们位于哪个模块中。我想重申thinsoldier的问题
“这些更改默认字体值的使用者是谁?
是否有人对此有实际的统计数据?”
是否可以从用户的UA中嗅探出默认字体大小?如果是,是否有任何可用的统计数据,如果有,在哪里可以找到它们?
谢谢
您对设置基本字体为px,其余字体为百分比有什么看法?
我同意你的观点 :-)
喜欢用于增加字体大小的滑块演示
使用百分比 +/- 100% 简单得多 - 在任何地方都能工作;这样你就不必担心rem和em的麻烦了!不要让我开始谈论跨平台兼容性。
就这么简单……
使用%和em的排版是一样的 - 它仍然会影响级联,因为300%的100%仍然是300%。同样,3em处的1em仍然是3em。
自己看看
http://codepen.io/basement31/pen/oyJFf/
关于CodePen演示的一个小技巧:如果您将回调绑定到“input”事件,则在您上下拖动范围时,字体大小会更新。超级酷。
我在Kendo UI Mobile中使用了类似的技术相当长一段时间。但是,我们需要组件可调整大小,并且主要基于em。
使用ems和rems以及根元素上的字体大小也是模拟Windows Phone 8中缺少的比例1自动调整大小的唯一方法,其中没有可用的devicePixelRatio(WP8.1有devicePixelRatio,但仍然没有进行自动调整大小)。
我认为这是一个好主意,但我只是想知道为什么您不使用磅值(pt)作为文本。这对于打印页面不是更好吗?
嘿,Chris,我们实际上已经在HTML5视频播放器中使用了这项技术两年了。在这种情况下,根调整是通过JS完成的,因为我们希望播放器能够缩放至窗口。我们决定对根使用px,对其他所有内容使用ems,但当然也可以使用rems来完成相同的事情。
这个项目的优点是,我们不必关心旧的浏览器,这些浏览器使用奇怪的旧的step-oncle(Flash)。
结果如下:http://www.heliview.de/?uid=Q5ZPL5
但是,(r)ems有一个主要问题:FF/Chrome/IE/Safari倾向于使用他们自己的算法来舍入值,这会导致计算中出现细微但可见的差异,并且您无法为边框等定义最小值。这就是为什么我们决定对这些使用px值……并在用户放大或缩小(仅限桌面)时遇到下一个问题。在现代浏览器中,px值实际上会放大。
所以……亲爱的CSS-WG/W3C:我们喜欢您为这个地方所做的事情,但那个房间仍然需要重新粉刷……
@Tim Severien和%与px:这确实取决于用例!如果您需要完全控制,则需要使用像素。对于网站:是的,你是对的 - 但对于应用程序,情况就不同了。
我喜欢这个想法。但同时,在当今时代教学生关于字体和单位的内容让我有点不自在。当我教新的网页设计学生关于 px、%、em 和 rem 时,他们有时会感到困惑。想象一下,向一个网页领域的新手解释如何在 html 中使用 62.5%、在模块中使用 rem、在元素中使用 em,以及在其他一些地方使用 px:)。不过,感谢你的提示,我喜欢它!
@Paul d’Aoust
是的,你是对的,我在测试中弄错了某些东西,从那以后说得太多了。
然后我想要实现的目标可以使用以 px 为单位设置的宽度。
在这种情况下,当 em 已经可用时,我并不认为 rem 真的有什么意义。我看到的唯一区别是 rem 没有复合。我要重新做测试,停止胡说八道。
@olivvv 呵呵,不用担心;我想我“在测试中弄错了某些东西,说得太多”这种情况每天都会发生几次(大多是跟同事说话的时候)。但是的,你是对的——
rem
很棒,因为像px
一样,它们不会复合,但像em
一样,它们相对于某个地方的字体大小(在本例中是根元素的字体大小)。现在,如果我能真正使用
rem
就好了……我们仍然看到 9% 的 IE8 用户,在我们将其支持率降至约 2-3% 之前,放弃对该浏览器的支持是不负责任的。唉。我完全是个新手,但我想在我的下一个网站上尝试一下……因为,为什么不呢。不过我很好奇……我们能否将它与黄金分割结合起来,使其在易于回退并解决上面关于 px 与 % 与 em 文档级别设置的争论(我对此完全不了解)的同时起作用?
所以,我可以将字体大小设置为 62.5%,并保留模块的回退值吗?对于文本来说……我想我仍然需要将内容分割出来……但至少我只需要除以 1.6rem/16px 到 em,并且我知道 1em 等于 16px,对吧?
我在新项目中使用 em 已经很多年了,在我进入一家代理机构的第一份工作时就被教导这样做。rem 的想法很棒,因为它们以文档为基础,但浏览器支持不足以让我们在所有项目中使用它们,请参阅 caniuse 网站:https://caniuse.cn/#feat=rem
我总是被教导使用 font-size:62.5% 的技巧,使 em 尽可能接近上面评论中提到的相关 px 尺寸,例如 1.6em = 16px,2.0em = 20px 等等。
为什么不使用
:root
伪类来设置根元素的字体大小呢?有趣的文章。
我保存了图形并注意到它是一个 SVG 图形。我创建了本教程的一个示例模式并嵌入了 SVG,然后我注意到它没有响应。
我打开了 SVG 并更改了标题,如下所示
嗯……无法弄清楚这个代码界面。需要更清晰的用户体验指南。
很棒的想法,Chris。我正在当前项目中实施它,效果很好 :)
这很酷,但我认为你的想法可以用这个技巧做得更好
在根元素中使用 %,例如:
html{font-size:62.5%;}
,rem
(使用技巧)用于组件,例如:.article{font-size:20px; font-size:2rem;}
以及用于文本元素的
em
,就像你的示例一样唯一的问题是,默认情况下,所有内容都相当于 font-size: 10px。
由于浏览器支持问题,我仍然对
rem
说不。但我认为从根元素一直使用em
是可以的。我有一件事不明白……为什么你要在较小的屏幕上缩小文本,而不是放大它?
Jos –
我同意。我发现通常最好将正文内容保留在“1em”(或 100%)上,以便设备/操作系统可以指定它想要的内容,因为它通常会在任何设备上呈现良好并具有良好的可读性,无论尺寸或分辨率如何。唯一的例外是某些字体倾向于呈现得有点小(如 Garamond),因此无论如何我都会在所有屏幕上稍微放大一点。
我认为需要缩小的是相对于正文内容大小的标题。如果您按比例缩小标题大小以适应屏幕尺寸,则会显得不那么笨拙,并且仍然非常清晰。我在 Typecast 上写了一篇关于此的文章:Typecast 博客文章