[HN Gopher] Let's fix font size
___________________________________________________________________
Let's fix font size
Author : rhabarba
Score : 432 points
Date : 2021-03-30 10:59 UTC (12 hours ago)
(HTM) web link (tonsky.me)
(TXT) w3m dump (tonsky.me)
| belinder wrote:
| Not sure if capital letter size would catch scenarios with little
| circly swirls that make other characters taller than capital
| letter characters
| [deleted]
| jamesu wrote:
| Font metrics are a pain. A while back I was working on trying to
| reliably reproduce the behaviour you get from the win32 font api
| using stb_truetype, but due to time constraints I just ended up
| having to manually tweak font sizes to match.
| tomgp wrote:
| Just look at those to two images with all the "Andy"s: In the
| first the words all have similar visual weight, none stand out or
| take up considerably more or less space. In the second image
| where all the cap heights are the same some fonts make the word
| look huge (courier new) others tiny (victor mono). That to me is
| a clear illustration of why this proposal is not going anywhere.
| JxLS-cpgbe0 wrote:
| What's the x-height of z[?][?][?][?][?][?][?][?][?][?][?][?][?][?
| ][?][?][?][?][?][?][?][?][?][?][?][?][?][?][?][?][?][?]?
| forty wrote:
| Interesting character :) what is it?
| jfk13 wrote:
| It's just a "z" with a ton of combining diacritics. Which is
| entirely irrelevant. x-height is a dimension of the font,
| it's nothing to do with an individual character. (In most
| Latin fonts, it'll match the height of the "x" glyph, but
| that's not a hard and fast rule.)
| zarq wrote:
| Capital Za[?]l[?]g[?][?][?]o[?][?][?]
| andjd wrote:
| >I see no reason to honor the so-called "default line-height".
| It's basically a font designer's personal preference, imposed on
| every user of the font in every viewing condition.
|
| Erm... To a large extent, these details of a font _are_ the the
| designer's -personal-preference- professional judgement, and
| that's the point. We use different fonts because they have a
| distinct feel or quality, and how much spacing they have between
| lines is one of the many little details that add up to the
| gestalt of a font. If you don't like the line spacing of a font,
| don't use it. Or tweak it if you like. But don't pretend that
| declaring that all fonts should have a line spacing of 200% of
| their cap height isn't similarly trying to impose your personal
| aesthetic preferences on everyone else as well.
| jahewson wrote:
| This has basically always been the case for typography. The point
| size of physical type refers to the height of the slugs, not the
| letters on them. You can't just grab two 12pt fonts and expect
| them to be exactly the same size.
|
| The standard solution is to use x-height, rather than cap-height
| and I agree that it would be nice to be able to select a font
| based on that instead of the em-size (font size).
|
| Line height on the web is indeed broken, as it's measured from
| the center of the em-box and I agree it would be nice to be able
| to specify baseline distances instead but the catch there is that
| you really need to know the content of the text being typeset, as
| soon as you start adding words with diacritics (AAA) your lines
| collide.
| ska wrote:
| > It's basically a font designer's personal preference, imposed
| on every user of the font in every viewing condition.
|
| Buried the lede here; but "personal preference" is really design.
| Article perhaps should be retitled "I don't like typographic
| design because it forces UI element to adjust to typographic
| spacing rather than the other way around". Clearly you can make
| arguments for both being the "right" way.
| globular-toast wrote:
| > The solution > Specify it in pixels.
|
| No, no, no... I don't understand why the author would suggest
| specifying in pixels. We know pixel size varies widely between
| different displays. This means we need stupid hacks like having a
| multiplier to convert from specified pixels to _actual_ pixels.
| So why pretend it 's specifying pixels in the first place?
|
| It's always annoyed me that DPI is not expected to be set
| correctly. All monitors should come with a DPI value that you set
| in your OS. Of course, a user is free to add some kind of
| multiplier on top of that (to account for variation in sight and
| preference), but the baseline would be standard.
| danShumway wrote:
| > 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._
| joshuak wrote:
| 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.
| CharlesW wrote:
| > _...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.
| danShumway wrote:
| 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.
| kevincox wrote:
| 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 wrote:
| This doesn't seem accurate. Items sized in pixels will get
| increased with CTRL + "+".
| kevincox wrote:
| I believe that that zoom is handled differently from
| default font size.
| djrenren wrote:
| 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
| danShumway wrote:
| 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.
| jstimpfle wrote:
| > 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 wrote:
| 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]
| [deleted]
| jancsika wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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.
| akersten wrote:
| 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.
| egwor wrote:
| 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
| jfk13 wrote:
| > The main issue I have as I get older is that as the
| resolution increases the text size seems to get smaller
|
| Most operating systems provide options for you to address
| that, by adjusting a scaling factor used by the display
| system.
| danShumway wrote:
| This is exactly the problem that I'm getting at. The reason
| your font is getting smaller with higher pixel densities is
| because the font size is being tied to the pixel density.
|
| In a better native world, your font size would be
| completely unrelated from the monitor(s) you're using. It
| is the attempt to tie font sizes to physical attributes of
| your monitors like their resolution that is giving you this
| problem. And it is the need for scaling to be based on
| resolution that makes multi-resolution monitor setups
| break.
|
| There's no reason why your OS couldn't size text
| differently on each monitor based on monitor-specific
| settings that you control, and there's no reason why the
| applications you're using couldn't implement responsive
| design and accommodate that setup.
|
| As designers we would just need to embrace responsive
| design and stop trying to control everything.
| amelius wrote:
| > and my response is "why would you ever need to know that?"
|
| The author wants to know, so this is simply the wrong
| question. I agree with the author that it is strange that a
| quantity which is in principle easy to compute behaves in
| such an unreliable way. It makes designing stuff more an
| iterative instead of a first-time-right experience.
|
| Also, if you specify X and get Y instead, then that is a way
| for websites to fingerprint your browser, which is another
| reason to make the computation more reliable.
|
| > It's ok for apps to look different on different platforms.
|
| We've been all in the situation where you designed something
| for device A and it looks off when viewed on device B. A word
| that wraps in the wrong place, or a button that is 1px taller
| than the button next to it, etc. More control over what is
| shown in the browser is always better. (Of course, a user
| should be able to override everything, but that is another
| matter entirely).
| thomasfromcdnjs wrote:
| 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.
| danShumway wrote:
| 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.
| akersten wrote:
| 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.
| simion314 wrote:
| A problem I had and I could not find a solution (maybe
| someone could help me).
|
| I want to show a button for the user to click. I respect my
| user and I want my button not to be too big or small, I would
| like it to be equal or similar to his preferred button size
| he configured his OS to use. If you search for the best
| practices you find studies that say that on mobile the button
| should be maybe 10mm real size , but good luck setting a css
| dimension on the button that will ensure either this default
| size on all devices. IMO there should be a css value for
| preferred font size and preferred touch button size so you
| don't get at the same time complaints that the button is too
| large or too small. (I do mostly bgackend so maybe I missed
| something when searching, maybe there is some hidden trick to
| do this...and I am referring at mobile devices)
| danShumway wrote:
| Having another unit for "touch area" would be kind of nice,
| I can imagine uses for that. The device/browser/user could
| set how large a `ta` unit is for buttons/inputs.
| .ClickBtn { min-width: 10ta; min-height: 5ta; width: 15em;
| }
|
| Wouldn't just be useful for mobile, I can imagine even on a
| desktop a user with Parkinson's or something might have
| trouble precisely using a cursor and want bigger
| interaction areas when they visit a website.
|
| The most common solution I see online is to swap layouts
| when the page drops below a certain aspect ratio or width,
| which can actually be kind of annoying on desktops. It's a
| hacky solution.
|
| There are also some media queries you can do to detect the
| presence of a mouse in some browsers, which can work, but
| also doesn't really hold up in a world with convertible
| devices that can be simultaneously mouse-drive and touch-
| enabled.
| sings wrote:
| > The most common solution I see online is to swap
| layouts when the page drops below a certain aspect ratio
| or width, which can actually be kind of annoying on
| desktops. It's a hacky solution.
|
| In many scenarios, there is no way to interpolate between
| the ideal layouts for large and small screens. This makes
| it necessary to arbitrarily select some point where the
| layout is rearranged as the viewport changes.
|
| I agree that this behaviour can be annoying on desktops
| as the window is resized, but it's better than the
| alternative - a layout that needs to work the same way
| for drastically different screen sizes.
| simion314 wrote:
| The problem I have presented in the grandparent comment
| could be solved either with:
|
| - let me specify the button size in real world dimensions
|
| - let me specify that my button should be the same size
| as Safari/Chrome buttons in the toolbar.
|
| Then my users can't complain that on their device the
| buttons are too big or too small. The page was something
| like a map with a toolbox on bottom, if you make the
| buttons too big the map area is reduced, if the buttons
| are too small then are hard to use.
|
| With native toolkits like Qt you have a toolbox widgets,
| you don't define any dimension or colors and the user
| theme will handle everything.
| ryandrake wrote:
| > 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.
|
| Thank you, Yes Yes!
|
| The web was much better when it was annotated text: You took
| a primarily _text_ document, maybe decorated with a few
| formatting hints, and let the User-Agent take care of the
| rest. Over the years, browsers have handed way too much fine-
| grained control over to web developers, and the result is
| thousands of developers treating my Hyper _Text_ browser as
| some kind of interactive graphic design canvas. This has
| really been a step backwards in web usability, even though it
| enabled nice fancily-designed blogs and "web apps" of
| dubious value.
| amelius wrote:
| > > 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 wrote:
| 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.
| setr wrote:
| 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 wrote:
| 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.
| crazygringo wrote:
| 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).
| danShumway wrote:
| > It already is. CSS "px" doesn't refer to physical pixels at
| all, they're called logical pixels.
|
| Okay, yes, but when people ask what the current resolution of
| a page is on the web, most of the time they're talking about
| those logical pixels. You're correct, but also this doesn't
| change anything about my argument. It's still a mistake to
| tie layout to the resolution of a web page, regardless of
| what unit you're using for a pixel.
|
| > Today, whether you write your CSS in "em" or "px" results
| in an identical user experience.
|
| No it doesn't. Like you said, `em` units are based on the
| current container font sizes. Pixels aren't.
|
| There's no way in the pixel world to say that you want a
| container that will always display 40 em-sized characters,
| and to have that continue to be true even as font size
| increases and decreases.
|
| You can try this yourself[0]. Set Firefox to Zoom Text Only
| (View->Zoom), then zoom in/out on a container sized with
| pixels and a container sized with `em` units. Only the `em`
| sized container will change its size, because its width is
| being tied to the font settings so its width scales
| proportionally as the font size changes.
|
| [0]: https://jsfiddle.net/jbwf6um4/
| crazygringo wrote:
| > _It 's still a mistake to tie layout to the resolution of
| a web page_
|
| You've got to tie it to _something_. Your argument falls
| apart because "em" are still defined in terms of "px" at
| the root element. You're _always_ defining layout relative
| to a logical resolution. Also, responsive design reports
| viewport widths in logical pixels, so logical pixels are
| still what everything is ultimately tied to.
|
| > _Set Firefox to Zoom Text Only (View- >Zoom)_
|
| Nobody does that anymore. That was how browsers zoomed two
| decades ago. For a _long_ time now, browser zoom defaults
| to zooming all content, i.e. logical pixel size. Heck,
| Chrome doesn 't even _have_ a text zoom option anymore. I
| 'm actually surprised Firefox still does -- maybe it's a
| backwards-compatibility thing?
|
| It's true that maybe two decades ago defining sizes based
| on em was a best practice, precisely because browsers only
| zoomed font sizes. But that ceased having relevance a long
| time ago, once browsers stopped using text zoom (except as
| an obscure setting).
|
| Today, in the browsers and browser settings 99% of people
| use, px vs em has zero difference for the user. It's just a
| matter of programming taste. ( _Especially_ now that it 's
| generally recommended to use rem over em anyways.)
| tracker1 wrote:
| Chrome on mobile absolutely has a text zoom, it's exposed
| as an OS function, but chrome respects it... my vision is
| not great, so in accessibility settings I have fonts set
| to largest. Chrome does a decent job (as most Android UI)
| of respecting this. The apps that don't, or don't do it
| well (Facebook) are the ones that are particularly
| annoying.
|
| It may not be exposed in the browser directly, but the
| functionality is definitely there.
| danShumway wrote:
| > because "em" are still defined in terms of "px" at the
| root element
|
| No they're not, they're tied to the _resolved_ font size
| of the current element they 're in.
|
| That matters if someone overrides part of the CSS, so
| even from a pure engineering perspective this makes a
| real difference. It also matters if the user changes the
| font size of their browser.
|
| `em` units define font size _in relation_ to the current
| font size. That font size might be set elsewhere in CSS
| using pixels, it might be set by the browser. It might be
| set using viewport width, it might be set using
| percentages. It might be set in pixels and overridden by
| the user using the browser 's minimum font size feature.
|
| In all of those cases, as a designer you will be glad
| that you used `em` units for container width and child
| text rather than pixels.
|
| > Nobody does that anymore. That was how browsers zoomed
| two decades ago.
|
| This is how Firefox's default font sizing works today. I
| listed that zoom option so it would be easier for you to
| play with it, that's the only reason. But if you go into
| your settings and change the default font size of the
| browser (which is absolutely something that people who
| have bad vision still do today), then you will see the
| same result in the JSFiddle I linked.
| crazygringo wrote:
| > _This is how Firefox 's default font sizing works._
|
| That's misleading. Firefox's default _zoom_ sizing zooms
| fonts together with everything else. Virtually nobody
| uses _font-only_ zooming. People with bad vision still
| overwhelmingly use page zoom -- because if your vision is
| bad you need _everything_ enlarged, including things like
| icons and images.
|
| Also, your description of how font size for em's is set
| is incorrect. It's _always_ set ultimately relative to
| px. If set by the browser, it 's a default stylesheet
| that specifies "body { font-size: 16px; }". It _cannot_
| be set as a percentage of viewport size using HTML /CSS,
| that doesn't exist as an option in font-size. If the
| browser sets a minimum font size, that too is ultimately
| in px.
|
| Your whole argument hinges on people using font-zooming,
| when that died for all intents and purposes many, many
| years ago. There's no reason for web designers to
| accomodate nonstandard font zoom anymore -- forcing all
| UX units to be in ems just re-implements page zoom using
| text zoom, which is utterly redundant.
|
| Use px or use rem, they're functionally equivalent --
| it's just a matter of developer preference.
| danShumway wrote:
| > Virtually nobody uses font-only zooming.
|
| I don't know how you can claim this. I have set up
| multiple computers for elderly people and taken advantage
| of that feature. Heck, _I_ have taken advantage of that
| feature on devices with weird aspect ratios like the
| older Surface Pros.
|
| > It cannot be set as a percentage of viewport size using
| HTML/CSS, that doesn't exist as an option in font-size
|
| What? font-size: 1vw;
|
| > If the browser sets a minimum font size, that too is
| ultimately in px.
|
| This is being pedantic. If a user or a parent container
| is setting the font size, that is clearly a different
| scenario then setting it in the container itself.
|
| If you're going to go down this route we might as well
| claim that browser fonts are set based on physical pixels
| as well, since ultimately the browser resizes its
| internal representation of pixels based on the device
| aspect ratio.
|
| > it's just a matter of developer preference.
|
| I don't know any experienced developer who writes CSS for
| a living that would claim this. Pixel-based CSS files are
| a nightmare to maintain when nesting components, this
| makes a tangible difference to how you architecture your
| CSS files.
| mtone wrote:
| What is the use case for font-only zooming?
|
| I just tried it on a few sites and it either doesn't
| change much/anything or breaks stuff -- either by
| overlapping text, or not increase the width of text zones
| so you end up with few words per line in the middle of
| the screen which was particularly bad on a newspaper site
| (along the ridiculously undersized article photo).
|
| I thought it could save some space in headers and such if
| they don't zoom those, but if they used ems everywhere as
| might be best practice then there's no win to have.
|
| So it's either the same or worse than full-page zooming
| in every test so far. This is not only a now-obscure
| feature, it should be considered deprecated imo --
| zooming (or changing default) font size feels like
| hijacking a responsive web page source and hoping for the
| best.
| [deleted]
| danShumway wrote:
| > either by overlapping text, or not increase the width
| of text zones so you end up with few words per line in
| the middle of the screen
|
| Those the problems that I mentioned. Those problems are
| why you don't use pixels instead of `em` units.
|
| If you increased the font size in a PDF then columns,
| diagrams, and layouts would also break. But you wouldn't
| be surprised because you don't expect the PDF to be
| responsive. We expect the browser to be responsive.
|
| The use-case for font-only zooming in general is that as
| a designer, there are elements that should scale with the
| font and elements that shouldn't. Full-page scaling works
| by acting like the browser is just a lower resolution, so
| everything scales upwards except percentage units and
| viewport units, including things like border widths,
| spacing between columns, etc... Sometimes as a user
| that's what you want. Sometimes it's not.
|
| As a designer, it would be useful to be able to have more
| control over that process to make something that
| genuinely feels responsive, rather than to be completely
| subject to a zoom method that is just pretending you're
| on a screen half as large and then upscaling before it
| renders.
|
| It would also be useful because we'd like to build the
| web into an extensible platform that users can interact
| with in creative ways. So maybe we'd like the ability to
| scale only _part_ of a webpage. Note that this is not
| completely theoretical, Firefox already lets users set
| minimum font sizes. If I set a minimum font-size of 14px,
| it doesn 't matter if you say that your font-size is 8px,
| it will render at 14px -- but all of your bigger titles
| and headers will be unaffected. That's the kind of
| feature that works if browsers allow font-based zooming,
| but that is impossible to do with full-page zooming.
| crazygringo wrote:
| Wow, you're right about vw. I've never once seen it in
| the wild, MDN's page for font-size certainly doesn't
| mention it, and I've never seen it listed anywhere as a
| best practice. But TIL, thanks.
|
| It's clear you really like font-zoom, and also that your
| preference is extremely uncommon. I still don't know why
| you recommend writing CSS using "em" dimensions for UI
| elements to work with font-zoom, rather than just "px"
| with page zoom, when the end result is identical. I
| mean... why _would_ you use font zoom when the rest of
| the world has moved on to page zoom?
|
| And I also don't know why you say nesting pixel-based
| components are a nightmare. Dimensions work exactly how
| you think they will, relative to the page.
|
| On the other hand, nesting em-based components _is_ a
| nightmare, because they jump crazily in size. You never
| want your date picker jumping 2x in size just because you
| placed a button for it inside of a larger header row vs.
| inside of a smaller form line. In fact, that 's the whole
| reason Bootstrap migrated from em to rem, precisely not
| to have that problem.
|
| Em-based components are really only appropriate for the
| most trivial typographical "components" if you can even
| call them that, like a bullet or tiny badge or something
| that gets used in different sizes of text. Certainly not
| components you would usually nest.
| danShumway wrote:
| > and also that your preference is extremely uncommon
|
| I'm still confused about this. You're commenting under an
| article that specifically calls out font-based zooming
| and differing font-sizes between devices as a problem in
| native environments. If it was as rare as you say, why is
| the writer upset about it? Do people only customize their
| fonts in Gnome/Mac, and never on the web? Nobody wants
| their browser to inherit system settings? Firefox didn't
| even have an option to set a default zoom on every
| webpage in the style you describe until early 2020.
|
| I mean, you can say this is uncommon and I'm in a bubble,
| and maybe you're even right, but I feel like at some
| point I'm going to want to see some stats on that,
| because I'm not sure I believe you.
|
| > On the other hand, nesting em-based components is a
| nightmare, because they jump crazily in size. You never
| want your date picker jumping 2x in size just because you
| placed a button for it inside of a larger header row vs.
| inside of a smaller form line.
|
| Depends heavily on the component; this is why both `em`
| and `rem` units are useful. But it's not that uncommon to
| want nested elements like a date picker to scale.
|
| My experience (doing a fair amount of front-end work in
| my day-to-day job, and writing a ton of CSS from scratch)
| is that (particularly when I'm writing in BEM style) I
| use `em` more often than `rem`, even for complicated
| components. But yeah, I do use `rem` sometimes, it's not
| that uncommon. It depends a lot on what you want the
| behavior of a component to be.
|
| > In fact, that's the whole reason Bootstrap migrated
| from em to rem, precisely not to have that problem.
|
| Two things. First, they didn't migrate to pixels, they're
| still inheriting their font sizes from user/browser
| preferences. In fact, Bootstrap in part moved to `rem`
| specifically to get away from pixel units in multiple
| parts of the codebase[0]. I don't see any sources online
| that claim they've abandoned the `em` unit entirely.
|
| Second, I would very, very hesitantly suggest that maybe
| Bootstrap is not actually the best example of responsive
| design. I'm not going to get into an argument about it,
| it's a very impressive framework. It's just in my
| experience often a pain to work with, precisely for this
| kind of reason (among others). You nest an element in a
| static page and then dig through layers of classes to
| figure out why nothing adapts to the container it's put
| in. Bootstrap is very useful until you start to heavily
| customize anything. Just my opinion, and to be fair I
| have not tried out Bootstrap 5 yet.
|
| The reason why nesting pixel-based components is a
| nightmare is because it forces you to care about every
| CSS class that sets a width in your component. It forces
| you to update every width and height in the component
| every time you want to make a change. For codebases you
| do control, this is sometimes merely annoying (depending
| on how clearly the CSS is written). But for 3rd-party
| styling systems, it can be a nightmare.
|
| [0]: https://github.com/twbs/bootstrap/issues/19943
| zamadatix wrote:
| Just completely forget "resolution" when talking about CSS
| pixels as they have nothing to do with the actual
| resolution (virtual or physical) when it comes to layout. A
| CSS "pixel" is just another way of saying 1/96th an inch
| just like saying a pt is 1/72 an inch.
|
| Em is indeed "font size * value" which is the difference,
| and only difference, vs using pt or px or pc or any other
| absolute sizing reference. Per CSS spec though this is only
| a difference for the _developer_ not the _user_ as the
| other person originally stated - either way on any screen
| at any zoom the results are identical to the user. Well
| negating the user only zooming portions of the design
| which, by definition, is not going to give a
| proportionately scaled design back. Also you can actually
| implement this in CSS using px you just need to tie it to
| calc() - though cleaner to just use em if that's all you
| wanted to do at that point. Like the original commentor
| said though, eventually em is going to read back to
| something which defines font size in absolute measures,
| such as px or pt, so for all of the debate either way
| eventually your font is all absolute measured based it's
| just a matter of what the original measure is currently set
| to (16px by default).
|
| Which comes to what I really wanted to say after clarifying
| the above, I like defining the root font size in px and
| using rem everywhere else. In that way I can think in terms
| of "I want this header to be 3x as large as the base font
| on the page", easily change the base font to whatever px
| value I want (scaling all the page text accordingly), and I
| don't have to worry about inheritance if I change a
| parent's font size. Best of both worlds between em and px
| IMO. Like I said you could get the same thing, or something
| more advanced even, with calc() and a variable but no
| reason when rem has been built into browsers for ages.
| danShumway wrote:
| > which is the difference, and only difference, vs using
| rem or pt or px or pc or any other absolute sizing
| reference
|
| It's a difference for anyone who changes the default text
| size in Firefox. The "Zoom Text Only" option works the
| same way as Firefox's default text sizing. This is a
| difference that does matter for anyone who adjusts either
| the default or minimum font size in their browser, it's
| not theoretical.
|
| > I like defining the root font size in px and using rem
| everywhere else
|
| This is better than using pixels everywhere. I would not
| define a root font size in pixels, I would leave it as
| 1rem. BUT, what you're doing is _much_ , much better than
| what the article is proposing, so I'm not going to be too
| critical.
| jan_Inkepa wrote:
| > 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 wrote:
| 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.
| dukeofdoom wrote:
| I was working on Display an Event Title, across devices. Sine the
| title can very dramatically, from just a word, to as many as 10+
| words. Its hard to size this properly, so that it displays on
| phone and computer screens. Not really sure which approach I
| should have taken, but I ended up using if statements to change
| font size based on word count. Wish there was some way of setting
| the font size so that it fills to the end of the screen. But its
| no larger so that title is longer than two lines. Its really easy
| to spot a title when its too big or too small, so that its not
| aesthetically pleasing. But don't really know how to do that in
| code. Seems like a font size that is tied to the line length
| might help.
| perardi wrote:
| Perhaps using...
|
| http://fittextjs.com
| true_religion wrote:
| In other news, this guys dark theme simply blacks out the sight
| and only lets you read text by using the mouse cursor as a flash
| light.
|
| It's hilarious.
| dredmorbius wrote:
| https://news.ycombinator.com/item?id=26590267
|
| https://news.ycombinator.com/item?id=26072323
|
| https://news.ycombinator.com/item?id=24589944
|
| https://news.ycombinator.com/item?id=23941312
| forgotpwd16 wrote:
| Heh, that's cool. But images are over the flash light making it
| seem strange.
| marcosdumay wrote:
| _Night_ theme, as opposite to day. It doesn 't seem to support
| a dark theme.
|
| Anyway, Firefox Dark Reader extension makes they both moot.
| [deleted]
| alakhtikov wrote:
| (off) Hey @true_religion, we are building a new p2p CDN and
| looking for a piece of advice from a domain expert. It would be
| nice to speak with a person, who is running "a media group with
| massive bandwidth requirements (1PB+ per site)". If you don't
| mind to do a user interview, please shoot me an email at
| anton+hn@farbacdn.com
| kevincox wrote:
| It is, but I really wish there was an option other than that
| yellow. Maybe if you click it again you can get an actual dark
| theme? Pretty please?
| mixmastamyk wrote:
| Reader view in light or dark mode works fine.
| njharman wrote:
| Whether the arguments or proposals are correct or better. Doesn't
| matter.
|
| Us, as in people reading blog post lack the ability to change
| 100's of years of conventions and standards across all the world.
| Change
| ineedasername wrote:
| You can't fix font size without also addressing printing. 72 may
| have been chosen as the PPI due to Mac monitors at the time, but
| it wasn't just for the on-screen size: It also meant that what
| you printed out on paper would be certain size as well. The roots
| in physical printing is precisely why there can a disconnect
| between screen size and text size: The bedrock assumptions that
| were baked into the system were targeting desktop publishing.
|
| That's still the case today: 12pt font on a 13" 1080p screen will
| print may look a lot smaller than 12pt font on a 24" 1080p
| display, but when you hit the print button they will both be the
| exact same size on paper.
| anticristi wrote:
| Reading this article makes me feel nostalgic: Remember the time
| when text rendering meant bitblt-ing from an 8x8 pixel matrix
| stored in ROM.
| grenoire wrote:
| "Dude, I can't believe that your TTY renders the 'a's counters
| at four pixels high whereas mine at six! They're both eight-by-
| twelve in the bitmap."
| jfk13 wrote:
| And font design meant uploading a new set of bitmaps to the
| video card (if you were lucky enough to have a machine where
| they weren't strictly limited to what was provided in ROM).
|
| The first non-Latin font editor, text processing and
| typesetting software I worked on ran on just such systems. Yes,
| those were very different times!
| swiley wrote:
| Pixels are meaningless unless you're an artist, especially with
| modern graphics APIs where it's often difficult to actually draw
| individual pixels.
|
| IMO: everyone who's used font size outside college knows what an
| em is. Just standardize a point size in terms of a physical
| measurement (maybe stick with 1/72 inches since everyone except
| Microsoft apparently uses that) and make the "font size" a
| coefficient that maps ems to inches.
|
| Furthermore: cap height doesn't capture as much as an em does:
| there's spacing between letters which has little to do with cap
| height. Everything about this is wrong.
| arduinomancer wrote:
| Isn't specifying font size as "display-independent pixels (dp)"
| supposed to deal with this?
| 8bitsrule wrote:
| relevant XKCD: https://xkcd.com/1273/
| jfk13 wrote:
| > The solution
|
| > - Specify cap height, not em square size.
|
| > - Specify it in pixels.
|
| Specify cap height, really? How does that work for Arabic or
| Tibetan or Mongolian (or ..., or ...) -- so many writing systems
| where "cap height" is meaningless, because there are no "capital
| letters" and no single dimension that is common across most
| characters in the set? Not all the world uses English.
|
| Specify it in pixels? So if I set my editor font size to 16
| pixels, on my MacBook's display, with 226 pixels per inch, the
| 16-pixel tall letters will be somewhat less than 2mm tall, if
| I've got the calculation right. Move the window to my external
| FlexScan display and that same 16-pixel letter will now be 4.32mm
| tall.
| skrebbel wrote:
| Oh come on, this entire article is obviously about Latin
| typography. Other scripts are simply out of scope.
|
| You'll find that nearly all typography articles focus on a
| single script they way. Often that's Latin because of its
| widespread use in the west, but not always.
|
| There's no racism here. Articles about pizza aren't dismissive
| of kebab.
| akersten wrote:
| > . Other scripts are simply out of scope.
|
| Luckily, the font engine developers for popular operating
| systems did not scope those issues out just because they were
| inconvenient for designers who falsely assume that "16"
| should mean an arbitrary part of a letter in a font is always
| 16 pixels high.
|
| > There's no racism here.
|
| No one said there was until you brought it up?
| ClumsyPilot wrote:
| So basically:
|
| "This car is only for driving in sunny weather on a perfectly
| smooth surface. It doesn't have lights, tyres, suspention or
| heating because traction, snow, rain, road bumps and darkness
| are out of scope."
| [deleted]
| jfk13 wrote:
| Nobody said anything about racism.
|
| Yes, the article was obviously focused on Latin typography,
| but it was calling for a user interface change that would
| affect everyone using the affected software, no matter what
| language they speak/write.
| kps wrote:
| For Latin, x-height is much more important than cap height,
| in particular for selecting compatible sets of fonts.
| johncolanduoni wrote:
| The author seems to be using the web notion of CSS pixels
| (which take PPI into account) without qualifying it. This is
| understandably pretty confusing to anyone who has used pixels
| in, well, any other context.
| mitchdoogle wrote:
| OK. Well let's come up with a solution that takes into
| consideration these other systems. Instead of getting angry
| that someone was ignorant of other languages, help them
| understand a way their ideas could be adjusted to be more
| inclusive.
| jfk13 wrote:
| Who's angry? I just pointed out that the proposed "solution"
| has some shortcomings that didn't appear to have been
| considered at all.
|
| OK, a more inclusive solution: how about sizing fonts based
| on a coordinate space within which the font designer is free
| to draw the glyphs using as much or as little of the space as
| they consider appropriate for a given character. (They can
| even draw beyond the nominal "bounds" of the sized coordinate
| space, e.g. for long tails or flourishes.)
|
| We could call it... oh, let's see... maybe the "em square".
| yoz-y wrote:
| That doesn't solve the need of: "I have two different fonts
| and want to display them having the same size". And also "I
| want to center a piece of text inside a box". Both of which
| are basically impossible these days without special casing
| for each font.
| jfk13 wrote:
| "I ... want to display them having the same size" is too
| vague to be useful.
|
| Do you mean having the same x-height (the main body of
| the lowercase letters, assuming Latin script)? Or the
| same cap-height? Or the same ascender height? Or the same
| descender depth? Or the same character widths? Or a
| similar overall amount of "ink" in each character?
|
| Yes, it's impossible without special-casing for each
| font, because there is no clear basis for making such an
| equivalence, given how designs differ.
| yoz-y wrote:
| The general case would be to have text written in the
| same paragraph align well. To me that encompasses same
| baseline, same x height, and in the case of mixing
| scripts same cap height (in case of CJK). Basically "do
| what I mean". I understand that it's hard, but it should
| be at least doable. If it would require being able to
| specify which height to consider, so be it, make it an
| option.
| The_rationalist wrote:
| This is a nice solution which however won't solve the
| problem for non-updated font polices.
| anticristi wrote:
| Forget "foreign" scripts. More pressing is the concern of
| properly sizing emoticons, so they don't look odd when mixed
| with Latin.
|
| I'm sometimes wondering what problems collective human
| intelligence had solved, had we stopped short of encoding
| emoticons in Unicode.
| iainmerrick wrote:
| Sorry to be pedantic, but I think you mean "emoji".
|
| "Emoticons" are the ones built out of letterforms, like ":)"
| rhabarba wrote:
| Technically, emojis are built out of UTF-16 letterforms.
| samatman wrote:
| That is an impressive amount of technical incorrectness
| to fit into one short sentence asserting technical
| correctness!
| crazygringo wrote:
| > _so many writing systems where "cap height" is meaningless_
|
| Can you name any writing system that doesn't have a logical
| equivalent? If you pull up all your examples, a quick
| eyeballing of them reveals there is a clear upper and lower (or
| left and right in the case of vertical scripts) "line" that is
| the obvious equivalent to cap height, even if ascenders or
| descenders sometimes go over it.
|
| If you don't want to call it "cap height" in favor of a more
| inclusive term then you're welcome to suggest one, but the idea
| is generally applicable. It's not ignoring other scripts.
|
| > _Specify it in pixels?_
|
| This is a solved problem, the author presumably meant logical
| pixels (e.g. as used in CSS), not display pixels. Logical
| pixels map to display pixels either 1:1, 2:1, 3:1, etc. or by a
| non-integer ratio when other browser or OS zoom settings are
| used.
| jfk13 wrote:
| Do you really see a clear cap-height (and baseline, to
| measure it from) here? https://software.sil.org/awami/design/
|
| Or look at Thai: https://omniglot.com/writing/thai.htm. Yes,
| there's a pretty clear upper and lower "line", but it's much
| more like an equivalent to ex-height in Latin than to cap-
| height.
|
| Giving it a different name doesn't help: if you put Latin
| text with 16px cap-height alongside Thai text with the "body"
| of the letters sized to 16px, they'll look awful (the Thai
| will be much too big).
|
| (As someone else has already said, ex-height is usually a
| more useful measure for Latin script, and that would be
| closer to matching how something like Thai might be measured
| -- though it'd be a bit on the small side. And it wouldn't
| interoperate well with Chinese, for example.)
| crazygringo wrote:
| > _Do you really see a clear cap-height (and baseline, to
| measure it from) here?_
|
| I absolutely do. Do you... not? You can do a quick web
| search for "Arabic type anatomy" that will make it crystal
| clear for you.
|
| I mean it obviously has nothing to do with "capital"
| letters (so a more inclusive _term_ would be better,
| probably), but there are clear upper and lower "bounds"
| beyond which ascenders/descenders poke out.
|
| The _relative_ sizing of fonts (and line heights) _across_
| languages is a separate issue, and is complex. But it 's a
| disaster in interfaces _today_ , where e.g. traditional
| Chinese characters sized to cap height become virtually
| illegible they're so small.
| taejo wrote:
| > I absolutely do. Do you... not? You can do a quick web
| search for "Arabic type anatomy" that will make it
| crystal clear for you.
|
| I also do not. When I search for that, I find articles
| like https://www.type-together.com/arabic-type-anatomy
| which say things like "Do not use 'x-height' and 'cap
| height' simply because there are no 'x' or capitals in
| Arabic."
|
| So since you do see such a thing, maybe you could show
| us? You could give a specific link or make a drawing.
| crazygringo wrote:
| The article you linked clearly shows lines labeled
| "baseline", "descender", "Latin x-height" and "ascender".
|
| And yes, it says do not use the term "cap height" but I
| _already_ stated that a more inclusive term would be
| better. It 's still obvious what's being referred to.
|
| In current practice (e.g. put roman and Arabic fonts next
| to each other on the same line in your browser), the
| Latin "baseline" and "cap height" lines clearly are
| conceptually equivalent to the Arabic "descender" and
| "ascender" lines.
|
| Do you see it now?
|
| I don't understand how anyone's trying to argue that
| there are languages that don't have obvious logical
| top/bottom boundaries (or right/left for vertical
| scripts) for basing font metrics on.
| insert_coin wrote:
| and em works in arabic and mongolian?
| bsza wrote:
| Tibetan doesn't even _have_ a letter m.
| dylan604 wrote:
| What are M&Ms called in Tibet?
| rhabarba wrote:
| I would meditate over this question, but there is no Om.
| jfk13 wrote:
| AUM is U+0F00 TIBETAN SYLLABLE OM.
| dec0dedab0de wrote:
| Meh, if it were up to me webpages wouldn't have any say at all
| over fonts or colors. When I was 14 I would browse the web with
| no images, and with the colors and fonts overwritten, and it was
| so nice. Then image maps became a thing and it was a pain, then
| javascript, then menus made of small images, then flash, and it's
| just gotten worse and worse every time around.
|
| Now there are webpages that don't work right on a 3ghz single
| core processor with 2 gig of ram, because of some reason that has
| nothing to do with what is best for the user.
| tolmasky wrote:
| Neither pixels nor ems are the right solution, and a side-effect
| of an era of low-resolution screens, what we need is real
| _physical_ units, and not just for fonts, but for every UI
| element. I should be to say that a button is intended to be an
| inch tall (or 2cm or whatever) -- the point is that it should
| have a height relative to reality, not relative to nothing.
| Imagine if anything else worked like dimensions in software: you
| asked for chair 3 feet tall but every maker of chairs had a
| different definition of a foot. This is how points, pixels,
| everything works on the web. And the most important thing to
| remember here is if you still like this system, you can _build
| it_ on top of one that fundamentally relies on real units at the
| bottom. But it is incredibly difficult to do the reverse. CSS has
| "in" and "cm", but they _don 't mean inch or centimeter_. On most
| browsers, "1 in" is defined as 96 (CSS) pixels[1]. _Except_ , if
| you print, then 1 inch DOES mean 1 inch. Which hilariously means
| that if you want to use CSS to lay out something to print, you
| can't tell how it will actually look until you print, because
| there's no "please just render like you would when you print"
| mode. This has been requested, and the classic answer of "who
| would ever want that" was the response. You can with a lot of
| work (and JS unfortunately, unless you pre-generate a huge CSS
| media query for a wide range of screen resolutions) create
| yourself a unit such that 1em = 1 physical unit, but this has
| other issues when you start wanting to do other things in CSS.
|
| Screen UI is the only aspect of design where we pretend that
| precision shouldn't matter. It is stockholm's syndrome. I
| remember how people said that its _fine_ (or better?!) that you
| can 't know "for sure" what font will display on the screen on
| the web. MAYBE it's Times New Roman, but maybe not! You should be
| flexible. This is nonsense. Perhaps that's the reality we live,
| but it's not _desirable_. We shouldn 't fool ourselves into
| _preferring_ that. Clearly if we could make the exact font show
| up it would be a better state of affairs. Again, if you really
| believe font uncertainty is _critical_ to the web experience,
| then by all means, add a script that randomly swaps in a
| different serif font occasionally. Boom, everyone is happy!
|
| Dimensions is the same kind of problem: we're using ideas from an
| age where screen were 256 pixels wide. When you design for print,
| you think about actual size of the produced object. Just because
| someone can resize the window does not mean that the height of
| the letter x should be some abstract unknowable quantity. And
| just because you can set the baseline in size to a specific
| physical size doesn't mean users can't apply a zoom to that. All
| it means is that the language with which we communicate to each
| other is real and not completely different depending on who is
| reading it.
| SavantIdiot wrote:
| I think the funniest part about this this post isn't the lack of
| typesetting among people who work with digital typesetting (there
| should be no mystery between points, em, rem, px if you do this
| for a living, that's 101-level stuff)... instead, it is the
| subtext pointing that the latter of the two complaints that
| spawned this is that vertical centering is still a challenge when
| it really should not be. And I can't help but observe that the
| two are tightly related.
|
| Also, I didn't know the original Mac screen was 72dpi. That is so
| delightful.
| mrob wrote:
| There are three font sizes with valid uses beyond designers
| trying to justify their existence: small, medium, and large.
|
| Likewise there are three valid fonts: fancy (serif or non-Latin
| equivalent), plain (sans-serif or non-Latin equivalent), and
| mono-spaced.
|
| This means only 9 font sizes need to be decided. The software can
| provide reasonable defaults, and a simple UI to allow to user to
| change them, which won't take long.
|
| The only difficulty is when a font doesn't provide full Unicode
| coverage. Full coverage will have to be assembled from multiple
| fonts, which means the sizing won't necessarily be consistent.
| But in this case consistency is already lost, so I see no need to
| further complicate the UI. The user can still tweak things with
| fontconfig or equivalent.
| c-smile wrote:
| > 16 pt text on Windows is 1/3 larger than 16 pt text on macOS.
|
| px != pt
|
| It appears that Windows and Mac browser screenshots are
| misleading at best.
|
| 1px in CSS is logical unit that is equal to 1/96 of inch. On any
| platform.
|
| And so neither 1px nor 1pt have anything with screen PPI (size of
| physical pixel measured by a ruler on screen surface).
| kbelder wrote:
| So a 12px character on a 14" 1080p screen is the same size as a
| 12px character on an 18" 1080p screen? I'm still somewhat
| skeptical, despite fifty posts in this thread claiming just
| that.
| chrisseaton wrote:
| > Instead, macOS always uses 72 PPI to convert points to pixels.
|
| Can't displays report their physical dimensions now? Couldn't
| this be used to restore using a physical dimension like mm for
| font sizes? (Please not inches of all things though!)
| jfk13 wrote:
| It could, but would usually be misused. People would design for
| the size of display and typical viewing distance that they like
| to use, forgetting that these things vary hugely.
|
| (And that doesn't even begin to address the question of what
| part of the font you'd be measuring.)
| kmeisthax wrote:
| macOS already does this at the pixel step, by multiplying the
| entire pixel layout by a scaling term before actually drawing
| the widgets. So effectively, macOS does _not_ use 72 points-
| per-inch, it uses 72 points-per-pixel, and then ensures 1 pixel
| is a particular physical measurement, for the same
| compatibility reasons that caused us to drop device pixels.
|
| The reason why the author is having issues with text sizes on
| different size monitors is that macOS does not support
| _fractional_ scaling; and it 's high-DPI detection is fairly
| limited. A non-high-DPI monitor has no scaling options
| whatsoever, it's locked to 1x. High-DPI monitors are locked to
| 2x; with the additional option to change the desktop's layout
| size and scale the resulting image to achieve the effect of
| fractional scaling. (Apple is _really_ paranoid about
| introducing rounding errors in pixel-aligned layouts, which is
| why they handle non-integer displays this way.)
|
| BTW, if anyone happens to know how to manually flag a monitor
| as HiDPI in macOS Mojave (or if I can do it in Catalina/Big
| Sur), please let me know. I have a 1080p NexDock Touch that I
| have to run at 720p because macOS won't give me the fractional
| scaling options on an external monitor.
| armagon wrote:
| I really wish I could use 1080p with a 1.5x scale factor.
|
| It is worth noting that when Apple was initially developing
| this feature, around the time of Mac OS 10.5 (Leopard), they
| had fractional scaling. I thought it was awesome. I can only
| assume that some artists felt it was not awesome. (I'm going
| to stop googling for this now, but I think 'Resolution
| Independence" is a key phrase that will help in finding it if
| you are interested).
|
| As for HiDPI mode, I know I've done it in the past for
| external displays, but I haven't been able to get it to work
| with my 1080p displays using Big Sur. I think this might've
| been the most useful link I've come across: https://www.reddi
| t.com/r/hackintosh/comments/jh6pjd/hidpi_on... . If you do
| manage to get it to work, a toolbar app like ResolutionTab or
| EasyRes is then a big help for changing between modes.
| kmeisthax wrote:
| The reason why Apple doesn't do fractional scaling is
| rounding errors: if you have a design that's aligned to the
| pixel grid at 1x, it's only guaranteed to remain aligned to
| that grid if you scale by other integers. If you aren't on
| the pixel grid, then the layout engine has to round sizes
| up or down to fit, which is dangerous. You're adding error
| to layout and then multiplying it by the number of elements
| being sized.
|
| This gets particularly bad on the web, where a number of
| different tricks have been employed by browser vendors over
| the years to avoid rounding errors (see
| https://www.palantir.net/blog/responsive-design-s-dirty-
| litt...). If you have, say, a float-column layout with
| percentage widths, then rounding errors can easily wind up
| making things either not line up or, worse, _actually
| overflow their containers for no reason_ , breaking the
| layout. Throwing non-integer scaling into the mix makes
| this even worse.
|
| Of course, this is a tractable problem, but it was much
| easier for Apple to just render-and-downscale from the
| nearest whole-number factor instead of making the lives of
| any developer with custom layout engines that much harder.
| chrisseaton wrote:
| I don't get it - why does alignment matter when pixels
| are so small you've got no hope of seeing if something is
| aligned down to such a small measurement or not?
| dfox wrote:
| They do and in fact both X11 and Windows are capable of using
| that information to scale font pixel sizes appropriately. In
| both cases this mostly defaults to off and fixed DPI for UI
| font layout because the result of non-default display DPI leads
| to either the result looking wrong/ugly (blurry text, thickness
| of font strokes disproportionate to other UI elements etc) or
| even unusable (there is edge case in Win32 UI where one way to
| create non-resizable dialog-style top-level application window
| causes its contents to scale with DPI, while size of the window
| itself does not -> you get UI elements that are cliped outside
| of the window).
| [deleted]
| crazygringo wrote:
| This is a fantastic article and I welcome this conversation.
|
| As the author states, sizing of fonts and line spacing is
| currently inconsistent across OS's, inconsistent across fonts,
| and inconsistent with other UI elements.
|
| It's madness. There's no good reason for _any_ of it except
| inertia and lack of forethought.
|
| The author's proposal to specify _cap height_ is really the only
| reasonable solution I think there is, though I 'd modify it
| slightly:
|
| - When defining cap height, be clear what the logical obvious
| equivalent in other scripts, e.g. Chinese logogram height
|
| - Specify cap height in whatever unit other UI elements are
| specified in (the author refers to pixels, but that's arbitrary)
|
| - Then line height can also be controlled predictably and exactly
| in whatever unit UI elements are specified in
|
| End result: zero inconsistencies. Text shows up exactly where
| it's meant to no matter what.
|
| How do we get there? Browsers should adopt it first, with
| something like a CSS "font-cap-size" property that can be used
| instead of (and override) "font-size", as well as something like
| "cap-line-height" overriding "line-height". (And for units,
| recommend using "px", or "rem" ultimately based on a root "px",
| and never touching "pt".)
|
| Then OSes can migrate similarly with new function
| calls/parameters based on cap height, and also try to phase out
| "pt" sizing in preference of the logical "px" sizing used in the
| rest of interfaces.
|
| I really think this is the way. I really hope browsers and the
| W3C can consider something like this. It's _decades_ overdue.
| fuzzer37 wrote:
| Does anyone really... care? I can't remember ever getting upset
| about font sizing. If it's too small to read make the font
| bigger, if you wanna fit more on the screen make it smaller.
| ddevault wrote:
| Something any proposal of this nature tends to be missing is an
| inquiry into the implications for non-English langauges.
| rhabarba wrote:
| You mean, like German?
| zweifuss wrote:
| Ss (capital sharp s; added to Unicode in 2008) and even the
| much older ss (eszett) are not included in all modern fonts.
| Sometimes Eszett is simulated with a lowercase b sign even
| today. Often its size doesn't match the ASCII characters.
| rgovostes wrote:
| Relatedly, it's really lame that many apps have an "Actual Size"
| zoom option (that's [?]0 to you Mac Safari users) that doesn't
| mean anything. If I create a word processor document with a 11"
| tall page size and zoom it to "Actual Size," I should be able to
| hold a sheet of US Letter up to the screen and have it match
| perfectly, but it is much too small. Displays (except projectors)
| provide physical dimensions via EDID metadata, which can be used
| to compute the correct scaling factor.
| dylan604 wrote:
| >(that's [?]0 to you Mac Safari users)
|
| Or a lot of other Mac apps. Adobe software has had [?]0 for
| longer than Safari has exisited followed by [?]-/[?]+ for
| zooming out/in. FF does it as well
| barry27 wrote:
| I thought this was going to be about webapps.
|
| Surely anyone who has a hankering to do some work just fiddles
| around for a few minutes with their editor until they get
| something they like and then gets on with it and doesnt ever
| think about it again.
| Tenal wrote:
| "So user requesting 32 pt font is actually requesting 32 px on
| macOS and 43 px on Windows. But these numbers are still nowhere
| to be seen."
|
| Is that first sentence poorly written or is this some crazy
| English grammatical clause I have yet to encounter.
| lucideer wrote:
| Worth noting this article is discussing OS-level native app font-
| sizes, and is quite separate to discussions of CSS `font-size` on
| the web, for which this "problem" is well-known and `px` is the
| commonly used unit.
|
| Also:
|
| > _P.S. VS Code seems to take editor.fontSize value directly in
| pixels. That's a start!_
|
| I presume this is just the result of VS Code being
| Electron/HTML/CSS, rather than MS deliberately "fixing" the issue
| explicitly for this app.
| PaulHoule wrote:
| Font metrics is a super-complex topic.
|
| I have been digging into old Word documents and it's started to
| dawn on me why Visual Basic "worked" as GUI builder in a time
| when its competitors didn't... The font metric system in Windows
| 95 gave great control, with the ability to position individual
| characters and more configuration choices (e.g. strikethrough)
| than most web browsers today.
|
| It is way "beyond state of the art" to change the typeface in
| your text editor easily and have it work.
|
| I have lately been doing a project that involves printing onto
| cards with bitmaps I make with Pillow, and you learn pretty quick
| that there is no such thing as a "unicode font" but instead you
| have to patch up your own "unicode font" by putting together a Ri
| Ben Yu font with a nice Latin font, and not worrying about other
| languages until I have to print them... The web browser and other
| high-level tools do it automatically but they don't do well.
| spiznnx wrote:
| The only "unicode font" I know of is the Noto family.
|
| > Noto helps to make the web more beautiful across platforms
| for all languages. Currently, Noto covers over 30 scripts, and
| will cover all of Unicode in the future.
|
| https://en.wikipedia.org/wiki/Noto_fonts
| Moru wrote:
| I have some memories of zooming into a word document and the
| space occupied by the text was not the same any more... I
| forget what OS it was running but W95 or earlier is likely.
| jfk13 wrote:
| Ah, yes... the good ol' days when changing your selected
| printer driver could also cause Word to reflow your entire
| document (because it affected the font metrics) and suddenly
| your carefully-tuned page breaks and figure placements were
| all wrong.
| [deleted]
| thayne wrote:
| > Specify cap height, not em square size.
|
| I'm curious how that would be accomplished. There is nothing that
| requires a font-maker to have a consistent cap height in a font.
| JoshTriplett wrote:
| The concept of changing "line height" seems completely broken for
| monospace fonts. Changing the line height of a monospace font
| makes line-drawing characters (lines, boxes, etc) fail to line
| up, either by overlapping or by having gaps between them.
|
| This gist shows an example of the problem; GitHub's CSS breaks
| this property of monospace fonts:
| https://gist.github.com/joshtriplett/dc2446716999c54cc9a5c48...
| kevincox wrote:
| I agree, by default I would want to trust the line height of my
| font designer, just like I trust their letter spacing. I very
| rarely use multiple fonts on the same line (maybe a monospace
| font for inline code?).
| JoshTriplett wrote:
| Right. If you're mixing multiple fonts on the same line, the
| default should be the maximum line height of the fonts,
| unless overridden.
| grenoire wrote:
| This is also a very big pet peeve of mine, Mr Author. I'm
| honestly more frustrated when I want to have multiple systems
| with different fonts at least look similar in 'space occupied,'
| whereas the lettering being slightly different is just... really
| a whatever matter.
| neura wrote:
| I can't be the only person looking at the top of the article,
| thinking "but if you just add the descender and ascender values
| together (the total height of the character, not the block space
| that it occupies), you get almost 32."
|
| I'm guessing if you even slightly tweak the way the measurements
| are being taken, you'll get 32. even if you just assume "always
| round up", you get 32.
|
| This is one of the strongest cases of manipulating data by
| providing a bunch of data points to obscure the one point,
| enabling belief in "well, they provide all this data and none of
| it is 32, so they must have a solid point here!"
|
| This misleading opening really just makes me want to avoid
| reading the rest of the article. I hope there wasn't any real
| information hiding behind that facade. :x
| setr wrote:
| That's an absurd take... the article's first paragraph is quite
| clear he's going to tell you exactly where that 32 ran off to,
| and despite your random arithmetic that happens to find the
| number with no double-checking whether it works on any other
| font-size or font (equivalent to finding your birthday in
| license plates, by arbitrary manipulations of the numbers
| available), it turns out the 32 is in fact missing from any
| visible artifact of the font.
| kybernetikos wrote:
| Sometimes I want to:
|
| 1. size based on how big it is in the real world - mm (but
| accurate!)
|
| 2. size based on user preference - rem?
|
| 3. size based on how large it appears to the eye - angle
| subtended on the retina (displays that don't know this can assume
| an average distance to the eye different for desktop, mobile,
| jumbotron, etc and work it out from their size)
|
| 4. size based on the kind of interaction the user will have
| (touch / mouse / eye / point) - some kind of new unit based on
| Fitts law - or should this just be a bunch of special cases?
|
| 5. size based on proportion of the available space - % vh vw
|
| I basically never need to size based on some other factors but
| maybe they have a use:
|
| 1. size based on the minimum resolvable size (i.e. the smallest
| something could be without losing definition). I guess this is
| much more of a concern if you're using a lot of very low
| resolution screens - px (but _actual_ )
|
| 2. size based on the size of the whole document (including
| document that isn't visible)
|
| Of course this is all made extra complicated by the fact that
| sometimes containers need to be sized based on concerns bigger
| than them, while sometimes they're sized based on the sizes of
| their contents. And whatever framework you're using is probably
| bad at exposing key pieces of information about e.g. 'how much of
| this text can I get in this width'
|
| Unfortunately operating systems tend to have little clue about
| how big in the real world their display surfaces are, they are
| even less clueful about how far away the user is. Everything
| seems to be based on an early assumption that what was important
| was the dots on the screen, and as that assumption has proven
| false, instead of attacking the problem in a principled way,
| we've just created scaling fudges on top of pixels to take into
| account higher quality, user 'zoom' preference etc.
|
| In the hypothetical ideal world, I'd set my IDE editor font
| setting to a subtended angle setting and switch between desktop
| and laptop displays, upgrade the resolution of my screen, or the
| size of my screen and never have to change it.
| hyakosm wrote:
| The article points to an interesting UI bug in macOS, text
| alignment in buttons is weird. Cf
| https://grumpy.website/post/0UfwgmMDe
| hyakosm wrote:
| There is a issue of the incoherence of this behavior in Big
| Sur. Example: on my screen, in the menubar, vertical alignment
| of menu items (File, Edit...) is not the same as date & time
| widget (slightly upper). I don't know if it's because of my
| non-Retina screen and the lack of optimisation in recent macOS
| in this regard.
| CharlesW wrote:
| I'd bet this was done on purpose, since the optical centering
| of "Revert" is improved by this change.
|
| However, Apple should reduce this optical offset for smaller
| buttons with relatively larger text, e.g. those in the
| Bluetooth System Preferences panel.
|
| The side-effect is that all-caps button text is no longer
| optically-centered, but that's a relatively-rare case other
| than the "OK" button.
| SamBam wrote:
| I have a similar issue on the web.
|
| I have a library, which adds DOM elements and some text to the
| page. The library _expects_ a certain font to be loaded on the
| webpage. (This is an internal project, so is usually the case,
| but not always.) Obviously there are fall-back fonts if not, but
| those fallback fonts happen to be a different size given the same
| font-size specification, and so everything looks like crap.
|
| The obvious solution would be to throw away the custom font. But
| if we really want to keep it, the only solution is to load the
| page, _then_ measure the width of the text, _then_ we know if the
| right font is loaded, and if it isn 't then tweak the styles so
| things line up better.
| VWWHFSfQ wrote:
| > I am using Sublime Text 4 on macOS
|
| did I miss when sublime text 4 was released? I'm still on 3
| jd3 wrote:
| Sublime Text 4 is under private alpha for users with a paid
| license.
|
| https://gist.github.com/jfcherng/7bf4103ea486d1f67b7970e846b...
| VWWHFSfQ wrote:
| oh cool
| pier25 wrote:
| Oh wow had no idea.
|
| Anyone knows what the major changes are compared to v3?
| trinovantes wrote:
| Oh man, I'm still on 2. I wonder if I can still get discount
| upgrade from 2->4
| amelius wrote:
| Perhaps use a different name for it, so we can have both?
|
| So e.g.: "font-size" is the old behavior, and "font-height" is
| the new behavior.
|
| By the way it would also be nice to be able to specify the height
| of lowercase letters, e.g. "font-lowercase-height".
| enriquto wrote:
| I long for the time where we used crisp, non-scalable, beautiful
| bitmap fonts. So called "anti-aliased" fonts look always
| irremediably blurry.
| Gualdrapo wrote:
| I'm still using custom bitmap font for monospaced things (text
| editor, console and such). No antialiased thing has made me
| changed my mind - bitmap fonts just look so crisp and sharp and
| readable.
| mcguire wrote:
| "500 years of typography is useless; let's throw everything out!"
|
| " _Also, I see no reason to honor the so-called "default line-
| height". It's basically a font designer's personal preference,
| imposed on every user of the font in every viewing condition._ "
|
| Yes, that would be "font design".
| ectopod wrote:
| I typeset a scanned and ocred copy of an old book. It used a
| moderately common font except with extremely narrow line
| spacing. None of the tools I had supported a line spacing
| narrower than the spacing chosen by the font designer, so I had
| to create a hacked version of the font to make it work.
|
| Traditionally, the leading was separate from the type. Nowadays
| it isn't, and that can be a huge pain in the bum.
| JxLS-cpgbe0 wrote:
| Is this app-development specific? In CSS the font-size and
| leading are easily decoupled.
| ectopod wrote:
| I'm not sure what you're asking. As a software developer,
| supporting negative leading isn't hard, but as an end user
| (as I was in the example above) that's no help if the
| software developer hasn't done the work.
| jancsika wrote:
| Here's a simple issue that I've never figured out:
|
| 1. Create an svg
|
| 2. Draw an svg rectangle in there
|
| 3. Draw an svg text "Hello World" so that it _fits inside the
| rectangle_.
|
| 4. Make sure #3 above works regardless of which platform/browser
| you are using.
|
| Now, I don't see it as a catastrophic problem that I can't
| (easily) automate everything up to step #3. I mean, maybe I
| _could_ by iterating over various sizes inside an offscreen HTML5
| canvas and measuring the results or something. But it isn 't the
| end of the world to, say, just guess and check in a browser until
| I hit the right pixel size.
|
| Problem is, that rendered result tells me absolutely _nothing_
| about what will render on other platforms. Maybe OSX will eat
| less horizontal width. Hell, maybe some troglodyte who lives deep
| in the guts of Gnu font rendering stack makes a change that
| accordions out the horizontal width so it 's way out of whack
| with Windows and OSX. There's no spec that says a troglodyte
| can't do that. (This all holds for fixed-width fonts the same as
| variable width, btw.)
|
| It's weird because I see all these SVG frameworks that have demos
| with, say, a graph where text _looks_ to be aligned so that the
| end of a label doesn 't overlap with a vertical line. But there's
| never a caveat given-- if there were, it should be that SVG
| _cannot_ guarantee there won 't be an overlap there, because it
| cannot control the underlying font engine that way. You
| _literally_ have to check with your eye on every platform that
| you want to support[1].
|
| Edit: clarification
|
| Edit:
|
| [1] You can't even simply check for each different font stack--
| you have to check every extant version of that stack. Because
| again, a font stack can make a lot of arbitrary changes from
| version to version.
| jfk13 wrote:
| Are you explicitly using a linked/embedded font resource, so
| that you control exactly what font is used to render the text?
| If not, there's certainly no expectation of uniformity.
| perardi wrote:
| Agreed. I simply would not expect this to work properly if
| you don't specify a font. Just compare Times New Roman and
| Verdana, two fonts that are broadly available, and broadly
| different in terms of character widths. Verdana will probably
| bust out of that container.
|
| Maybe if we had container queries, and could set font size as
| a...container unit? I don't even know what to call it. Like
| vw and vh units, but relative to a parent container.
| SpaceNugget wrote:
| would that not just be `%`?
| perardi wrote:
| Wait, like this?
|
| https://codepen.io/cperardi/pen/VwPmMrM
|
| I would have no expectation _at all_ that would work without
| specifying a specific font. Fonts just have different
| horizontal metrics. That doesn 't seem to be a bug, so much as
| "fonts are different, if you want very specific space-
| constrained rendering, you should explicitly specify a font,
| and ideally serve it so all platforms get the exact same font
| metrics".
| perardi wrote:
| (Or convert to outlines, and then embed some sort of metadata
| for accessibility and machine readability. But that's
| probably overkill.)
| svachalek wrote:
| That should be easy!
|
| https://www.amazon.com/CSS-Awesome-Mug-Programmer-Developer/...
___________________________________________________________________
(page generated 2021-03-30 23:00 UTC)