14 ms·

> Specify it in pixels No thank you. I regularly wonder if it might not be better for the web if we got rid of pixels as a unit entirely. We can't realistical

> Specify it in pixels No thank you. I regularly wonder if it might not be better for the web if we got rid of pixels as a unit entirely. We can't realistically do that for a lot of reasons, and there are legitimate reasons to use pixels sometimes, but resolution independent font-size and container sizing should be the default. If you are using pixels on the web for font sizes, consider this a public intervention that you need to stop. The fact that `em` units are not related to physical size attributes is intended. We don't want them to be related to physical size -- what `2em` is saying is that you want a piece of text to be twice as large as the "default" size of the specific font on the platform/device. That is a superior way to think about text size, because as a user I don't want you to try and figure out what the pixel density or screen ratio or resolution of my device is. Size your fonts with `em` and `rem` units, and size your containers based on the number of characters you want to fit in each line. Don't use pixels. It doesn't matter if your fonts are bigger on Mac or Windows. It is intentional that platforms can size their fonts differently, and your interface designs should take that into account. If anything, native platforms should be moving more in this direction, they should not be moving away from it. There was a period where you could decide to only care about responsive design on the web, but increasingly you should be thinking about responsive design on native platforms too. And resolution-independent font-sizes based on the user/platform are part of that process. EDIT: Yes, I'm aware that pixels on the web are not necessarily 1:1 ratios with physical pixels on a screen. That doesn't change anything, pixels are still bad to use on the web. Tying font size to resolution, whether that's browser window resolution or physical resolution, is still equally problematic. And it certainly doesn't mean that we should move in the opposite direction on native devices -- the web's pixels are the way they are because the alternative, being tied to literal physical pixels, would be even worse.

deleted 6y ago
[deleted]
jancsika 6y ago
Essentially, you've made svg text a special case. So diagram-based languages and frankly any graph-drawing framework that let you specify text labels go out the window. I think svg `<glyph>` was meant to be the answer to this question, but that was an answer for people who don't care about readability. So now it is rightly deprecated. Unfortunately, that leaves essentially no answer except guessing and checking with pixel-sized fonts to make sure font-rendering-stack development troglodytes haven't screwed up my diagrams. So don't touch my pixel sizes, bro.
- jancsika 6y ago
  In fact, I think I'm underselling it. Because I think the gaming industry essentially says, "fuck it," to this same problem and simply uses images for the text. Am I right, gaming industry?
  - danShumway 6y ago
    The gaming industry isn't doing responsive design. For multiple reasons, some legitimate and some not, but the point is that I would consider them to be a separate category. Most games on the web are going to be using Canvas I suspect -- in my experience at least, they usually won't be rendering to the DOM or using CSS at all.
- danShumway 6y ago
  > Essentially, you've made svg text a special case. So diagram-based languages and frankly any graph-drawing framework that let you specify text labels go out the window. Hear me out on this: a graphics format that is specifically designed to scale losslessly as it's biggest selling point, should have support for scaling `em` units. It's absurd that building responsive SVGs is currently harder than building responsive web pages. Instead it's got some kind of messed up, obtuse system where we either do viewport scaling and break all of our line-widths, or do percentage-based scaling and break all of our custom paths.
  - runarberg 6y ago
    You can use `<foreignObject>`[1] in your SVGs to wrap text inside a nice HTML rendering (with word wrapping and other superpowers). However I’ve found that there is always some issues (e.g. I need the graph to shrink in the inline direction when text is longer then X; or this rect should flow lower when I have multiple lines). I’ve never actually found my self using <foreignObject> in the SVG diagrams I write, and usually just listen to a resize event and manipulate everything that way (shrug). 1: https://developer.mozilla.org/en-US/docs/Web/SVG/Element/foreignObject https://developer.mozilla.org/en-US/docs/Web/SVG/Element/for...
  - jancsika 6y ago
jstimpfle 6y ago
> Size your fonts with `em` and `rem` units, and size your containers based on the number of characters you want to fit in each line. AFAIK this is not a good solution in most situations. The number of characters that you can fit on a fixed container varies greatly depending on platform / font / settings. By consequence, you'd lose a whole lot of control over you layout if you were to scale the containers in this way.
- danShumway 6y ago
  I realize this is going to come off as dismissive, but don't use fixed container widths. Responsive design is a paradigm shift away from perfect pixel-level control over every container size on a static-width document. It's not print design, it's a different medium. Stop making fixed layouts that break whenever I snap a window at half-width to the side of my screen; there are legitimate reasons why someone on a computer might want their fonts to be bigger or smaller, and your column widths should adjust to accommodate that.
  - deleted 6y ago
    [deleted]
  - ryanar 6y ago
    Agreed! This idea is presented really well in https://everylayout.dev https://everylayout.dev
    - vlz 6y ago
      https://every-layout.dev https://every-layout.dev But thanks for the reminder! I meant to have a look at that.
  - deleted 6y ago
    [deleted]
