[HN Gopher] Typescale: A tool for easy CSS typography
___________________________________________________________________
Typescale: A tool for easy CSS typography
Author : surprisetalk
Score : 127 points
Date : 2023-05-19 11:15 UTC (11 hours ago)
(HTM) web link (typescale.com)
(TXT) w3m dump (typescale.com)
| myfonj wrote:
| Looking at those typographic scales in context of modern
| computers always makes me wonder, why everyone adhere to original
| "letterpress" constraints?
|
| Nothing against proven crafts when they serve well, yet all
| "typographic scales in CSS" I've seen so far always operated
| almost exclusively on font-size / line-height and seldom letter-
| spacing, almost never font-weight and never used other visual
| clues for expressing hierarchy and rhythm like decorative
| ornaments, different shades or even palette or some other
| creative tricks. Those are techniques that _are_ sometimes used
| in the wild, built organically, but I have never seen them
| analysed in isolation, some colour theory telling that "you
| either bump-up font size by this factor or increase contrast
| between background and text to get such and such level of
| urgency".
|
| What I find most strange is that, seemingly, everyone is fine
| with conveying the same information using two and more ways in
| parallel: size, visual contrast and disruptions in vertical
| rhythm. Making part of text bigger makes it stand out on it's
| own, since it disrupts vertical rhythm around it and also shines
| with thicker strokes. Side-effect of this is more visual
| contrast, something I'd call "pressure".
|
| It is mostly _the absence of content_ what constitutes the
| hierarchy -- the space around headings, indentation etc -- not
| the local "pressure" of the letters in headings. From my
| subjective perspective large contrasting text very often
| "screams" in my head.
|
| Some time ago I've tried if would be possible to normalize that
| optical pressure across sizes (without changing weight); this was
| the result: https://codepen.io/myf/pen/oNLKzNY
|
| In short, I think we should try to "tone down" blocks with large
| text when we have the opportunity, like:
|
| (edit HN discards block element characters; think large square in
| "lighter" shade followed by two "heavier" lines of the same width
| below)
|
| rather than keeping it same, like:
|
| (think large square followed by two lines below, all of same
| shade, so the compact area of the square stands out even more.)
| chrismorgan wrote:
| This is something that I'd say should mostly be handled in the
| font, and nowhere else. Variable fonts have the _optical size_
| (opsz) axis, which you can use to tweak things like glyph
| thickness and tracking based on the font size. It's like full
| hinting used to be, but even better. I'd like to see operating
| systems move to defaulting to fonts that work this way.
|
| I find your example interesting, but I _hate_ things overriding
| letter-spacing like that, because it generally looks bad, and
| definitely looks bad in my chosen fonts. Need to finish off my
| article railing against people changing letter-spacing on body
| text, which is _ridiculously_ common and _always_ a bad idea.
| Line-height you take a bit too far, but the general concept of
| "larger text means smaller line-height" is one I wish more
| people understood. I've become partial to `* { line-height:
| calc(1em + 0.5rem) }` in the last year, which I find to work
| quite nicely as a single definition. For colour, it's an
| interesting thing to consider, but I think it's mostly the
| wrong solution--optical size s the proper solution for most of
| it, and my experience is actually that larger text normally
| wants to have a _stronger_ colour rather than a weaker, because
| it's a heading. But the interactions between font sizes and
| contrast in various guises is absolutely relevant, and I'm glad
| that the successor to WCAG's terrible colour contrast
| technique, APCA (Advanced Perceptual Contrast Algorithm), takes
| font size into account in considering what makes for acceptable
| contrast.
| simonbw wrote:
| I hadn't seen musical intervals used to express ratios between
| things that weren't pitches, but I think it's an interesting
| idea. I guess all they really are is a nice name for specific
| ratios, so it makes sense that they could be useful in more
| contexts. Has anyone seen them used in other interesting
| contexts?
| antidaily wrote:
| Any CSS for type that's not using clamp() for fluid scaling seems
| like a waste of time. Demo looks nice on desktop though.
| moritz wrote:
| clamp() is not supported by browsers merely three years old.
| silverwings wrote:
| The tool currently generates CSS where the font sizes are
| assigned in descending order to h1, h2, h3, h4, h5, and h6 tags.
| However, this approach may lead users to mistakenly assign the h1
| tag to the largest heading, rather than the most significant one.
| According to W3C accessibility criteria, HTML offers six levels
| of headings, with h1 being the most important and h6 the least
| important. It's crucial to adhere to these guidelines for optimal
| accessibility.
| SquareWheel wrote:
| I can see this being useful for creating pleasing ratios between
| font sizes. Though I feel this may be less useful today than in
| the past. Headers, navs, and other elements often require
| responsive font sizes to adapt well to all screen sizes. You
| could still maintain a ratio if using a container query of the
| full document, but it's usually not a good idea to scale the body
| font more than a couple points up or down for readability.
|
| I think this tool may be good for documents with careful
| typesetting and layout, but maybe not modern, interactive,
| responsive pages.
| bromuro wrote:
| I disagree, changing the text size to adapt it to your eyes is
| a feature in every browser.
| SquareWheel wrote:
| If you're talking about the browser zoom feature, then I
| don't believe any website should require you to use that to
| make the contents legible.
|
| If that's not what you're saying, then you'll need to
| clarify.
| layer8 wrote:
| The variation in display devices, environmental conditions,
| and quality of eyesight are large enough that that's
| virtually impossible.
| asb wrote:
| I'm currently using the 'minor third' scale on my site muxup.com
| (mainly because I didn't know what scaling to use and I saw it in
| use somewhere else). It seems fine, but I've found the headings
| aren't visually distinct enough if they're not right next to each
| other (i.e. it's hard to visually distinguish a h2 at 2.488 rem
| vs an h3 at 2.074rem). Perhaps I've chosen a bad scale, or
| perhaps I should be adding other visual markers to help
| distinguish the heading level?
| surprisetalk wrote:
| I see a lot of cool sites in your HN profile! Which one are you
| talking about?
| asb wrote:
| Edited to explicitly mention muxup.com - you won't see any
| current articles using nested headings (i.e. h3 in addition
| to h1 for the article title and h2 for article headings) as
| every time I've used one I've not liked how hard it is to
| differentiate, and haven't invested the time in revisiting
| the CSS to fix it.
| surprisetalk wrote:
| Love that rounded font! And the site looks great.
|
| I just changed an H2 tag to an H3, and it looks like your
| H3 is way too small.
|
| One thing I've seen for H3 and below is to use `font-style:
| italic` and font-weight 500 to distinguish it from the H2.
| I don't think that would work for your site though.
|
| For your site, you could maybe throw a `color: #444` on H3
| and below? You can also try `h1, h2 { margin-left: 1em }`.
| asb wrote:
| Ah, that's because my static site generator only includes
| "needed" CSS directives, so if the page doesn't have h3
| then this isn't included (I know, classic premature
| optimisation): h3 { font-
| size:2.074rem }
|
| Playing with font weights or color is a good suggestion,
| thanks.
| john-doe wrote:
| Some good advice:
| https://practicaltypography.com/headings.html#:~:text=Certai...
| chazeon wrote:
| > It's fine to make the point size bigger, but just a little.
| Use the smallest increment necessary to make a visible
| difference. If your text is set in 12 point, you needn't go
| up to 14 or 15 point. Try a smaller increase--to 12.5 or 13
| point.
|
| This is great advice. This is exactly what i think so many
| web design failed to follow, e.g. bootstrap.
| lisrjflksdjfi wrote:
| Is the current bleeding edge CSS techniques to base everything
| off a base "px" value?!
|
| I would imagine things would have progressed to have decent
| points or some other measurement based on screen actual size by
| now.
| kroltan wrote:
| Well, CSS pixels are not literal device pixels, they are kind
| of like the Android "device independent pixel" measurement.
|
| The exact definition evades me since it's been a couple years I
| did any web development, but your px-based sizes won't look
| tiny on high-DPI screens.
| tracker1 wrote:
| 72/inch iirc.
| dtagames wrote:
| The current best practice is to use "em" measurements, where
| 1em is the size of the base font and zoom you've selected in
| your browser. Other measurements are scaled from there, so 2em
| is twice that size and .5em is half, etc.
|
| In reality, the browser will use a variable number of pixels
| (and even device subpixels) to actually render the font or div
| -- but if you use all "em" measurements, all those sizes will
| have the same relationship to each other on the final device.
|
| The 16px in the demo comes from the default base font size in
| the browser, which has 1em = 16px.
| lisrjflksdjfi wrote:
| You just expanded on my poorly worded question :)
|
| so, yes, it is still all based on a "base pixel value, that
| is not really a pixel".
| chrismorgan wrote:
| Only partly, and not the part that dtagames was speaking
| of.
|
| There are three families of distance units.
|
| One is _absolute length units_ <https://www.w3.org/TR/css-
| values-4/#absolute-lengths>. px is the _canonical_ one of
| these, but it may be _anchored_ to physical measurements
| (typical in print) or the reference pixel (which in
| practice is generally approximated by some number of device
| pixels multiplied by a scaling factor from the operating
| system).
|
| Then you get _viewport-percentage lengths_
| <https://www.w3.org/TR/css-values-4/#viewport-relative-
| length...>, of which I will not speak, save to note that
| they're broken by design so that they're almost completely
| useless for _layout_ purposes.
|
| Then you get _font-relative lengths_
| <https://www.w3.org/TR/css-values-4/#font-relative-
| lengths>. The _em_ dtagames speaks of is one of these. The
| root em, _rem_ , is commonly used as a base, and is _most
| commonly_ 16px, but it depends on a variety of factors like
| user preferences, the root font-size, the root font-family,
| and the root language. It's very messy and even mildly
| context-dependent.
|
| Most lengths should _generally_ be font-relative for most
| perfect compatibility and user-preference-acceptance, but
| doing this perfectly is harder than it may sound.
| paulddraper wrote:
| https://web.archive.org/web/20230325144112/https://typescale...
|
| P.S. CDNs can keep your site up at near zero cost.
| gnrlst wrote:
| Just a bug I noticed: the lowest two sizes (0.64rem and 0.512rem)
| displayed on the settings panel, are not part of the outputted
| CSS.
| chrismorgan wrote:
| The major problem with these kinds of tool is that they don't
| explain why there is any _virtue_ in the scales produced. My
| answer to that: _there is none_. Ever. In fact, I would go so far
| as to say that consistent geometric or modular scales like these
| are normally _bad_ (though I won't say always), and this kind of
| consistency actively undesirable, because our eyes and minds just
| don't work that way, but value asymmetry and obvious differences
| in parsing and gathering information. You either end up with
| insufficient distinction, or grossly excessive variation.
|
| That's why you might do things like this (which I provide as an
| example of something reasonable, not as the only way of doing
| things):
|
| 1. Page title: positively huge (e.g. 4rem/64px/48pt). Probably
| not bold (though I freely invite you to use inline styles inside
| the title, something nowhere near enough people do).
|
| 2. Heading: quite large, and with a large gap before it (e.g.
| 2.5rem/40px/30pt, plus margin-top of 1.5em/60px and margin-bottom
| of 1rem/16px). Maybe bold, maybe not.
|
| 3. Subheading: somewhere between heading and body text in size,
| and perhaps with a decent-sized gap before it when not preceeded
| by a heading (e.g. 1.5rem/24px/18pt, margin-top 1.33em/30px and
| margin-bottom of 1rem/16px). Probably bold.
|
| 4. Subsubheading (rare) and certain sorts of captions (e.g. on
| figures and asides): normal size and distinguished by _style_
| instead. (e.g. 1rem /16px/12pt, but bold, and perhaps with a
| larger gap above.)
|
| One thing covered incidentally in this sample scheme is the use
| of asymmetric margins to visually separate sections. That's
| normally a good idea, but for some reason people don't often try
| to fit it into their neat mathematical constructions--though you
| _will_ note this tool's sample area using such asymmetry
| unremarked. Probably because their formulae are arbitrary anyway.
|
| Another thing to note is that for general typography you don't
| need many levels. As far as major sizes and styles are concerned,
| I'm sceptical of any general-use model that goes beyond five
| (title, heading, subheading, caption, body text). As far as
| headings are concerned, if you're using more than title + two
| more, you should probably reconsider your content structure.
|
| Cast off the tyranny of typographical scales. They have the
| appearance of wisdom in promoting rigour, but they are of no
| value.
| leroy-is-here wrote:
| > You either end up with insufficient distinction, or grossly
| excessive variation.
|
| That's the point of scales -- to provide structure to any scale
| of values so there's distinction without excessive variation.
| chrismorgan wrote:
| I'm saying that geometrical scales are precisely what end up
| with at least one of those two problems. If the ratio at each
| level is too small, then the first few up from your base text
| size are too close to body text to be usable, and so people
| go _skipping_ levels, even though that obviously corrupts the
| mathematical purity of the concept. If the ratio at each
| level is enough to make them useful, then you get too big
| (and too small) too quickly.
|
| The only reason their values might _seem_ to make any sense
| is if you have this weird idea that you should support at
| least five or six levels of headings. You actively shouldn't.
|
| Take the scale of 1.250 (the default of this tool). -1 is
| riskily small for _any_ purpose, and -2 should never be used.
| +1 isn't big enough for any kind of heading. +2 to +4 are
| reasonable heading sizes, but aren't different enough from
| each other. +5 might be OK as a title, but very often you'll
| want to go bigger. Depending on content, it might do for a
| heading style too.
|
| Another mildly popular value: ph, 1.618. -1 is already too
| small for any purpose. +1 is decent for a subheading level,
| and +2 for a heading, and +3 for a title. (+3 is normally too
| big for any sort of heading; +4 could also be reasonable for
| a title.) But at that point you have only about four usable
| values, and where was the virtue in using a scale for them?
| You could have chosen more suitable values manually.
| [deleted]
| leroy-is-here wrote:
| Yeah, that's probably true. I only use 3 levels of headers
| on my website.
| mikojan wrote:
| > But at that point you have only about four usable values,
| and where was the virtue in using a scale for them?
|
| The virtue was in drastically reducing the space of correct
| answers.
|
| How long would it take the average developer to pick sizes
| out of an infinite number of sizes? And how long would it
| take them to pick sizes out of a small number of sizes?
|
| I know I do not want to fiddle with an infinitely large
| problem space.
| dimmke wrote:
| The default font size is 16px. You can scale it down to
| 12px for mobile viewport sizes and up to 18px for extra
| large and then use relative sizing for everything,
| including the text size of all the elements on your page.
|
| There's a well known book called The Elements of
| Typographic Style that deals with text size (among many
| other things.)
|
| This scale isn't helpful because it's arbitrary and based
| off of math percentages. And the actual values are just
| decimal values. 1.25, 1.33, etc...
|
| It's not any better than eyeballing, and could in fact be
| worse, where a heading size might actually look better at
| 1.3rem instead of 1.33rem but because you're forcing
| yourself to stick to math you are using a size that is
| slightly too big.
|
| And if you are looking for someone to have done this work
| for you, I'd recommend using Tailwind which has good sane
| defaults for many elements of typesetting:
|
| - https://tailwindcss-typography.vercel.app/
|
| - https://tailwindcss.com/docs/typography-plugin
| chrismorgan wrote:
| > _The default font size is 16px._
|
| No, it's not. You don't statically know what the default
| font size is, because it depends on various user
| configuration and document language. For English text,
| it's _mostly_ 16px, but there are devices where the
| default is higher or lower.
|
| > _You can scale it down to 12px for mobile viewport
| sizes_
|
| Please don't. I'd advise against going down to even
| _15px_ ; 12px is madness, you should basically never have
| _any_ text that small.
|
| > _I 'd recommend using Tailwind_
|
| Eh, dubious for web _sites_. Tailwind is very clearly
| designed for and targeted at _apps_ , and makes all kinds
| of decisions that are not suitable for general-purpose
| websites. It's not _terrible_ , since there have been
| enough people wanting to use it for general-purpose
| websites that they've made it tolerable, but it's still
| going to be at least mildly painful to work with, because
| its _actual_ defaults are deliberately extremely stupid,
| and adapting it to this kind of work requires effectively
| overriding quite a lot of stuff. (Disqualifier: I've
| never actually worked with Tailwind in anger, because I
| hate most of its defaults and near-defaults, and it just
| doesn't match how I like to work philosophically, which
| is a pity, because I could quite enjoy working with
| something not far off it for some purposes. But a lot of
| the way it treats things like colour and dark mode is
| just objectively a terrible way of doing things--they
| designed themselves into a corner and insist on using
| tools they designed like an abundance of modifiers, even
| when they're _clearly_ inappropriate.)
| dimmke wrote:
| I'm not going to respond to most of what you wrote, but
| the main point of my comment is that it is generally
| accepted practice to size text along a scale, when
| deciding different text sizes in a document, and
| Tailwind's text sizing defaults with their typographic
| plugin are widely used and considered acceptable.
|
| You don't even have to use Tailwind, simply open the demo
| and look at how they scale the text size and line height
| on different elements. You could pull the computed styles
| from your browser.
|
| You and I agree that using arbitrary numbers is
| pointless. You clearly have a lot of other strong
| opinions I don't care to debate with you about.
| mikojan wrote:
| I am using Tailwind. It is great.
| chrismorgan wrote:
| It reduced the space by _arbitrary choice_. You are just
| as capable of arbitrarily choosing four numbers as one
| ratio. I believe in you, though I don't know you. In
| fact, I believe you will do a _better_ job in your
| arbitrary choice of four numbers than in your choice of
| one scaling factor.
|
| Although the four values from ph are _usable_ , they're
| unlikely to be _excellent_ for the purposes of anyone in
| particular. You can easily choose more suitable, and will
| if you consider your content and intended design rather
| than just slapping a number on it.
| mikojan wrote:
| > Although the four values from ph are usable, they're
| unlikely to be excellent
|
| I am not a designer. Excellence is not for me by any
| stretch of the imagination.
|
| It sounds like you have not yet figured that one out for
| yourself and are maybe severely misjudging your own
| capabilities. It is just absolutely, completely bonkers
| to suggest anybody can "easily" pull off "excellent"
| rhythm, space, dimensions, design.
|
| "Just pick up the saxophone, wiggle your fingers, and off
| you go, Coltrane!"
|
| What in the actual what are you talking about
| chrismorgan wrote:
| Very well then, I shall call the four values from ph
| lacklustre and uninspired; yet people have occasionally
| presented them as though they have objective value or
| virtue, which I deny. I say that if you possess the
| wherewithal to choose that value to compute your font-
| sizes from (which is far from trivial, and there's no
| reason why you would think it's any good unless someone
| told you it was and you believed them), you can choose
| four values that look good to you, possibly based on
| recommendations from others just like you surelyl did
| with ph, and get a result that is likely to be at least
| as good.
|
| We're comparing _font-size values for headings_ , not
| anything more in the design. I didn't say anything about
| pulling off excellent rhythm, space, dimensions or
| design, nor would I.
| pers0n wrote:
| I was hoping it was for baseline rhythm, something CSS needs
| badly
| chrismorgan wrote:
| Why?
|
| (Honest question. I've toyed with it in minute detail a couple
| of times over the past decade, but for fun or as part of
| matching a lined-paper aesthetic. Not because I think there's
| any inherent virtue in it, because I _don't_. So I'm curious
| why you think CSS needs it badly.)
| pers0n wrote:
| Because the current methods to it are very complicated and
| only work with a few fonts. A reliable baseline rhythm would
| lead to better typography and sense of visual order.
|
| More calm More orderly Easier to read More professional
| chrismorgan wrote:
| Ah, I think you copied the list from
| https://zellwk.com/blog/why-vertical-rhythms/. It says
| these might be properties of "better", largely without
| quantifying what they mean, as part of comparing something
| with simple rhythm (and quite ugly in its spacing, in my
| opinion) with something that's deliberately _terrible_.
|
| To the best of my knowledge, no one has treated "rhythm" in
| any way rigorously, and it's mostly just a crock, something
| that sounds good on paper but is utterly without actual
| _reason_ or value, rather like modular scales for
| typography.
|
| I don't respect that article. Its analogies are lousy, its
| examples of non-rhythm unnecessarily bad (straw-man
| arguments), its rhythm not great in any case (and lacking
| any attempt at anything like baseline alignment), and after
| the first instance it only really shows rhythm with an
| unrealistic superimposed grid which _obviously_ makes
| rhythm look better than non-rhythm. I get the sense that
| the author has read a bit of various things, and then
| attempted to justify an opinion in any way they could, and
| ended up producing an incoherent and completely unsound
| argument.
|
| There are certainly major places where consistent spacing
| and sizing is of value. But slavishly following it _page-
| wide_ without something like a background pattern that
| you're aiming to match (which is absolutely a legitimate
| use case, but is _aesthetic_ rather than _functional_ )...
| I've never come across any argument that seemed to hold any
| water, and I'd like to understand why a few people are so
| attached to the notion that it has inherent virtue.
| andrei_says_ wrote:
| I'd like to recommend https://utopia.fyi/
|
| A fluid typographic scale and spacing. Eliminates the need for
| breakpoints for text. I've used it on a number of projects with
| great success and love its simplicity.
| manuelmoreale wrote:
| Thank you for sharing this. You just removed an item from my to
| do list because I wanted to code something similar for myself
| and now I no longer need to since I can use this tool.
| scrozier wrote:
| Or...you could work with a designer whose training and experience
| it is to make things like this look nice and work well. Instead
| of trying to have an formula or algorithm for everything, just
| because that's what you know.
| spagoop wrote:
| Strange take, as if this isn't largely a tool for designers to
| experiment with type scales?
| scrozier wrote:
| I'd be happy to be wrong, but this sure feels like another
| instance of a numbers/formulas/algorithm-oriented person
| wanting a shortcut to visual style. This site is full of
| these, in many areas of endeavor. As a musician, I
| particularly notice posts that do this kind of thing with
| music ("I've Invented a New Musical Notation That Makes
| Everything Easier!").
|
| I just get sad for the designers who have to battle this
| stuff every day. No programmer would take "input" on their
| code from a nurse (say), but designers face "input" on their
| decisions and their craft at every turn. I've yet to meet a
| designer who was longing for a web form to input a bunch of
| numbers to generate some type sizes.
|
| But I could be wrong. It happens a lot.
| tracker1 wrote:
| I think you assume that a designer can't also understand
| math, ratios and scale. Many practical designers are also
| engineers.
| scrozier wrote:
| Not sure how you read that into my comment. I'm saying
| that trained, skilled designers don't _need_ formulas and
| tools like this to achieve pleasing and functional
| results.
| giraffe_lady wrote:
| Maybe, but in this context on this site I think it's safe to
| assume a lot of people are going to look at this with "ah!
| another subjective judgment that can be marked Objectively
| Correct by using an algorithm."
| kadomony wrote:
| This honestly outputs trash CSS. The scaling is abysmal. If I see
| a font size with a decimal in it, I'm going to assume you were
| about as lazy as this tool.
| hundchenkatze wrote:
| What's wrong with decimals in font sizes?
| toastal wrote:
| If you block third-party fonts or Google Fonts specifically--and
| you should for privacy--this whole tool doesn't work. Prefer
| first-party hosting, and always provide a native fallback (at
| minimum sans-serif, serif, monospace, or fantasy).
| wildrhythms wrote:
| This is a nice visualization tool for seeing how these fonts will
| scale in your browser. Nice job!
|
| I always consider: That 9px text might look readable on your 4K
| iMac, but how about your users on a budget Chromebook with a 720p
| display? And text rendering differences between browsers and
| operating systems is still something that severely affects how
| the text looks, especially at thin font weights that seemed to be
| all the rage a few years ago.
| graup wrote:
| Also, for users that have any of the CJK languages as their
| default browser language, Chrome enforces a minimum font size
| of 10 (or 12?) pixel, so anything smaller should be avoided
| anyway if you care about rendering similarly for all viewers.
| https://bugs.chromium.org/p/chromium/issues/detail?id=36429
| lisrjflksdjfi wrote:
| The fact you can even read a not-really-"9px" font on a retina
| display highlights how wrong browsers get things when they try
| to move too fast to quickly patch things. and more importantly,
| when the companies selling the new displays get a say on the
| html/css spec.
|
| yeah, chrome and safari supported retina displays on day one,
| but at yet another huge consistency nuclear bomb that we now
| have to remember forever.
| chrismorgan wrote:
| I have no idea what you're trying to say, but I'm pretty sure
| you're misunderstanding something.
| Guidii wrote:
| Font sizes get scaled in the browser. So when you ask for a
| 9px font, the browser treats that as 9px in virtual pixels,
| then maps it into 18px physical pixels.
|
| It mostly works, but gets weird when you have non-scaled
| content in the design.
| chrismorgan wrote:
| Ah, that could be the misunderstanding.
|
| You don't have non-scaled content in the design.
| _Everything_ is scaled. <img width="32" height="32">
| will be 32px (as in, CSS pixels) wide, whether that means
| 32dpx (device pixels) or 64dpx or something else.
|
| (OK, so there are a few escape hatches; you have things
| like <img srcset> which allow you to choose different
| image sources for different scaling factors, and you can
| also query devicePixelRatio and change things based on it
| --though all of this isn't actually guaranteed to map to
| physical pixels, e.g. my system uses 1.5x scaling but
| Firefox hasn't finished implementing fractional scaling
| under Wayland so it renders at 2x and then scales down to
| 1.5x, so any line that is carefully made "one device
| pixel wide" will actually only be 2/3 of a device
| pixel.)
| tracker1 wrote:
| In browsers, there are supposed to be roughly 72px per
| inch. This _should_ get scaled, assuming the OS /Browser
| knows what the actual pixel density per inch is. And even
| then the scaling may not be linear to reality.
|
| If you've ever run a mobile device without the real
| dimensions set properly (cheaper models, or custom roms)
| it gets interesting to say the least. Having less than
| stellar vision up close, I have every accessibility
| setting on my phone maxed... It's bad enough as it is the
| number of applications/sites that will render (in
| particular modals) off-screen.
|
| In the end, however, nearly everything is scaled to
| either the real pixels, or often assume 72/inch as the
| actual screen density and scale accordingly. You really
| never know which.
| chrismorgan wrote:
| Correction: The CSS units are defined as 96px = 1in. It's
| the _point_ that's 1/72 inch.
|
| My comment elsewhere in the thread is relevant on these
| units and how they're anchored:
| https://news.ycombinator.com/item?id=36001822.
| tracker1 wrote:
| Yeah, I often get the two conflated... in either case,
| it's never, or at least rarely accurate.
| alex_lav wrote:
| When can I get a total replacement of CSS with something more
| sane? Seems like one of the few pieces of the stack that's just
| not getting any better over time. And no, flex isn't better.
| chrismorgan wrote:
| I have no idea how you get to this from the article or the
| discussions in this thread. What do you propose to replace CSS
| with? How will it avoid the problems you perceive with CSS
| _while still being useful_?
|
| (I'm genuinely curious what you think is wrong with CSS, and
| how it could be fixed. I've heard this kind of sentiment from
| time to time, and never had a reasonable answer. CSS certainly
| isn't perfect, but it's not at all bad, and most criticisms of
| it like the meme "CSS is awesome" box with overflow genuinely
| come from not understanding it and why any other approach would
| be worse.)
| alex_lav wrote:
| > What do you propose to replace CSS with
|
| I don't think I need to have a solution prepared to define a
| problem?
|
| > How will it avoid the problems you perceive with CSS while
| still being useful?
|
| How did <insert any language> replace <insert any older
| language> while still being useful?
|
| This is kind of what I mean when talking about CSS. For
| whatever reason, all of the innovation, invention, tinkering,
| progress that went into _every other aspect of software_ just
| gets forgotten about with regard to CSS? This idea that CSS
| is the perfect solution, or close enough that there's no
| reason to invent something radically different. We're on our
| 5000th Javascript build tool but we still just have terrible
| old CSS.
|
| > and never had a reasonable answer.
|
| Completely reasonable answer: I have no idea, it's not my
| responsibility to create a solution. CSS is enough of a
| problem that I just generally refuse to use it. I'm not alone
| in this.
| chrismorgan wrote:
| What do you even find _wrong_ with CSS? You haven't defined
| the problem at all.
| alex_lav wrote:
| 1. Positioning (yes even with flex) is unintuitive and
| painful
|
| 2. The fact that the !important tag exists, and at a
| broader level the fact that cascading exists
|
| 3. The community seems pretty hellbent on rejecting
| working solutions for being "bad". float: left is "bad".
| And yet, many/any other positioning systems are, to me,
| much worse. So to me, it's all "bad". Similarly, tables
| are the easiest way to position things correctly (since
| point 1, all other positioning tools are pretty bad), and
| yet, table-based-layouts are "bad". So again, it's all
| "bad".
|
| More elegantly put:
|
| - https://adamwathan.me/css-utility-classes-and-
| separation-of-...
|
| - If you search "What's wrong with CSS y combinator",
| you'll get some derivative of this exact conversation
| over and over again for the past 15 years. CSS people
| saying "no it's good!", many other types of people saying
| "it's just too complicated and I don't want to keep doing
| it", followed by css people saying "no it's good!"
|
| I think Tailwind is probably the closest approximation to
| tolerable CSS, but I also think its existence highlights
| a greater problem with both the community and the
| technology.
___________________________________________________________________
(page generated 2023-05-19 23:01 UTC)