akersten 6y ago
Absolutely agreed. The article laments things like "I have no good way of knowing how big my text is going to be when I say 16pt," and my response is "why would you ever need to know that? Do your containing elements not reasonably resize when their inner content gets bigger? How are you handling internationalization where strings will certainly be longer?" It's ok for apps to look different on different platforms. We need to stop trying to design things pixel-perfect to the mockups - I thought we could have left that trend behind in the early 2000's. OS font rendering can even provide info about the physical dimensions of the screen and give you an "actual size" unit you can use to match your screen to real world paper. So a lot of this article, to me, reads as a misunderstanding of why fonts render the way they do.
- thomasfromcdnjs 6y ago
  I like this opinion but not sure if it translates well to building apps in the real world. A lot of work goes into UX research and A/B testing, if fonts are too flexible none of your results will be meaningful.
  - akersten 6y ago
    I would posit that if rendering differences in font display are affecting A/B testing a workflow, the A/B testing apparatus has failed to control for confounding factors and was probably invalid anyway. If OSX is known to render differently than Windows (and it's not just fonts), why are you comparing cohort A from Windows to cohort B from OSX? That is an analysis error.
  - danShumway 6y ago
    Any kind of user customization will have the same effect. Any preference that the user can edit can be a confounding variable in an A/B test. I don't want to live in a software world where as a user I'm forced into a one-size-fits-all approach to every interface just because it makes A/B testing easier.
- egwor 6y ago
  If I have two monitors with two resolutions and I put the two screens together the text is a different size. When I'm reading the text I want it to be consistent as I move it across screens. With this approach will the text be the same size? The main issue I have as I get older is that as the resolution increases the text size seems to get smaller
CharlesW 6y ago
> …there are legitimate reasons to use pixels sometimes, but resolution independent font-size and container sizing should be the default. Web pixels are different than device pixels, and are resolution independent.
- kevincox 6y ago
  The are independent of the screen but also of the user preferences. Using rem or relative sizes bases your sizing off of the user's selected font size. As soon as you size something in px you have just thrown away the user's font size choice.
  - charrondev 6y ago
    This doesn’t seem accurate. Items sized in pixels will get increased with CTRL + “+”.
    - kevincox 6y ago
      I believe that that zoom is handled differently from default font size.
    - pwdisswordfish0 6y ago
      Ctrl++ is only necessary because you've "thrown away the user's font size choice". As a user, I have my font preferences set to what I want to read. If you maintain main body text size = 1em, then those preferences are respected. If you start arbitrarily specifying font size in px (whether CSS px or physical px), then you destroy that. This can still happen with 1em, too, by opting for a font whose em box is screwed up, as described in the article, but that's the _easiest_ thing to test for, because it will be apparent on all screens (including the designer's).
- danShumway 6y ago
  Yes, correct, I should have been more specific. The resolution of the webpage as reported by the webpage, even if it doesn't line up with the literal number of pixels in a screen, should not be used for font sizing in most scenarios.
djrenren 6y ago
Hey just a heads up, on the web (or at least in CSS) px is resolution independent. It represents 1/96th of an inch [1]. The web has physical, font-relative, and viewport-relative lengths which all serve slightly different purposes. Like you, I find font-relative to be super useful much of the time, but the others have their place as well. I just want to point out that CSS specifically doesn't have a resolution-dependent measurement. Using pixel (1/96 in) sizes for a font is fine if you care about the physical size of the font being displayed. Starting from the system default font-size as you suggest will also work, but you'll need to test it on all the platforms (especially if you use a custom font). [1]: https://www.w3.org/TR/css-values-4/#absolute-lengths https://www.w3.org/TR/css-values-4/#absolute-lengths
- danShumway 6y ago
  Yes, completely correct, and it's good that you pointed that out. However, you also shouldn't be sizing fonts based on 1/96th of an inch units. That will also break responsive design in many cases. Not all of them, like you said there are legitimate use-cases, but most of the time you should not be trying to make a font be a specific physical size.
crazygringo 6y ago
I'm sorry, but you seem to be under some misconceptions about how pixel sizing works on the web. > resolution independent font-size and container sizing should be the default It already is. CSS "px" doesn't refer to physical pixels at all, they're called logical pixels. Which on old screens at 100% zoom may map 1:1, but these days are more likely to map 2:1 or even 3:1, and with OS and browser zoom levels may be things like 1.666:1 or 2.5:1. > Size your fonts with `em` and `rem` units In the browser, em/rem are necessarily defined by a parent/root element that is ultimately defined in either px or pt, so your suggestion doesn't achieve what you think it achieves. Today, whether you write your CSS in "em" or "px" results in an identical user experience. It's really just whether you prefer to work with a baseline of something like "16px" and use larger round integers (8px, 1000px, etc.) or prefer to work with something like a baseline of "1em" and use small numbers with lots of decimals (0.5rem, 30rem, 0.05rem). Ultimately we need some measure of consistency, and browsers have long defined that as a default legible body text size of 16 px = 12 pt (= 1 em by default).
- jan_Inkepa 6y ago
  > It already is. CSS "px" doesn't refer to physical pixels at all, they're called logical pixels. Which on old screens at 100% zoom may map 1:1, but these days are more likely to map 2:1 or even 3:1, and with OS and browser zoom levels may be things like 1.666:1 or 2.5:1. Yeah it's a nightmare if you're doing pixel-art-y games in the browsers, there's last time I checked no way in general to get access to physical pixels anymore, which makes integer-multiple upscaling AFAIK impossible in general. Hurrah. [ disclaimer: The browser rendering stack is complicated enough that I might be wrong. ]
  - wffurr 6y ago
    CSS px * devicePixelRatio = physical pixels I feel your pain about non-integer scaling ratios. The way I hack around it is to set the canvas context to an integer number of device pixels, and then set the CSS size of the canvas to a fractional size: device pixels / DPR. We use this along with some other hacks on keep.google.com and some other sites to map 1:1 to display pixels to try to ensure hardware overlay promotion for the inking surface.
amelius 6y ago
> > Specify it in pixels > No thank you. The article is NOT about px versus em or pt. It is about specifying sizes in a way that makes sense, i.e. based on visible quantities rather than abstract quantities that are difficult to understand.
- sings 6y ago
  Agreed, this definitely goes off on a tangent. The article is mostly about switching two fonts with the expectation that the visual size of the characters remains consistent. That expectation fails because the em size is arbitrary with respect to the visible caps-height. As it stands, fonts can have drastically different rendered sizes at the same specified font size. This leads to all sorts of problems, like ensuring fallback fonts have similar metrics to the one you expect to load.
  - dragonwriter 6y ago
    > The article is mostly about switching two fonts with the expectation that the visual size of the characters remains consistent. That expectation fails because the em size is arbitrary with respect to the visible caps-height. It would fail with caps-height, too, as other visible measures of characters (not just abstract ones like em) have no guaranteed consistent relationship to caps-height, so, as such, there's no guarantee that fonts with the same caps-height have the same “visual size”, or even visual vertical size, since cap height doesn't i close descender and ascender height.
    - amelius 6y ago
      Perhaps we should have a "median-height" property, for specifying the median height of the actual glyphs in the text.
- setr 6y ago
  It’s not just difficult to understand, the em height / character shape described by the article are total nonsense — they have zero relationship to the font itself, and no relationship between one font’s eg height and another. Which ultimately means that font sizing is entirely nonsense: the only thing you can say is font size 1 is smaller than font size 2, but it’s impossible to say by how much, or guess the difference, except when talking about one, and only one font. That is, a font with size 16 roughly corresponding to the same size in another font is entirely defined and enforced by nothing at all — it’s purely a “happens to be true”. Thus, the only real way to handle font sizing predictably is to never switch them out, because you’re really dealing with undefined behavior
samatman 6y ago
The main point of the article, as I see it, is that the "em" used in fonts isn't the intuitively correct em size. It's just a control box used by the font developer, and the result is that designers can't get a consistent font size. They can know, more or less, what something is going to look like given the font they want to load, but the fallback font might have a different concept of em size and look more different than it would need to be. So having a different metric, which is exactly capital height, makes fonts look more similarly-sized to each other at the same capital-height resolution, which he demonstrates in the article. This seems valuable to me.
joshuak 6y ago
I strongly disagree with this general philosophy. One should be able to use an absolute, non-relativistic unit of measure that requires no external knowledge at all. Not even to other parts of the same layout. Relativistic units are inadequate if they are free to cause non-pixel perfect transformations of designers intent from platform to platform. It is no more reasonable to re-layout a carefully designed UI then it is to reposition objects and people in a movie scene played on devices of different resolution, in fact it is much less reasonable. Perhaps, in some circumstances this will call for platform specific design, and that is correct and appropriate. Perhaps a UI will look like a postage stamp on a high pixel density display. Adjusting for that difference is the domain of the operating system and the user. Even the OS may be unaware of the actual physical size of the display, for example when using a projector. Automatic layout is a convenance, but it works against not for good design.
- nemetroid 6y ago
  Pixel-perfect design should not be a goal for the web if it means compromising usability.
  - joshuak 6y ago
    It doesn't mean compromised useably, it is a guarantee of usability. Dynamic layout, re-flow and responsive design compromise usability. The utility of responsive design is not improved usability, its improved designer productivity at the cost of usability.
- tracker1 6y ago
  If you have two fonts at size X, they should both display the same number of lines in Y space... The problem is the relativistic measure isn't even consistent between fonts.
- danShumway 6y ago
  > It is no more reasonable to re-layout a carefully designed UI then it is to reposition objects and people in a movie scene played on devices of different resolution Is this unreasonable? We don't have the ability to design this kind of responsive control over video streams, but we do have the ability to speed up and slow down videos, embed captions that use native device fonts rather than bake themselves into the video file, adjust contrast and brightness, skip over segments and timestamps, and to adjust audio balance. And many players also have the ability to zoom in and cut off black bars. None of that seems like a problem? I'm regularly thankful for the ability to auto-skip intros and adjust playback speed. Every single video player should have the ability to play at 1.5x speed. I think in general it's important to separate practical design from art. I don't think any user has any obligation to worry about whether or not it's "reasonable" for to adjust an interface in whatever way works best for them. The goal of design is to make it easier to accomplish a task; the designers individual vision doesn't take precedent over that. > Adjusting for that difference is the domain of the operating system and the user. That's exactly why we have semantic units that are tied to a specific meaning/purpose, not ones that just represent abstract concepts like pixel width. The purpose of an `em` unit for widths is to describe the design of a column based on its intended use -- to show X characters in a line. The more specific we are about not just the width of an element, but also the intent behind that width, the easier it is for an OS and a user to adjust for size differences in specific scenarios. If I drop a page to 300 pixels, did I do that because I want the font to be bigger? Am I scaling the entire window down including the font? Do I want the same design and font-size in a single column? Semantic units allow me as a user to communicate the context a page is in, which allows the page to respond to that context. Absolutist design is anti-customization; it imposes the designer's will over the user's will. This matters because even in a single device/platform, it can often be impossible to design a single interface that always works. I use i3wm, so when I open a program it opens in tiled mode. You might get half of the screen, you might get 1/3rd, you might just get the upper left corner. The websites and programs on my computer that are designed responsively handle that, and the ones that aren't, don't. Thankfully, native programs have (slowly) started to get better about things like dropping out of 3-column views when they only have 300 pixels to work with. But the answer to that problem can not be that from now on I'll just open every program in full screen mode so the designer can perfectly position every element. The answer is responsive design, and if that means that a few pixels are out of place when I jam the design into a 328x451 pixel box, then that's fine. I want the interface to work inside the box first, to fulfill its functional requirements, and then to look pretty second.
geoffmunn 6y ago
Using em and ex is definitely the best way of doing relative font sizing, but the reason is something I don't think people properly understand. 1em is the width of a capital M character. 1ex is the height of the capital X character (of the font currently in use). If you specify block element dimensions using em and ex values, then the margins and paddings will be relative to the font and it will look really nice (in my opinion).
- maskros 6y ago
  1em as used in fonts and browsers has nothing to do with the size of a capital M character (though the name as used historically means it should). A font is drawn using a design size box (typically 1000x1000 units in OTF, 2048x2048 in TTF) and this box is scaled to the 'em' size. How big the glyphs inside the design box are drawn varies from font to font (which is the problem that the article is talking about). The ex unit is supposed to be the height of the _lower case_ X character (not the upper case) -- but typically is just 1ex = 0.5em
stevula 6y ago
The article is about OS font size, not CSS.
nightowl_games 6y ago
> Size your fonts with `em` and `rem` units, and size your containers based on the number of characters you want to fit in each line. I have no idea what you mean by this.
- runarberg 6y ago
  An example of a side note which should be smaller font-size and should be relatively narrow (on a maximized desktop screen): aside { font-size: 0.8em; max-inline-size: 30ch; } This will fit approximately 30 characters at most on your aside and the font size will be 80% of the font size of the parent container (which is probably an `<article>` or a `<section>`).
timvisee 6y ago
Yes! Don't fonts provide some form of hinting as well, to improve rasterization accuracy on various display configurations? Also, doesn't sub-pixel anti-aliassing break when using a rasterized source like the article suggests. These are two arguments against it - pro vector.
praestigiare 6y ago
This article is not about px versus em At best, this is a tangent because the author used px as an example.
- danShumway 6y ago
  A couple people have brought this up, and I'll admit I don't really get what they mean. The article is pretty clearly critical of non-pixel based rendering. Three of the four problems the author sees with fonts: > Unpredictable: you can’t guess what you’ll get. 16 pt means how many pixels, exactly? > Not practical: you can’t get what you want. Want letters to be 13 px tall? Can’t do it. > OS-dependent. Get different rendering when opening a document on a different OS. Can’t share editor config between macOS and Windows. Most of those complaints are relevant to what I'm talking about: - A pt measurement unit might be different between computers, which the author considers a serious problem to solve, and the web considers to be a fact of life to be embraced. - There's no way to specify exactly how many pixels a font takes up, which is not necessarily a problem people should be trying to solve. - Different OSes might display your font at different sizes, which is, again, not a problem that most native apps should be worried about. The author does have a (somewhat) legitimate complaint that `em` units are somewhat arbitrary. It's a little bit weird because it doesn't acknowledge that in this case "arbitrary" means specifically chosen by the font designer to incorporate the best spacing for their font. But whatever, I can get behind an effort to make it easier to compare fonts to each other, and it doesn't seem like there's a compelling reason to force everyone to follow the font designer's choices. But the author's solution is to use pixels (or some other unit-based non-relative measurement that will be guaranteed to render at the same size across OSes): > Specify cap height, not em square size. > Specify it in pixels. In short, I share the author's frustration that there's no way to relate different fonts to each other in a reliable way, I share their frustration over working with line-heights, but I don't see how their criticism of pts and need to have font size perfectly synced between Windows and Mac works into that. In a responsive world, it should not be an issue for your app that font size might be a different number of pixels than you set it as.
incrudible 6y ago
I fail to see a convincing argument here. The "px" unit has a well-defined relation to devicePixelRatio and works predictably across many devices. > It doesn't matter if your fonts are bigger on Mac or Windows. It is intentional that platforms can size their fonts differently, and your interface designs should take that into account. You're going to mess this up, guaranteed. I see it all the time. Font size strongly relates the sizing of all your other interface elements, which are naturally defined in logical pixels (or "px"). You can't design your way around that.
- danShumway 6y ago
  > Font size strongly relates the sizing of all your other interface elements, which are naturally defined in logical pixels (or "px"). You can't design your way around that. A huge part of responsive design is the art of designing your way around that. In most cases (not all, but most), don't define your interface elements in pixels (or any other logical unit that is unrelated to font size). I also see native apps fail at this, but it's not because it's an unsolveable problem, it's because a lot of native apps are behind the times on responsive design. Normally I'd criticize native UI toolkits here as well, but the truth is that for many toolkits (including GTK and QT) this hasn't been a problem for a while; most popular UI toolkits support font-based widths for layout. Designers just have to take advantage of those features.
  - incrudible 6y ago
    The operating system sizes everything according to the equivalent of devicePixelRatio, not font size. Device manufacturers choose this value according to screen size and pixel density. It is reasonably predictable. The em-size however could be anything. If your intent is to drive the layout with font size, using units such as "em" does the exact opposite of what you want: you're simply adding another unpredictable factor into your size calculations. > A huge part of responsive design is the art of designing your way around that. Using "px" for responsive design works just fine. What exactly is the advantage of "em" in this regard?
    - 6y ago
joshspankit 6y ago
I agree with pushing all aside to size by "Cap height" and "distance between baselines", but like you: totally disagree with using pixels. Font size is a ridiculous nonsense land with so many gotchas that it deserves it's own University semester, but pixels are a clear, specific, and-tangible thing. It would simply cause more issues as a certain number of designers would forget or not even be aware of physical pixels, and further cloud the space as they communicate with peers, bosses, subordinates, and the public. We could probably get to exactly where the author (and I) want to be by changing `em` and `rem` to use cap height and distance between baselines, or by using a new measurement altogether (although: https://xkcd.com/927/ https://xkcd.com/927/)
- danShumway 6y ago
  Agreed, I would have no objection to having more typographic tools on the web around stuff like line height. I don't want to get rid of `em` units, because they represent the font designer's vision of how the characters are best sized and positioned. I regularly do want to defer to that in my interfaces. But yeah, lining up fonts is a pain in the neck. The author is right, it would be nice to allow line-height to be defined more consistently. It would be nice to allow me to somewhat size two fonts to be the same height or width as each other without eyeballing things. So no, not pixels, but sure, have more ways of talking about font size based on concepts like baseline and cap height.
  - joshspankit 6y ago
    Agreed with only a single sticking point: If the font designer's vision is for the character baseline to be above or below other font's baselines 'within the em', I want to override that vision. As well: I feel like this type of standardization could actually free designers to make more interesting typographical layouts as they could freely mix fonts and sizes without cascade effects on the rest of the text.
    - danShumway 6y ago
      Right. In a lot of ways it's the same principle we're talking about on the web with using `em` units. Give users control (except in this case the layout designer is the user). I want font designers to be able to define a basic box and baseline for their font, and I want to be able to respect that if I'm just throwing the font onto a page without thinking about it. But I also want to be able to easily override it if I'm mixing fonts, and to be able to override it without manually adjusting a bunch of margins by trial and error that are specific to that font -- margins that will then immediately break if my users sub out their own fonts again. It's good that we have controls in CSS for stuff like line height, ligatures, character spacing. Having more of those controls would be useful, and having quick options for them that can kind of "standardize" different fonts to all act the same would be very useful.
OkGoDoIt 6y ago
I recently had lasik and went through a period of a few weeks where I couldn’t read small text on screens. It’s absolutely infuriating that you can’t just increase the text size on most websites. Most websites when you increase the text size it balloons the entire design as well. I had to do so much swiping left and right every line because text doesn’t reflow the way most designers code for the web. Em units should only be used for text, not for other aspects of your design. Let the text reflow within a fixed-size design!

deleted 6y ago

[deleted]

jancsika 6y ago

Essentially, you've made svg text a special case. So diagram-based languages and frankly any graph-drawing framework that let you specify text labels go out the window. I think svg `<glyph>` was meant to be the answer to this question, but that was an answer for people who don't care about readability. So now it is rightly deprecated. Unfortunately, that leaves essentially no answer except guessing and checking with pixel-sized fonts to make sure font-rendering-stack development troglodytes haven't screwed up my diagrams. So don't touch my pixel sizes, bro.

jancsika 6y ago
In fact, I think I'm underselling it. Because I think the gaming industry essentially says, "fuck it," to this same problem and simply uses images for the text. Am I right, gaming industry?
- danShumway 6y ago
  The gaming industry isn't doing responsive design. For multiple reasons, some legitimate and some not, but the point is that I would consider them to be a separate category. Most games on the web are going to be using Canvas I suspect -- in my experience at least, they usually won't be rendering to the DOM or using CSS at all.
danShumway 6y ago
> Essentially, you've made svg text a special case. So diagram-based languages and frankly any graph-drawing framework that let you specify text labels go out the window. Hear me out on this: a graphics format that is specifically designed to scale losslessly as it's biggest selling point, should have support for scaling `em` units. It's absurd that building responsive SVGs is currently harder than building responsive web pages. Instead it's got some kind of messed up, obtuse system where we either do viewport scaling and break all of our line-widths, or do percentage-based scaling and break all of our custom paths.
- runarberg 6y ago
  You can use `<foreignObject>`[1] in your SVGs to wrap text inside a nice HTML rendering (with word wrapping and other superpowers). However I’ve found that there is always some issues (e.g. I need the graph to shrink in the inline direction when text is longer then X; or this rect should flow lower when I have multiple lines). I’ve never actually found my self using <foreignObject> in the SVG diagrams I write, and usually just listen to a resize event and manipulate everything that way (shrug). 1: https://developer.mozilla.org/en-US/docs/Web/SVG/Element/foreignObject https://developer.mozilla.org/en-US/docs/Web/SVG/Element/for...
- jancsika 6y ago

jstimpfle 6y ago

> Size your fonts with `em` and `rem` units, and size your containers based on the number of characters you want to fit in each line. AFAIK this is not a good solution in most situations. The number of characters that you can fit on a fixed container varies greatly depending on platform / font / settings. By consequence, you'd lose a whole lot of control over you layout if you were to scale the containers in this way.

danShumway 6y ago
I realize this is going to come off as dismissive, but don't use fixed container widths. Responsive design is a paradigm shift away from perfect pixel-level control over every container size on a static-width document. It's not print design, it's a different medium. Stop making fixed layouts that break whenever I snap a window at half-width to the side of my screen; there are legitimate reasons why someone on a computer might want their fonts to be bigger or smaller, and your column widths should adjust to accommodate that.
- deleted 6y ago
  [deleted]
- ryanar 6y ago
  Agreed! This idea is presented really well in https://everylayout.dev https://everylayout.dev
  - vlz 6y ago
    https://every-layout.dev https://every-layout.dev But thanks for the reminder! I meant to have a look at that.
- deleted 6y ago
  [deleted]

akersten 6y ago

Absolutely agreed. The article laments things like "I have no good way of knowing how big my text is going to be when I say 16pt," and my response is "why would you ever need to know that? Do your containing elements not reasonably resize when their inner content gets bigger? How are you handling internationalization where strings will certainly be longer?" It's ok for apps to look different on different platforms. We need to stop trying to design things pixel-perfect to the mockups - I thought we could have left that trend behind in the early 2000's. OS font rendering can even provide info about the physical dimensions of the screen and give you an "actual size" unit you can use to match your screen to real world paper. So a lot of this article, to me, reads as a misunderstanding of why fonts render the way they do.

thomasfromcdnjs 6y ago
I like this opinion but not sure if it translates well to building apps in the real world. A lot of work goes into UX research and A/B testing, if fonts are too flexible none of your results will be meaningful.
- akersten 6y ago
  I would posit that if rendering differences in font display are affecting A/B testing a workflow, the A/B testing apparatus has failed to control for confounding factors and was probably invalid anyway. If OSX is known to render differently than Windows (and it's not just fonts), why are you comparing cohort A from Windows to cohort B from OSX? That is an analysis error.
- danShumway 6y ago
  Any kind of user customization will have the same effect. Any preference that the user can edit can be a confounding variable in an A/B test. I don't want to live in a software world where as a user I'm forced into a one-size-fits-all approach to every interface just because it makes A/B testing easier.
egwor 6y ago
If I have two monitors with two resolutions and I put the two screens together the text is a different size. When I'm reading the text I want it to be consistent as I move it across screens. With this approach will the text be the same size? The main issue I have as I get older is that as the resolution increases the text size seems to get smaller

CharlesW 6y ago

> …there are legitimate reasons to use pixels sometimes, but resolution independent font-size and container sizing should be the default. Web pixels are different than device pixels, and are resolution independent.

kevincox 6y ago
The are independent of the screen but also of the user preferences. Using rem or relative sizes bases your sizing off of the user's selected font size. As soon as you size something in px you have just thrown away the user's font size choice.
- charrondev 6y ago
  This doesn’t seem accurate. Items sized in pixels will get increased with CTRL + “+”.
  - kevincox 6y ago
    I believe that that zoom is handled differently from default font size.
  - pwdisswordfish0 6y ago
    Ctrl++ is only necessary because you've "thrown away the user's font size choice". As a user, I have my font preferences set to what I want to read. If you maintain main body text size = 1em, then those preferences are respected. If you start arbitrarily specifying font size in px (whether CSS px or physical px), then you destroy that. This can still happen with 1em, too, by opting for a font whose em box is screwed up, as described in the article, but that's the _easiest_ thing to test for, because it will be apparent on all screens (including the designer's).
danShumway 6y ago
Yes, correct, I should have been more specific. The resolution of the webpage as reported by the webpage, even if it doesn't line up with the literal number of pixels in a screen, should not be used for font sizing in most scenarios.

djrenren 6y ago

Hey just a heads up, on the web (or at least in CSS) px is resolution independent. It represents 1/96th of an inch [1]. The web has physical, font-relative, and viewport-relative lengths which all serve slightly different purposes. Like you, I find font-relative to be super useful much of the time, but the others have their place as well. I just want to point out that CSS specifically doesn't have a resolution-dependent measurement. Using pixel (1/96 in) sizes for a font is fine if you care about the physical size of the font being displayed. Starting from the system default font-size as you suggest will also work, but you'll need to test it on all the platforms (especially if you use a custom font). [1]: https://www.w3.org/TR/css-values-4/#absolute-lengths https://www.w3.org/TR/css-values-4/#absolute-lengths

danShumway 6y ago
Yes, completely correct, and it's good that you pointed that out. However, you also shouldn't be sizing fonts based on 1/96th of an inch units. That will also break responsive design in many cases. Not all of them, like you said there are legitimate use-cases, but most of the time you should not be trying to make a font be a specific physical size.

crazygringo 6y ago

I'm sorry, but you seem to be under some misconceptions about how pixel sizing works on the web. > resolution independent font-size and container sizing should be the default It already is. CSS "px" doesn't refer to physical pixels at all, they're called logical pixels. Which on old screens at 100% zoom may map 1:1, but these days are more likely to map 2:1 or even 3:1, and with OS and browser zoom levels may be things like 1.666:1 or 2.5:1. > Size your fonts with `em` and `rem` units In the browser, em/rem are necessarily defined by a parent/root element that is ultimately defined in either px or pt, so your suggestion doesn't achieve what you think it achieves. Today, whether you write your CSS in "em" or "px" results in an identical user experience. It's really just whether you prefer to work with a baseline of something like "16px" and use larger round integers (8px, 1000px, etc.) or prefer to work with something like a baseline of "1em" and use small numbers with lots of decimals (0.5rem, 30rem, 0.05rem). Ultimately we need some measure of consistency, and browsers have long defined that as a default legible body text size of 16 px = 12 pt (= 1 em by default).

jan_Inkepa 6y ago
> It already is. CSS "px" doesn't refer to physical pixels at all, they're called logical pixels. Which on old screens at 100% zoom may map 1:1, but these days are more likely to map 2:1 or even 3:1, and with OS and browser zoom levels may be things like 1.666:1 or 2.5:1. Yeah it's a nightmare if you're doing pixel-art-y games in the browsers, there's last time I checked no way in general to get access to physical pixels anymore, which makes integer-multiple upscaling AFAIK impossible in general. Hurrah. [ disclaimer: The browser rendering stack is complicated enough that I might be wrong. ]
- wffurr 6y ago
  CSS px * devicePixelRatio = physical pixels I feel your pain about non-integer scaling ratios. The way I hack around it is to set the canvas context to an integer number of device pixels, and then set the CSS size of the canvas to a fractional size: device pixels / DPR. We use this along with some other hacks on keep.google.com and some other sites to map 1:1 to display pixels to try to ensure hardware overlay promotion for the inking surface.

amelius 6y ago

> > Specify it in pixels > No thank you. The article is NOT about px versus em or pt. It is about specifying sizes in a way that makes sense, i.e. based on visible quantities rather than abstract quantities that are difficult to understand.

sings 6y ago
Agreed, this definitely goes off on a tangent. The article is mostly about switching two fonts with the expectation that the visual size of the characters remains consistent. That expectation fails because the em size is arbitrary with respect to the visible caps-height. As it stands, fonts can have drastically different rendered sizes at the same specified font size. This leads to all sorts of problems, like ensuring fallback fonts have similar metrics to the one you expect to load.
- dragonwriter 6y ago
  > The article is mostly about switching two fonts with the expectation that the visual size of the characters remains consistent. That expectation fails because the em size is arbitrary with respect to the visible caps-height. It would fail with caps-height, too, as other visible measures of characters (not just abstract ones like em) have no guaranteed consistent relationship to caps-height, so, as such, there's no guarantee that fonts with the same caps-height have the same “visual size”, or even visual vertical size, since cap height doesn't i close descender and ascender height.
  - amelius 6y ago
    Perhaps we should have a "median-height" property, for specifying the median height of the actual glyphs in the text.
setr 6y ago
It’s not just difficult to understand, the em height / character shape described by the article are total nonsense — they have zero relationship to the font itself, and no relationship between one font’s eg height and another. Which ultimately means that font sizing is entirely nonsense: the only thing you can say is font size 1 is smaller than font size 2, but it’s impossible to say by how much, or guess the difference, except when talking about one, and only one font. That is, a font with size 16 roughly corresponding to the same size in another font is entirely defined and enforced by nothing at all — it’s purely a “happens to be true”. Thus, the only real way to handle font sizing predictably is to never switch them out, because you’re really dealing with undefined behavior

samatman 6y ago

The main point of the article, as I see it, is that the "em" used in fonts isn't the intuitively correct em size. It's just a control box used by the font developer, and the result is that designers can't get a consistent font size. They can know, more or less, what something is going to look like given the font they want to load, but the fallback font might have a different concept of em size and look more different than it would need to be. So having a different metric, which is exactly capital height, makes fonts look more similarly-sized to each other at the same capital-height resolution, which he demonstrates in the article. This seems valuable to me.

joshuak 6y ago

I strongly disagree with this general philosophy. One should be able to use an absolute, non-relativistic unit of measure that requires no external knowledge at all. Not even to other parts of the same layout. Relativistic units are inadequate if they are free to cause non-pixel perfect transformations of designers intent from platform to platform. It is no more reasonable to re-layout a carefully designed UI then it is to reposition objects and people in a movie scene played on devices of different resolution, in fact it is much less reasonable. Perhaps, in some circumstances this will call for platform specific design, and that is correct and appropriate. Perhaps a UI will look like a postage stamp on a high pixel density display. Adjusting for that difference is the domain of the operating system and the user. Even the OS may be unaware of the actual physical size of the display, for example when using a projector. Automatic layout is a convenance, but it works against not for good design.

nemetroid 6y ago
Pixel-perfect design should not be a goal for the web if it means compromising usability.
- joshuak 6y ago
  It doesn't mean compromised useably, it is a guarantee of usability. Dynamic layout, re-flow and responsive design compromise usability. The utility of responsive design is not improved usability, its improved designer productivity at the cost of usability.
tracker1 6y ago
If you have two fonts at size X, they should both display the same number of lines in Y space... The problem is the relativistic measure isn't even consistent between fonts.
danShumway 6y ago
> It is no more reasonable to re-layout a carefully designed UI then it is to reposition objects and people in a movie scene played on devices of different resolution Is this unreasonable? We don't have the ability to design this kind of responsive control over video streams, but we do have the ability to speed up and slow down videos, embed captions that use native device fonts rather than bake themselves into the video file, adjust contrast and brightness, skip over segments and timestamps, and to adjust audio balance. And many players also have the ability to zoom in and cut off black bars. None of that seems like a problem? I'm regularly thankful for the ability to auto-skip intros and adjust playback speed. Every single video player should have the ability to play at 1.5x speed. I think in general it's important to separate practical design from art. I don't think any user has any obligation to worry about whether or not it's "reasonable" for to adjust an interface in whatever way works best for them. The goal of design is to make it easier to accomplish a task; the designers individual vision doesn't take precedent over that. > Adjusting for that difference is the domain of the operating system and the user. That's exactly why we have semantic units that are tied to a specific meaning/purpose, not ones that just represent abstract concepts like pixel width. The purpose of an `em` unit for widths is to describe the design of a column based on its intended use -- to show X characters in a line. The more specific we are about not just the width of an element, but also the intent behind that width, the easier it is for an OS and a user to adjust for size differences in specific scenarios. If I drop a page to 300 pixels, did I do that because I want the font to be bigger? Am I scaling the entire window down including the font? Do I want the same design and font-size in a single column? Semantic units allow me as a user to communicate the context a page is in, which allows the page to respond to that context. Absolutist design is anti-customization; it imposes the designer's will over the user's will. This matters because even in a single device/platform, it can often be impossible to design a single interface that always works. I use i3wm, so when I open a program it opens in tiled mode. You might get half of the screen, you might get 1/3rd, you might just get the upper left corner. The websites and programs on my computer that are designed responsively handle that, and the ones that aren't, don't. Thankfully, native programs have (slowly) started to get better about things like dropping out of 3-column views when they only have 300 pixels to work with. But the answer to that problem can not be that from now on I'll just open every program in full screen mode so the designer can perfectly position every element. The answer is responsive design, and if that means that a few pixels are out of place when I jam the design into a 328x451 pixel box, then that's fine. I want the interface to work inside the box first, to fulfill its functional requirements, and then to look pretty second.

geoffmunn 6y ago

Using em and ex is definitely the best way of doing relative font sizing, but the reason is something I don't think people properly understand. 1em is the width of a capital M character. 1ex is the height of the capital X character (of the font currently in use). If you specify block element dimensions using em and ex values, then the margins and paddings will be relative to the font and it will look really nice (in my opinion).

maskros 6y ago
1em as used in fonts and browsers has nothing to do with the size of a capital M character (though the name as used historically means it should). A font is drawn using a design size box (typically 1000x1000 units in OTF, 2048x2048 in TTF) and this box is scaled to the 'em' size. How big the glyphs inside the design box are drawn varies from font to font (which is the problem that the article is talking about). The ex unit is supposed to be the height of the _lower case_ X character (not the upper case) -- but typically is just 1ex = 0.5em

stevula 6y ago

The article is about OS font size, not CSS.

nightowl_games 6y ago

> Size your fonts with `em` and `rem` units, and size your containers based on the number of characters you want to fit in each line. I have no idea what you mean by this.

runarberg 6y ago
An example of a side note which should be smaller font-size and should be relatively narrow (on a maximized desktop screen): aside { font-size: 0.8em; max-inline-size: 30ch; } This will fit approximately 30 characters at most on your aside and the font size will be 80% of the font size of the parent container (which is probably an `<article>` or a `<section>`).

timvisee 6y ago

Yes! Don't fonts provide some form of hinting as well, to improve rasterization accuracy on various display configurations? Also, doesn't sub-pixel anti-aliassing break when using a rasterized source like the article suggests. These are two arguments against it - pro vector.

praestigiare 6y ago

This article is not about px versus em At best, this is a tangent because the author used px as an example.

danShumway 6y ago
A couple people have brought this up, and I'll admit I don't really get what they mean. The article is pretty clearly critical of non-pixel based rendering. Three of the four problems the author sees with fonts: > Unpredictable: you can’t guess what you’ll get. 16 pt means how many pixels, exactly? > Not practical: you can’t get what you want. Want letters to be 13 px tall? Can’t do it. > OS-dependent. Get different rendering when opening a document on a different OS. Can’t share editor config between macOS and Windows. Most of those complaints are relevant to what I'm talking about: - A pt measurement unit might be different between computers, which the author considers a serious problem to solve, and the web considers to be a fact of life to be embraced. - There's no way to specify exactly how many pixels a font takes up, which is not necessarily a problem people should be trying to solve. - Different OSes might display your font at different sizes, which is, again, not a problem that most native apps should be worried about. The author does have a (somewhat) legitimate complaint that `em` units are somewhat arbitrary. It's a little bit weird because it doesn't acknowledge that in this case "arbitrary" means specifically chosen by the font designer to incorporate the best spacing for their font. But whatever, I can get behind an effort to make it easier to compare fonts to each other, and it doesn't seem like there's a compelling reason to force everyone to follow the font designer's choices. But the author's solution is to use pixels (or some other unit-based non-relative measurement that will be guaranteed to render at the same size across OSes): > Specify cap height, not em square size. > Specify it in pixels. In short, I share the author's frustration that there's no way to relate different fonts to each other in a reliable way, I share their frustration over working with line-heights, but I don't see how their criticism of pts and need to have font size perfectly synced between Windows and Mac works into that. In a responsive world, it should not be an issue for your app that font size might be a different number of pixels than you set it as.

incrudible 6y ago

I fail to see a convincing argument here. The "px" unit has a well-defined relation to devicePixelRatio and works predictably across many devices. > It doesn't matter if your fonts are bigger on Mac or Windows. It is intentional that platforms can size their fonts differently, and your interface designs should take that into account. You're going to mess this up, guaranteed. I see it all the time. Font size strongly relates the sizing of all your other interface elements, which are naturally defined in logical pixels (or "px"). You can't design your way around that.

danShumway 6y ago
> Font size strongly relates the sizing of all your other interface elements, which are naturally defined in logical pixels (or "px"). You can't design your way around that. A huge part of responsive design is the art of designing your way around that. In most cases (not all, but most), don't define your interface elements in pixels (or any other logical unit that is unrelated to font size). I also see native apps fail at this, but it's not because it's an unsolveable problem, it's because a lot of native apps are behind the times on responsive design. Normally I'd criticize native UI toolkits here as well, but the truth is that for many toolkits (including GTK and QT) this hasn't been a problem for a while; most popular UI toolkits support font-based widths for layout. Designers just have to take advantage of those features.
- incrudible 6y ago
  The operating system sizes everything according to the equivalent of devicePixelRatio, not font size. Device manufacturers choose this value according to screen size and pixel density. It is reasonably predictable. The em-size however could be anything. If your intent is to drive the layout with font size, using units such as "em" does the exact opposite of what you want: you're simply adding another unpredictable factor into your size calculations. > A huge part of responsive design is the art of designing your way around that. Using "px" for responsive design works just fine. What exactly is the advantage of "em" in this regard?
  - 6y ago

joshspankit 6y ago

I agree with pushing all aside to size by "Cap height" and "distance between baselines", but like you: totally disagree with using pixels. Font size is a ridiculous nonsense land with so many gotchas that it deserves it's own University semester, but pixels are a clear, specific, and-tangible thing. It would simply cause more issues as a certain number of designers would forget or not even be aware of physical pixels, and further cloud the space as they communicate with peers, bosses, subordinates, and the public. We could probably get to exactly where the author (and I) want to be by changing `em` and `rem` to use cap height and distance between baselines, or by using a new measurement altogether (although: https://xkcd.com/927/ https://xkcd.com/927/)

danShumway 6y ago
Agreed, I would have no objection to having more typographic tools on the web around stuff like line height. I don't want to get rid of `em` units, because they represent the font designer's vision of how the characters are best sized and positioned. I regularly do want to defer to that in my interfaces. But yeah, lining up fonts is a pain in the neck. The author is right, it would be nice to allow line-height to be defined more consistently. It would be nice to allow me to somewhat size two fonts to be the same height or width as each other without eyeballing things. So no, not pixels, but sure, have more ways of talking about font size based on concepts like baseline and cap height.
- joshspankit 6y ago
  Agreed with only a single sticking point: If the font designer's vision is for the character baseline to be above or below other font's baselines 'within the em', I want to override that vision. As well: I feel like this type of standardization could actually free designers to make more interesting typographical layouts as they could freely mix fonts and sizes without cascade effects on the rest of the text.
  - danShumway 6y ago
    Right. In a lot of ways it's the same principle we're talking about on the web with using `em` units. Give users control (except in this case the layout designer is the user). I want font designers to be able to define a basic box and baseline for their font, and I want to be able to respect that if I'm just throwing the font onto a page without thinking about it. But I also want to be able to easily override it if I'm mixing fonts, and to be able to override it without manually adjusting a bunch of margins by trial and error that are specific to that font -- margins that will then immediately break if my users sub out their own fonts again. It's good that we have controls in CSS for stuff like line height, ligatures, character spacing. Having more of those controls would be useful, and having quick options for them that can kind of "standardize" different fonts to all act the same would be very useful.

OkGoDoIt 6y ago

I recently had lasik and went through a period of a few weeks where I couldn’t read small text on screens. It’s absolutely infuriating that you can’t just increase the text size on most websites. Most websites when you increase the text size it balloons the entire design as well. I had to do so much swiping left and right every line because text doesn’t reflow the way most designers code for the web. Em units should only be used for text, not for other aspects of your design. Let the text reflow within a fixed-size design!