[HN Gopher] The least amount of CSS for a decent looking site (2...
___________________________________________________________________
The least amount of CSS for a decent looking site (2023)
Author : loughnane
Score : 696 points
Date : 2025-10-06 23:47 UTC (23 hours ago)
(HTM) web link (thecascade.dev)
(TXT) w3m dump (thecascade.dev)
| Jabrov wrote:
| More sites should be like this
| hsbauauvhabzb wrote:
| Why? There's a huge amount of JavaScript bloat, but I've never
| really had an issue with css on any site. If anything, I wish
| more sites supported a dark mode.
| librasteve wrote:
| CSS bloat is there also, perhaps not as big a deal. I think
| that complexity is the main enemy (both JS and CSS and React
| and npm ...) or over on the WordPress plugin morass. I like
| that the OP is aiming for a simpler world, kind of like the
| HTMX and Pico CSS ideas that I currently prefer.
| lelandfe wrote:
| > perhaps not as big a deal
|
| If I load CNN.com right now and scroll to the bottom, I
| receive 26.9 MB over the wire.
|
| Of that, 52.2 kB are CSS.
|
| 5,547 kB are JS.
|
| CSS bloat is not as big a deal.
| typpilol wrote:
| Tailwind v4 tree shakes too so even thats not technically
| bloated anymore
| o11c wrote:
| Tree-shaking really only works for languages that are
| designed to be tree-shakable, which no web language is.
| _heimdall wrote:
| Tree shaking and bloat are different concerns. And,
| technically, is tailwind tree shaking? I thought they
| only built styles that the compiler could find being used
| rather than removing styles the compiler _couldn 't_ find
| being used.
| zelphirkalt wrote:
| Tree shaking is actually a sign of bloat. It is a tool on
| top of a bloated mess, to fix that mess. It would be
| better not to make a mess in the first place.
| sublinear wrote:
| I'm curious how much of that JS is functional and how
| much is adware.
|
| The adware is typically injected onto the page by 3rd
| parties so it's nothing the web devs can do anything
| about.
| kmstout wrote:
| > how much of that JS is functional
|
| Lots of sites become more functional with JS disabled.
| zelphirkalt wrote:
| It is the web devs' responsibility to say no to bs.
| However, very few do, and some even welcome the bloat as
| a job guarantee.
| sublinear wrote:
| This is not how the web works.
|
| That's like asking any other software dev to "say no" to
| letting other programs run concurrent with their own.
| It's just not within scope and any attempts to have your
| program behave this way will be impossible to maintain.
|
| If you're a business that wants to inject ads without
| anyone getting in the way, all you have to do is host the
| pages somewhere the dev can't touch. This would likely be
| a CDN or similar for a multitude of other good reasons.
| So the content security policy is now only configurable
| by the admin who _really_ doesn 't give a shit and
| doesn't even know what's being hosted on there.
| efreak wrote:
| I'm more curious how much of that js is intended to load
| more js that has been blocked (by the browser, adblocker,
| hosts file/DNS, etc).
|
| CNN specifically isn't a site I visit much, but most news
| sites load a ton of third-party stuff (being on mobile
| makes it hard to check)
| SoftTalker wrote:
| Use lite.cnn.com instead.
| prisenco wrote:
| 52K of CSS should be an opportunity for optimization but
| you're right, we're so far gone on javascript we should
| really focus on the mountains before the molehills.
| cratermoon wrote:
| But even a small bit of css can slow down page rendering.
| https://www.granola.ai/blog/dont-animate-height
| hsbauauvhabzb wrote:
| That article refers to literally one line of css. Cutting
| down the volume of css does not have value, cutting down on
| animations and other expensive directives does.
| zelphirkalt wrote:
| If a small amount of CSS can, then so can a similarly small
| amount of JS, since JS can set styles.
| hsbauauvhabzb wrote:
| I think that's moot. Everyone agrees there's a pretty big
| bloat problem in JS, not so much because of single costly
| lines (though, they exist) and more the entire ecosystem
| of includes
| phantomathkg wrote:
| Why not? Code is liability. Less code to maintain also
| enhance engineer's ability to reason the code and implement
| better website.
| hsbauauvhabzb wrote:
| Code is a liability lends well to tech debt, wasting time
| refactoring css to reduce the size by tens of kilobytes has
| no real world return on investment in most cases.
| edoceo wrote:
| Still need a lot of the reset stuff - to at least get a baseline
| consistency.
|
| If you only target modern (5 year window) that one popular reset
| can be trimmed.
| moron4hire wrote:
| Resets are overrated. You don't really need all that much
| consistency between platforms when you're talking about a
| minimal setup for something like a personal blog like the OP is
| doing. Resetting for consistency is mostly just designer-brain
| not being able to accept that things can look slightly
| different in different places and be completely fine.
| mcny wrote:
| Yes! That's the whole "when in Rome" idea but I've never
| gotten any team at $work to accept that.
|
| A drop down menu on an iPhone SE is supposed to look
| different than on an ultra wide monitor on a desktop!
| nine_k wrote:
| It's not about consistency, it's about basic readability. On
| different platforms / browsers things will differ, but remain
| readable. Not necessarily aesthetically perfect, but more
| usable than with defaults from 1994.
| joshuat wrote:
| reset.css
| armchairhacker wrote:
| > ...it is a best practice to allow users to manually toggle the
| color-scheme as well.
|
| > Some people prefer a dark system theme, but light website
| themes, and vice-versa.
|
| Is this common? Why don't those people configure their browser to
| use a light theme? Or if they prefer different websites to be
| different themes, use a browser plugin?
|
| ...a more general issue is that every website has to re-implement
| many things. It's a small issue, but it discourages newcomers,
| and the redundancy on every website adds up. Ideally, a site
| should look decent with _no_ CSS, but in order to support legacy
| sites (a good thing) the _default_ styles are the legacy ones (a
| bad thing); keeping what even back then would probably be
| considered "bugs" (except, like how crimes become legal, they
| managed to become "features" by being discovered too late), such
| as large images causing horizontal overflow. Honestly, is there a
| single good reason to make the default font Times New Roman 16px?
| justmedep wrote:
| Browser extension that do that require full access to the
| contents of the website. That's why some people decide not to
| use those extension.
| kennywinker wrote:
| It's been a while since i mucked around with browser
| extensions, but i assume they don't have network access by
| default. Surely there is an extension with page read access
| and without network access, no?
|
| Edit: this looks pretty harmless https://github.com/the-code-
| rider/dark-theme-extension/blob/...
| ezfe wrote:
| Browser extensions that modify webpages are just javascript
| code injected in the page; They can definitely access the
| internet.
| kennywinker wrote:
| I don't think that's an accurate description of browser
| extensions. Content scripts work that way, and many
| browser extensions include content scripts... but not all
| browser extensions use content scripts.
|
| Anyway, a quick readthru of the code of the extension i
| linked shows it does use content scripts, but also it
| doesn't do any network access.
| sgc wrote:
| If I want to use an extension that needs full permissions on
| sensitive websites, I just download it and install it
| manually after looking at the source code. I rarely have to
| update them, and I'm not worried about future injections at
| that point.
| smolder wrote:
| Listen to this guy defend trash web browsers to support
| google! Tell me more about how traditional forums are
| unacceptable and your daddy with billions for shareholders
| but not customers has the right idea.
| ponooqjoqo wrote:
| Browsers _should_ have been set up to allow per-site toggling
| of the dark mode CSS preference, much like how they allow per-
| site zooming.
|
| Configuring the whole browser to have a light theme is the
| wrong solution - some websites look better in dark mode and
| some look better in light mode. Also, the browser setting also
| affects the UI of the browser itself, not just website
| contents.
|
| These are of course solvable problems, but the most obvious and
| trivial way to handle this is just to store an extra flag per-
| website in the same place as the zoom preference.
| o11c wrote:
| Obligatory "there is a way, it's just that your browser
| refuses to implement it".
|
| https://developer.mozilla.org/en-
| US/docs/Web/HTML/Reference/...
| MrJohz wrote:
| Is that persistent? As in, if I select a style sheet for a
| website, will it use that same style sheet if I reload the
| website or navigate back at a later date? Browsers do this
| all the time with zoom levels, but it would be really
| useful for much more than that.
| sunaookami wrote:
| Firefox does not remember it sadly.
| zzo38computer wrote:
| I think the default styles are OK; I do not think they are so
| bad as some people say. However, the thing I would add (for web
| pages that have pictures) would be: img { max-
| width: 100%; }
|
| (which is one of the things mentioned in that article; it
| probably would make sense for videos and SVG as well like they
| mention.) But, if you don't like them, the user should be
| allowed to customize them. In case this causes problems with
| web pages that use different styles that interfere with them,
| then hopefully an attribute could be added to specify that the
| user's CSS should be used instead of this one (and in some
| cases the browser might be able to decide this automatically
| for when the web page does not specify this attribute, e.g. if
| the styles are only associated with media queries and HTML
| element names rather than IDs, classes, etc). The user could
| still override this to disable the web page's CSS entirely if
| desired, but this would make it possible to specify that the
| web page's CSS is not needed for styling classes and other more
| complicated stuff within the specific web page or web app. (If
| the user does not define their own CSS, then it would use that
| defined in the web page (or the defaults if there is no CSS in
| the web page; the defaults probably should be changed to
| support the light/dark scheme properly for web pages that lack
| CSS, though), and the hypothetical attribute that I mentioned
| would be ignored.)
| majkinetor wrote:
| I prefer light at day and dark at night. I have scheduler that
| turns on OS like that and all other stuff follows (e.g. apps
| with auto setting and browser with dark reader).
|
| This is particularly important on mobile, as dark is very
| reflective at day, and light blinds you at night.
| bix6 wrote:
| https://meyerweb.com/eric/tools/css/reset/
|
| Cash money
| roblh wrote:
| I've seen this one a few times and something about it doesn't
| agree with my eye. It's somehow in the weird awkward zone of
| not old enough to truly feel simple and functional, but not new
| enough to look modern minimal/clean. Might just be the font
| also, but I don't find it very easy to read. Could just be me
| though.
| pbhjpbhj wrote:
| I mean, it's a reset, not a complete style. You're supposed
| to apply your styles on top (well, underneath, as styles
| cascade; but hopefully you know what i meant).
| slow_typist wrote:
| Eric Meyer, the CSS guru of all times
|
| I wouldn't have made any sense of the CSS box model without him
| back in 2002.
|
| https://meyerweb.com/eric/books/
| AceJohnny2 wrote:
| Ironically, that page does not render well on Chrome/Windows,
| at ~1920x2160 (that's half a 27" 3840x2160 monitor), with an
| excessive empty margin on the left pushing the book list to
| the right, causing a horizontal scrollbar, which when
| scrolled to its rightmost causes the right side of the
| website to scroll and leave an awkward empty space.
|
| I guess this says something about the evolution of web
| standards.
| Theodores wrote:
| CSS reset stylesheets are just the first step towards
| unmaintainable 'add to' stylesheets, laced with the word
| 'important' everywhere.
|
| I think it is best to take the Kevin Powell approach, as per
| the article, where you will be leaning in on browser defaults.
| Clearly you have to do your cross-browser and cross-platform
| testing, however, after almost two decades of everything coming
| with a CSS reset lurking in the stylesheets somewhere and
| mountains of cruft on top (remember frameworks), it is so
| liberating to get rid of the lot and to use the modern CSS
| tools such as CSS Grid and CSS variables.
|
| Nowadays CSS is my favourite 'LEGO set' and I love the creative
| opportunities. This contrasts with the olden days where I hated
| the hacks based on hacks that was CSS. I have gone from
| practically drowning despite wearing armbands to being able to
| effortlessly glide through the water. CSS reset is one of those
| 'armbands' and it takes courage to go without such things. Same
| goes for those awful CSS pre-processor things.
| sfn42 wrote:
| I've recently chosen plain CSS for a project at work. Haven't
| got that far yet as it's been mostly backend work so far but
| for what had been done it's been good. I'm just a bit worried
| that it's going to look wrong in different browsers but I
| guess I'll burn that bridge when I get to it. Luckily I don't
| think there's going to be any safari users.
| Izkata wrote:
| I have this vague memory of a blog where someone went through
| various CSS resets, and came to the conclusion that margins
| and paddings made up something like 90%+ of the differences
| between browsers. Apparently only "* { margin: 0; padding: 0;
| }" gets you most of the way there and the larger CSS reset
| stylesheets were so big because they included unnecessary
| stuff, rarely-used elements, or even added the creator's
| preferences instead of just being a reset.
| cratermoon wrote:
| 58 bytes of CSS to look great nearly everywhere
| https://gist.github.com/JoeyBurzynski/617fb6201335779f8424ad...
| swyx wrote:
| 100 bytes: https://www.swyx.io/css-100-bytes
|
| (i collect a lot of these design advice. more:
| https://github.com/swyxio/spark-joy/)
| noduerme wrote:
| Like, this is a clever enough way to play golf and find an
| average that works between major browsers and come out with
| something that should generally be legible. "Look great" is a
| bit of hyperbole, because it'll always look like shit. Legible
| shit, probably.
| kmoser wrote:
| > To make the website more readable, we'll limit the content
| width
|
| Please don't do this. Despite what usability studies say, I
| prefer wide content over scrolling every few seconds and having
| to make my eyes follow the moving text. I, the user, can already
| control the content width by resizing my browser, thank you very
| much.
| geokon wrote:
| you can also just display text with multicolumn.
|
| solves the paragraph width "usability" and uses the full screen
| space
|
| not sure why its never used.. I also really dislike the current
| trend of giant white sidebars
| hiAndrewQuinn wrote:
| It's a little annoying to change from 3 to 2 to 1 columns
| when someone does resize, though. I just let people resize
| the window itself on my blog if they want to compress the
| text down.
| shdon wrote:
| Because it would make scrolling more frequent? For
| multicolumn text to reduce scrolling, the column height would
| have to match the available viewport height. And if your text
| exceeds what can fit in multiple columns on a single
| screenful, scrolling also becomes awkward, because you'd have
| to scroll exactly to the next screenful to have any
| consistency. Multiple text columns only make sense on
| extremely restricted layouts, or where the volume are
| entirely independent instead of a single flowing piece of
| text, or where there is still a direct horizontal
| relationship (like annotations or translations beside the
| main text).
| wtallis wrote:
| > And if your text exceeds what can fit in multiple columns
| on a single screenful, scrolling also becomes awkward,
| because you'd have to scroll exactly to the next screenful
| to have any consistency.
|
| That used to be a solved problem, before every website
| started to include multiple oversized "dickbars" floating
| over the real content and taking up 15+% of the available
| vertical space. Pressing the "Page Down" button on a
| keyboard would scroll down by exactly one screenfull. We
| also used to have scrollbars that on most operating systems
| would let you scroll down by exactly one screenfull with a
| single click.
| andai wrote:
| >you'd have to scroll exactly to the next screenful to have
| any consistency.
|
| Or to the right. (That might be even worse though, I don't
| know.)
| zelphirkalt wrote:
| Interesting idea. Maybe we could have a standard action
| of moving one column further.
| geokon wrote:
| oh good question
|
| i have never hit this issue bc you need a massive amount of
| text to fill the whole screen. I have some natural breaks
| and subheaders. Each section is wrapped in its own columns
| handsclean wrote:
| I want this and am eventually going to try harder to
| implement it, but the reason is basically because CSS can't
| do it. What do you do when you still have more content than
| fits on the screen? If you just stick with default CSS
| behavior and make the columns taller than the screen, now
| you're scrolling all over the place constantly, it sucks. If
| you add more columns off to the right, you already probably
| need to use JS for layout, and it still isn't nice on
| desktop, you need to scroll more for each bit of content and
| most desktops don't have intuitive side scrolling controls.
| What you want is viewport-sized "pages" with a dynamic number
| of columns per page, but this is basically a whole extra
| layout mode that you need to implement in JS. There was a
| whole project to let JS plug into the layout engine better, I
| think it's stalled now, I don't know if it got far enough.
| Then there's the weird bottom right -> scroll -> top left
| jump, you probably want to implement a hint or UI there,
| maybe even column to column since we're breaking norms here.
| Scroll snapping is thankfully in CSS now, so we don't have to
| worry about scrolling precisely to the next screenful, but we
| do cost people the ability to put what they want where they
| want it within the viewport. You'll need to implement
| something to make anchor links work again, users can no
| longer just look at the top of the page. Everything's going
| to go nuts when users resize the window, and maybe even more
| nuts due to browser attempts to keep them "in the same
| place", you need to make it some semblance of ok. As soon as
| you want something non-text your columns will be too narrow,
| so you're really going to have to implement complex column-
| spanning stuff off the bat. CSS thankfully has tools for
| controlling things like "don't split this across columns",
| but I bet they'll prove inadequate if you dig into it. You've
| also reduced linearity, it's now much less true that what's
| above is before and what's before is above, etc.
|
| I'm still interested in this layout, but that's why nobody
| does it: it's far more complex from the web dev's
| perspective, bad if not executed perfectly, and still has
| downsides even if perfect.
|
| I think it's still popular in places where the viewport size
| and content are both known at design time.
| Tistron wrote:
| I remember somebody championing css features, I think
| Adobe, to make it possible to have overflowing content
| spill over into another container, like it is (was?)
| possible to do in Publisher. I'd love something like that,
| and have wanted it several times. But it was abandoned...
| handsclean wrote:
| Never knew that. I think that in combination with CSS
| grid auto fill, that may have solved a huge chunk of
| paged columns.
| zelphirkalt wrote:
| I find shift + scroll quite intuitive. Works on almost
| everything where there is a horizontal scrollbar.
| klinch wrote:
| No offence, but "please don't do X" where X is favoured by the
| big majority of users AND has a broad scientific base sounds a
| bit... entitled?
| kmoser wrote:
| It has nothing to do with entitlement. If you choose an
| arbitrary width based on usability studies, you may make a
| large percentage of users happy, but if you let users set the
| width by resizing their browser, you make 100% of users
| happy. Why not choose the latter?
| Waterluvian wrote:
| My windows stay maximized and I'm not about to faff about,
| resizing them. When I come across an Ultra Panavision
| website I usually just open the dev tools with a single
| F-key to squish it.
| Gigablah wrote:
| I'm not going to resize my browser each time I follow a
| link or switch between tabs.
| xdennis wrote:
| Nonsense. People almost always use browsers maximized. And
| many people have 2.5k or 4k screens. Even on 1080p screens
| full width text is unreadable.
|
| I seriously doubt there are any people who resize their
| browser window every time they switch tabs.
| galaxyLogic wrote:
| Right, there is a reason newspapers long ago realized
| multiple columns is better than full-width text. Imagine
| reading New York Times if it had only one full-width
| column. People would stop subscribing to it.
| zelphirkalt wrote:
| it what's also nonsense is, to firmly associate browser
| window width with tab content width. The user can control
| these independently. Maybe it should be made easier to do
| so, or more comfortable. At some point though we should
| take a step back and ask ourselves how we can solve the
| problem without dumbing down the interface so much, that
| capable users suffer.
| patrickmay wrote:
| I must not be a people -- I don't have my browser
| maximized. I like to be able to see the browser window,
| Emacs, and a terminal all at once.
| joegibbs wrote:
| If the user needs to set their own width by resizing the
| window they can also set the width by right-clicking ->
| inspect element -> disabling the CSS style on the div that
| gives it a max width. Which is only a couple more clicks
| than resizing the window and affects a lot less people.
| zelphirkalt wrote:
| Often not so easy to do with nowadays bloated designs and
| tons of patronizing frontend devs making websites. You
| might have to remove 10 styles for all the bloat
| containers they used to contain fancy text. Better to not
| prescribe any preference and enable the user via standard
| browser tooling, which definitely would spring up, if
| users showed significant interest in such.
| chrismcb wrote:
| You won't make 100% of the users happy. In fact if argue
| you would make the majority of the users unhappy. I don't
| want to have to realize my browser for every web site. Is
| rather have a website that is fairly easy to read without
| me doing anything. I think most people would want that.
| lawn wrote:
| > but if you let users set the width by resizing their
| browser, you make 100% of users happy
|
| It's very ignorant to believe 100% of users are happy with
| having to resize their browsers just to get a pleasant
| rendering of the site.
| majkinetor wrote:
| Resizing browser is cumbersome and will definitely NOT make
| me happy. Especially since I have tiled desktop but even
| without it.
|
| If you really want to please everybody here, introduce an
| option that is remembered in a cookie (reading preference,
| trivial to implement). There is no one size fit all here.
| shayief wrote:
| I actually prefer limited content width for prose content. Full
| width content on wide screens requires moving eyes all the way
| from one side to another for every line.
| galaxyLogic wrote:
| Right, if you have wide columns then you have to move eyes
| BOTH from left to right AND when you reach the end of the
| line you have to move them back to left AND down to next
| line. Whereas if the line is narrow enough to read without
| moving eyes horizontally you only need to move your eyes down
| after each line.
| yosefk wrote:
| The real problem is that the browser won't let you control
| the width of a tab without resizing the browser window, which
| is a bit fiddly, exposes stuff behind the window, and makes
| you resize the window again and again when moving between
| tabs.
|
| If you could easily shrink a tab, I would prefer websites to
| not limit text width. Since you can't, I sorta prefer them to
| do it, though it's much worse than the user controlling it in
| a nice per tab way
| Cockbrand wrote:
| You could use the browser's dev tools to emulate a narrower
| viewport.
|
| It should also be almost trivial to create a browser
| extension for this, if it doesn't even exist yet.
| rixed wrote:
| I use the developer tools right panel for that.
| fodkodrasz wrote:
| you can "pop out" a single tab to a new window.
| throw_await wrote:
| I use firefox's sidebar (vertical tabs) which makes
| resizing quite natural imo
| zelphirkalt wrote:
| (1) reader mode (made for that purpose)
|
| (2) user stylesheets (permanent solution, but you could
| have multiple and use an extension to enable disable
| different widths)
|
| (3) responsive mode (in dev tools, most flexible, but most
| cumbersome to reach)
|
| (4) Other extensions
|
| There are easy ways to resize the viewport, so the premise
| is false.
| solstice wrote:
| This bookmarklet to shrink the width has been in my toolbox
| for a long time: javascript:(function(){%20var%20myBody%20=%2
| 0document.getElementsByTagName('body')[0];%20var%20myBodyWidt
| h%20=%20myBody.style.width;%20if%20(!myBodyWidth%20||%20myBod
| yWidth%20===%20'auto'%20||%20myBodyWidth%20===%20'inherit')%2
| 0{%20myBody.style.width%20=%20'1200px';%20myBody.style.margin
| Left%20=%20'auto';%20myBody.style.marginRight%20=%20'auto';%2
| 0myBody.style.position%20=%20'relative';%20myBody.style.cssFl
| oat%20=%20'none';%20}%20else%20{%20myBody.style.width%20=%20'
| auto';%20myBody.style.position%20=%20'static';%20}%20})();
| dev_l1x_be wrote:
| This summarizes the web ghetto pretty neatly.
| vasvir wrote:
| Thanks that's an interesting trick.
|
| This is beautified if somebody wants to see how it is done.
| function() { var myBody =
| document.getElementsByTagName('body')[0]; var
| myBodyWidth = myBody.style.width; if (!myBodyWidth
| || myBodyWidth === 'auto' || myBodyWidth === 'inherit') {
| myBody.style.width = '1200px';
| myBody.style.marginLeft = 'auto';
| myBody.style.marginRight = 'auto';
| myBody.style.position = 'relative';
| myBody.style.cssFloat = 'none'; } else {
| myBody.style.width = 'auto';
| myBody.style.position = 'static'; } }
| mixedbit wrote:
| Right, there is a reason why print magazines use columns even
| for long multi-page articles. With long lines, readers tend
| to get lost when navigating from the end of one line to the
| start of the next line, and the reading experience suffers.
| You can help this somehow by increasing spacing between the
| lines, but the general recommendation is to have 45-75
| characters per line.
| froddd wrote:
| If a text-heavy website does not constrain the width of its
| content, what do you tend to resize the browser to? Does it
| depend on text size? Or other factors?
| kmoser wrote:
| I tend to not resize the browser ever, except when
| developing/testing sites to make sure they render properly on
| different screens sizes. I use a 27" monitor and I like
| reading full-width. As I said in my original comment, I find
| the act of syncing my eyes with scrolling text to be very
| distracting, whereas reading a very wide column of text to be
| very easy. Depending on the website's default font face and
| size I might use the browser's text zoom feature to enlarge
| the font, but I still like reading full-width.
| 3371 wrote:
| No. No no no. I browse hundreds even thousands of pages every
| singe days, and I either just close such sites or go the extra
| mile to write custom css for them when they are disgustingly
| wide.
| andai wrote:
| While we're on the subject of "the user needs to become the
| programmer to have an acceptable experience" (sites needing
| my custom css added to be usable), my pet peeve is when the
| scrollbar is present but intentionally offset from the right
| edge of the screen by one pixel.
|
| So then you hug the right edge of the screen, looking for it,
| where it _looks_ like it is, and where it 's been for like
| the entire history of computing, and then you click, and
| there's just nothing there.
|
| This is a special case of Fitts's law, where a button at the
| edge of a screen becomes effectively infinitely wide, as far
| as ease-of-clicking goes.
|
| This was used intentionally with great effect on usability in
| the 90s and 2000s. (Scrollbar, start menu, show desktop,
| etc.)
|
| In the last decade however the trend appears to have
| reversed: it is now fashionable be to make the scrollbar as
| difficult to click as possible, by offsetting it, making it
| narrower, or hiding it altogether.
| onli wrote:
| There is a browser out there which does something like that
| for every site. It has a separate area for the tabs,
| instead of using the full window. That could be okay. But
| it has a margin around it. Which means that every single
| scrollbar for every single page does not go to the edge of
| the screen, completely sabotaging easily hitting the
| scrollbar. Welcome to the genius of the zen browser.
|
| https://github.com/zen-browser/desktop/issues/1126 is the
| issue, closed as they won't fix it (thus my snark).
|
| > _In the last decade however the trend appears to have
| reversed: it is now fashionable be to make the scrollbar as
| difficult to click as possible, by offsetting it, making it
| narrower, or hiding it altogether._
|
| Afaik Ubuntu jumpstarted it with their minified GTK
| scrollbar, used in their Unity DE. But that thing was
| actually smart: It slimmed down visually, but as soon as
| the mouse entered its region you got the scrollbar handle
| at the mouse pointer's position. So it made manipulating
| the scrollbar even easier than a fullsized scrollbar (for
| at least some usage) while looking nicer. Ofc that
| usability aspect is something the CSS reskins and other
| adaptations promptly and completely forgot.
| jancsika wrote:
| > I, the user, can already control the content width by
| resizing my browser, thank you very much.
|
| Nearly every techie and non-techie I know has a bazillion tabs
| open 100% of the time. The likelihood that even the top 10 are
| all single-column text is 0%. And I'd sooner read web pages hot
| off a dot matrix printer than constantly pecking at the edge of
| an un-maximized window, resizing it like some kind of meth-
| addled chicken.
|
| Note: I may be overstating slightly for effect.
| lloeki wrote:
| The art of opening windows instead of tabs appears to have
| been lost to time.
|
| Oh the irony that lots complain that mainstream OSes window
| managers are oh so poor when all people seem to be able to do
| is fullscreen everything and then tab around.
|
| Meanwhile, macOS gave up on the absolutely brilliant if
| misunderstood Mac OS X green + a.k.a "zoom" which would
| miraculously resize windows to the maximum size _of its
| content_ but no more.
| perching_aix wrote:
| It's almost like window management is primarily being used
| for facilitating inter-app interactions, rather than intra-
| app interactions... almost like tabs were invented for a
| reason...
|
| Did people lose the old art, or have you never managed to
| grasp the "new" one?
| robinsonb5 wrote:
| It wouldn't be a problem in the first place if we hadn't
| migrated away from 4:3 aspect monitors to these
| ridiculous widescreen things. ;)
|
| Maybe someone should invent a tiling tab manager for the
| web browser.
| latexr wrote:
| > macOS gave up on the absolutely brilliant if
| misunderstood Mac OS X green + a.k.a "zoom"
|
| It's still there. Window > Zoom from the menu bar, or [?] +
| click the green window button.
| efreak wrote:
| I really wish mobile browsers had windows (true windows
| that could be switched easily, not the weird crap where you
| go into a submenu to find the list of windows and try to
| figure out which one has your tab, and Firefox doesn't even
| have that). I would love to split up my browsing into
| multiple workspaces on my large tablet, but instead I get
| to have four browsers installed.
| jancsika wrote:
| I think a big reason it's lost to time is because it was
| poorly-specified and therefore a non-portable art.
|
| E.g., there's no way for you to easily _send_ me the
| desktop state of the open window sizes and dimensions you
| have in mind. And even then, I 'd have to hack the window
| decorations and fonts myself. I'm back to meth-addled
| chicken pecking!
| cyral wrote:
| This being the top comment really shows you cannot take HN
| advice seriously.
| AlecSchueler wrote:
| It feels so much against the spirit of the site as well.
| "Ignore the actual research in favour of my N=1 preference,
| and don't worry your users will jump through various non-
| obvious UX hoops to get the same behaviour that could have
| been default."
| BoredPositron wrote:
| I felt it was pretty fitting for HN to find a comment like
| this at the top. I'll have to admit it's also fitting to
| find one like yours below it. That it's the most discussed
| argument is the cherry on top. The comment section feels
| like a carousel for nearly a decade now.
| zelphirkalt wrote:
| Actually, you are doing the exact thing you criticize. You
| are suggesting to prescribe your personal preference to
| users, while they argued for not doing so and letting the
| user choose, while leaving it unspecified, how the user is
| supposed to make that choice of viewport/content width.
|
| I much more sympathize with them tbh. Let browser makers
| figure out how to give the easy to use controls to users.
| Let them add some override for the number of columns and
| columns max width and gap and so on. Or let extensions
| handle that. Whatever. But don't rely on each site
| prescribing how I have to read it.
| AlecSchueler wrote:
| What am I doing exactly? I'm saying to take UX studies
| more seriously than anecdotal preference, and to
| recognise that very few people are going to manually
| resize their viewport to navigate your website.
| traches wrote:
| If your website requires a browser extension to be nicely
| readable you are doing it wrong
| perching_aix wrote:
| Resizing your browser resizes your browser. The rest of the
| page content, the tab you're on (in every major browser), and
| the window holding those tabs, all resize with it. This is so
| misguided, I can't help but consider it to be just a thin
| veiled plea at making sites more frustrating for everyone in
| support of your supposed preference.
|
| I'd know, because this is exactly how I temporarily "fix"
| rubbish, outdated sites that have all their 80 column text
| appear on the left: I resize my browser window to move the text
| in to the center of my display. It's immensely annoying. It's
| annoying enough that sometimes it compels me to spend the
| (short but anger filled) time and override the site's
| stylesheet rather. At which point, may as well have served me
| some plain text instead. Speaking of, I do sometimes just
| toggle reader mode on too.
| zelphirkalt wrote:
| If you personally don't like how wide a text is, you can of
| course apply your own preference in various ways: (1)
| responsive mode, (2) user stylesheets, (3) reader mode. Maybe
| there are others as well. But don't try to force your
| preference onto everyone please.
| perching_aix wrote:
| > you can of course apply your own preference in various
| ways
|
| See above...
|
| > But don't try to force your preference onto everyone
| please.
|
| Limiting column width is already the predominantly
| established pattern, even all the way back to print, so
| this is nonsensical. Unless I interpret it as the cheap,
| childish clapback that it is. Which I have to say, really
| befits the take.
| zelphirkalt wrote:
| So anything that is not like the way things are now, is
| automatically nonsensical? That seems a very ...
| progressive mindset. And everything anyone else says,
| that goes against current trend is ... childish clapback?
| Wow. You sir are truly an enlightened being. Thanks for
| sharing your wisdom with us today.
| perching_aix wrote:
| > So anything that is not like the way things are now, is
| automatically nonsensical?
|
| No. Claiming that I'm trying to force something to happen
| that is already the given way is what's nonsensical.
| Because you see, it has already happened. I can at most
| reinforce it, contributing to it remaining established,
| which is really not the model you've been playing along
| in.
|
| > That seems a very ... progressive mindset.
|
| I'd go as far as to say it's downright tautological!
|
| > And everything anyone else says, that goes against
| current trend is ... childish clapback?
|
| No. Riding off what I said to coyly make your point
| instead of just directly sharing them, in order to get a
| rise out of the other, is what constitutes the childish
| clapback there. You know, like what you're doing again.
|
| > Wow. You sir are truly an enlightened being.
|
| Unfortunately, I fall way short of that. If I was truly
| enlightened, I wouldn't give conversations like this the
| time of day, as they're intentionally crafted to be
| asinine, to waste people's time and care. Or is that not
| your whole idea?
|
| Because I have to say, could have fooled me! Repeating
| after me that I have the amazing options of simulating a
| different device, injecting my own styling, or using
| reader mode, blatantly ignoring that these are
| workarounds and right after I did explicitly list 2/3rds
| of them off, surely you can appreciate comes across as
| more than just a little insulting and disingenuous. So
| does reflecting back the subjectivity of the topic, while
| conveniently ignoring that e.g. stylesheet injection or
| browser extension use go both ways, and they could use
| those too. So is everything just fine as is then, or is
| there a change needed? Make up your mind, please?
|
| > Thanks for sharing your wisdom with us today.
|
| Cheers! I would say any time, but hopefully for not much
| longer.
| anon7000 wrote:
| I mean it's in your comment. The usability studies mean more
| people prefer it the other way. You SHOULD cater your default
| style to something that's more widely usable.
|
| And no, I absolutely do NOT want the content I'm reading to be
| full width on my 32" monitor. I have loads of other sites that
| I'm jumping between which do need to take up the full space.
|
| I mean newspapers have a narrower columnar layout than any
| website and they've been around for centuries.
| tuetuopay wrote:
| I don't mind limiting content-width. I do mind the trinity of
| plz-scroll-to-read-two-words: content-width limiting, bigger
| fonts, bigger line height.
|
| Most websites abuse the latter two, and makes my mouse wheel
| spin like a meth addict without a dose.
|
| Please keep the default font size. It's aligned with the
| system's size, and is precisely what a browser's zoom function
| will scale.
| throwaway150 wrote:
| > I, the user, can already control the content width by
| resizing my browser, thank you very much.
|
| But I, the user, do not. And I will not. Because there are a
| bazillion websites that I want to browse in a maximized browser
| window. So limiting the content width help people like me who
| cannot/would not resize my browser.
| traches wrote:
| I've been on the internet since the 90s and this might be the
| worst opinion I've ever encountered.
| reassess_blind wrote:
| Please don't listen to this. You are in an incredibly small
| minority with that preference. Most readers prefer a line
| length of 50-75 characters, similar to a novel. Newspaper
| columns are even narrower than that for easier scanning. If I
| have to move my head or resize my browser to read your content,
| it's poorly formatted.
| haunter wrote:
| Have you ever read a newspaper? Or you don't even have to read
| one, just look at the layout
| rixed wrote:
| I wonder why light/dark themes became the norm in a couple of
| years, but we are still begging for the wide/narrow themes or
| two or three themes with different font sizes. Those would be
| very useful as well. And I'm as guilty as the next dev of
| course.
|
| Yes you can already resize the window or zoom but that
| oftentimes break the design in some way.
|
| Well, nothing happen in tech before it's a trend, so let's just
| wait and hope.
| YuukiRey wrote:
| > Despite what [...] studies say, I prefer [...]
|
| It's nice of you to consider only your own perspective.
| efreak wrote:
| I, the user on a mobile device, cannot resize my browser. This
| used to be supported for a very short period of time (I think?
| I might be remembering the short period of time Firefox and
| Chrome were available as fullscreen-only Windows 8 Metro apps)
| but it's not anymore.
| crabmusket wrote:
| Obligatory mention of
|
| https://motherfuckingwebsite.com/
|
| and
|
| http://bettermotherfuckingwebsite.com/
| bschwindHN wrote:
| Yep, this is my standard.
| travisgriggs wrote:
| >> ...on an iMac or a motherfucking Tamagotchi...
|
| LOL.
|
| Interesting comparison in the context of the top rated
| discussion about setting width. I'm with @kmoser. The original
| actually looks better--to me--and I like that I can manage it.
| BaudouinVH wrote:
| https://evenbettermotherfucking.website/
| vjk800 wrote:
| I think the first one is better. What's the purpose of having
| all the text crammed in a thin column in the middle of the page
| anyway? If I'm reading the page on a wide screen, let me use
| all of the _motherfucking_ screen.
| fragmede wrote:
| Eyeball muscle speed limits how fast you can read or, well;
| at least for me). My eyes simply can't go left and right as
| fast as I can read, plus keeping track of which line I'm on
| is extra overhead. YMMV.
| trashb wrote:
| I have posted a link to a research paper in a different
| comment, however it is generally accepted that 50-70 CPL
| (characters per line) is optimal for reading. Fast readers
| preferring shorter lines.
|
| Layout wise this is why newspapers arrange their text in
| columns and books also generally comply with this
| restriction.
| xxs wrote:
| Even if any of this was true, ultrawide screens are choice.
| I do prefer my code on an ultrawide one, same with text.
|
| In that regard HN is excellent.
| trashb wrote:
| Sure it is a preference and that may differ.
|
| I agree "HN is excellent" you only need to change the
| "85%" on the main table to your preference, in my case
| "70ch" in your case to "100%".
|
| I do wonder how much you need UW for coding, in my
| experience without the IDE borders and decorations
| usually the code will end around halfway on my screen.
|
| When I'm using my UW daily screen I usually dock two
| windows side by side. and didn't find that restricting.
| But I am also nostalgic for the 4:3 days from time to
| time.
| trashb wrote:
| I love these websites as they highlight not only the complexity
| of modern web design but also that the web is made for writing
| content. There are so many variations on this
| "motherfuckingwebsite" concept with a lot of different opinions
| that I would recommend everyone interested in webdesign to
| google that term and read through a bunch of them.
| xxs wrote:
| the better-versions one looks like trash on an ultrawide screen
| deadbabe wrote:
| The least amount _can_ be zero.
| webprofusion wrote:
| Ok but what happened after that. It's been years with no word.
| bigtones wrote:
| Note this website itself uses way more CSS than what it is
| proposing in the article. I count at least 300 lines all up.
| Still a good baseline though.
| thakoppno wrote:
| Thanks for doing the detective work for your friends on mobile.
| This fact severely diminishes the message of this medium. I'll
| check for myself later; but until then, I will hope it
| leverages the techniques it describes.
| paulhebert wrote:
| The article emphasizes multiple times this is a baseline
| example to be built upon
| mnls wrote:
| The least amount of CSS for a decent looking site is prefers-
| color-scheme: dark.
|
| You hear this, HN?
| majkinetor wrote:
| Just use dark reader, you can't educate the world.
| mnw21cam wrote:
| Please don't do that. I should be the one to decide whether I
| read in dark or light mode. If you want dark mode, change your
| browser defaults. Leave us normal people alone.
| mnls wrote:
| Sure but right now we can't choose right? And no, I don't
| want to use any extension for a feature that simple.
| fami-com wrote:
| If a website forces a dark theme on me, I just close it. I hate
| dark themes because they make all text an unreadable blurry
| mess for me.
| mrb wrote:
| font-family: System UI;
|
| That's incorrect. It should be: font-family:
| system-ui;
|
| Author has it right in some CSS examples, but not the first one.
| andai wrote:
| Also, if the name had been two words, it would need to be
| quoted, right?
|
| e.g. this wouldn't work either? font-family:
| Times New Roman;
|
| Edit: Well this and just "times" does work fine, which makes me
| wonder if it's been special cased due to being an older font,
| or if the matching is very permissive.
| lblume wrote:
| The matching is very permissive, and the example just works:
| https://codepen.io/leo848blume/pen/RNrppdj
| bmacho wrote:
| For me it defaults to Times New Roman when it doesn't
| understand the font, so to check if it indeed works I had
| to change the default font in my browser
| someothherguyy wrote:
| https://drafts.csswg.org/css-fonts/#family-name-syntax
| noduerme wrote:
| yknow what's also cool is specifying the font you want, so your
| website looks the way you want it to. This is generally
| referred to as "design" and, while considered an antipattern
| among people who entirely spurn aesthetics, it has something
| like a 3000 year history of getting people to engage with your
| content, assuming you have some.
| arcanemachiner wrote:
| Counterpoint: I never notice what font I'm reading unless
| someone changed it to an ugly one.
|
| This is generally referred to as "what pretty much everyone
| else thinks about your stupid font".
| noduerme wrote:
| Counter-counterpoint (from someone who minored in
| typography): The purpose of a font is to be transparent as
| glass to the data being transmitted to your eyes. That is
| why if you notice a font and think it's stupid, the
| designer has made a mistake. _Also_ if you notice a font
| because the designer left it in your default Times New
| Roman, that is a mistake. If a layout artist does a good
| job, you should never notice a font in the body of text you
| 're reading. You should only notice a font occasionally if
| they really want to highlight a header or something. The
| font is a carrier of information - lighting on the stage,
| not the main actor. And it must never assume the role of an
| actor unless the designer specifically intends it to.
|
| If you're a coder, you understand this extremely well,
| implicitly: You set up your IDE fonts and colors in a way
| that helps you see _through the code_. You don 't want to
| be looking at letter forms when you're trying to grok
| something.
|
| This is also the job of designers: Creating typefaces and
| layouts so that people see _through the text, to the
| meaning_.
|
| _Leaving your website in the system standard font
| basically screams "I do not give a shit about what is
| written here"_ and also possibly _" I run a quacky
| conspiracy website"_ and me and most people will scroll
| past your writing as quickly as possible.
|
| But there is no font that has no connotation. Every font
| has subconscious meanings to readers. Knowing what these
| are is important. Times New Roman screams, "I'm still using
| Windows 98". Whereas Comic Sans screams, "I work in a
| shitty real estate office". Simple examples. But the art is
| much deeper than that, because Optima Sans and Univers read
| very differently to the general public in ways that I could
| spend another few pages explaining. Every choice you make
| with type _implies something_ that sits as a layer on top
| of the text that 's written in that typography. But if you
| do your job well, you make the artisanship transparent, and
| allow the content to shine.
|
| This is why typography is a bit of a black art, and why
| it's powerful. It subtly influences people in ways they
| don't notice and don't understand, while they're absorbing
| written information. Dig:
|
| https://en.wikipedia.org/wiki/Antiqua%E2%80%93Fraktur_dispu
| t...
| cout wrote:
| When I think of quirky conspiracy sites, I picture
| yellow-on-blue text and bright red text inside a blink
| element and links at the bottom to lycos and altavista.
| noduerme wrote:
| This is the example of people trying too hard to make
| things "scream". Just plain Times New Roman or system
| font conveys a slightly different form of illiteracy...
| dehugger wrote:
| I love that use of "legible fonts" are a indicator of
| illiteracy for you.
| noduerme wrote:
| You can be the most literate person in the world, but if
| the way you present yourself is a bunch of flashing pink
| and purple Times New Roman on a lime green background,
| I'm going to assume you have nothing useful to tell me.
| There are a whole lotta legible fonts you can use that
| show you give a tiny fuck about how you come off to other
| people.
| jbeninger wrote:
| I was with you up to "I do not give a shit"
|
| What font has been more tested for quick pass-through of
| data than the default system fonts? To me, this simply
| screams "This is the main body. You can find your
| information here"
| noduerme wrote:
| No. System fonts have completely different reasons for
| existing than fonts you would want to use to communicate
| with the public. System fonts were initially created for
| legibility at certain screen resolutions, for dot-matrix
| printers, etc.
|
| But it's worse than that. What I'm trying to explain is
| that _every typeface, even the most innocuous one_ gives
| subtle, subconscious cues to the readers. Every font. The
| associations can range from some childhood Disney movie
| to a font you saw at a hospital while you were having a
| really serious medical problem. But after 30 years of
| _everyone on earth looking at system fonts_ , readers now
| get the cue when they see a system font that they are
| looking at a shitty MS Word document their boss just
| pinned to the felt board. Or else they assume the author
| did not bother or did not have the skill to make it look
| good.
|
| I'm a writer. I've written 6 novels. I love words and
| ideas, unencumbered by visuals. I've written at least
| 500k LoC on in my life, maybe double that, I don't know.
| That's all pure thought and logic. So I get the
| agitation: All I want to get across to you, my reader, my
| employer, is the information, my distilled ideas. That's
| all that's important. Read it or don't, I don't care,
| it's good and the logic works.
|
| I'm also trained as a designer. My first several jobs
| were in ad agencies, since I was 14 years old as an
| intern. _How will people subconsciously interpret the
| ancillary visual aspects of this_ is something I learned
| early on: _what will they construe?_ Because bad design
| can prejudice someone against a great piece of writing,
| and vice-versa.
|
| No visual thing you can make has zero cultural reference;
| everything you make that other people will see drags some
| bundle of pre-understood tropes into it. You can't make
| one without referencing some aspect of culture that
| affected you. The job of a designer - what makes a
| designer different from someone who just has aesthetic
| chops and can tell if a web page looks good - what
| constitutes the black arts of design - is to _know every
| single cultural trope you are dragging in front of the
| customer 's target audience_ and to understand how it
| will psychologically affect their state while they read
| the content, so you know how to trigger certain emotional
| resonances in them while they absorb the information the
| client is trying to get across.
|
| That's what "giving a shit" means in terms of
| communicating visually.
| vntok wrote:
| Facebook cares, right? Given their impact, their
| resources, their objectives, they of all companies must
| "give a shit". Right?
|
| So here are the fonts of the Facebook posts listed on a
| Facebook user's wall:
|
| > Helvetica, Arial, sans-serif
|
| > system-ui, -apple-system, BlinkMacSystemFont, Segoe UI
| Historic, Segoe UI, Helvetica, Arial, sans-serif
|
| Observe how there's no custom font, no weird font, and no
| "associations with some childhood Disney movie" to be
| found on a page seen and used by 2+ billions of users
| daily.
| noduerme wrote:
| Funny you should bring that up, because FB is a perfect
| example of a visual relic from the late '00s which didn't
| age well. Much of the post-dot-com-crash world of design
| in the web and early mobile space was defined by a
| rejection of the excessive - wild crazy idiotic
| irreverent and often incoherent - typography and design
| of the '90s web. So, super basic fonts, white
| backgrounds, and what they thought was "minimalism".
| However, because they relied on the tooling rather than
| creating their own cues, (and also because their UI
| turned into a towering nightmare of crap) Facebook looks
| extremely dated to most people's eyes now. It looks like
| a 20 year old website...and not a particularly good one.
|
| My outside opinion is that Meta does not give a shit at
| all about how Facebook looks at this point. I'm not here
| to make the case that revolutionizing their design would
| improve their onboarding rate now or something. I'm
| making the case that if you are some nobody with no
| network effects and no billion dollars, you have a better
| chance at getting people to read your content if you take
| the time to (a) get it out of system-ui fonts and (b)
| make a bunch of other aesthetic decisions that trigger
| certain pleasing feelings in your audience.
| Izkata wrote:
| Facebook got modernized multiple times and doesn't look
| at all like it did 20 years ago.
| noduerme wrote:
| hard to tell with all the cruft but I'll admit I'm not a
| user. The point stands about the shift in web design in
| the early 2000s
| asdboch wrote:
| Could you recommend any good books, video series, blogs,
| or other training for those that who need to understand
| fonts at your level professionally? Or maybe you could
| write one?
|
| I know someone that is trying to break into this space
| but doesn't have the past experience, and it's almost
| impossible to catch up. I'd love to provide them with a
| resource.
|
| In defense of Comic Sans, it's not just for realtor
| pages. It can be effective for local, casual
| communication by appearing friendly and approachable. If
| I saw a flyer pinned to a corkboard advertising a fish
| and chips special in Comic Sans in a seaside town, my
| mouth would be watering, because I'd know that's a mom
| and pop place that focuses more on the food and taking
| care of people than the marketing.
| noduerme wrote:
| >> If I saw a flyer pinned to a corkboard advertising a
| fish and chips special in Comic Sans in a seaside town,
| my mouth would be watering
|
| Heh. You absolutely nailed the concept. This is precisely
| right. Comic Sans is a totally crap font, but it's
| _great_ if that 's the feeling you want to get across!
| That's exactly how thoughtful design works. Level one is
| to know your references. Level two is: Use the kitsch
| when you want it. Use the profane. Use the found art.
| Then use the "classy" or "expensive" when you want to
| show a "classy" client. Level 3 and up is knowing how to
| play with those high and low cultural notes to make a
| kitschy client still look kitschy but subconsciously
| implant that the fish is of a slightly better quality; or
| make your "classy" real estate agent still look "classy"
| but show that they aren't a stuffy asshole. And do this
| without either client outright complaining.
|
| Far as books, I'd qualify by saying that I learned the
| design craft on the job from an early age and was tutored
| by great art directors who let me experiment and
| explained these things to me; why what I was
| communicating with a certain background or certain font
| was going to negatively affect a consumer in a way I
| hadn't considered. And I had a couple great professors in
| college (but I dropped out). Most of the basic theory of
| the higher level of how to use this stuff to influence
| people is contained in Marshall McLuhan's "Understanding
| Media", which is the quintessential work on how one - in
| a design role - can change perception of the content of a
| piece by making informed psycho-sociological choices
| about the way it's presented visually. Lots of master
| works before and since on the concept of propaganda, but
| for designers McLuhan helpfully narrows it down to show
| that presentation is often more important than content,
| and for designers this means your role is essentially to
| master content the way an audio engineer masters a band's
| album. Which is often as important to the final output as
| the original recording quality itself. This is especially
| hard to do if you also _wrote the content_ because it
| requires a certain objectivity about the work. Anyway,
| McLuhan 's theory is timeless and kind of essential to
| get into the guts of everything: How brands work, how
| small design choices work, etc.
|
| Being able to _explain_ the difference between what looks
| good and being able to explain _why you chose it_ (along
| with all the cultural references, positive and negative,
| which the choice is intended to trigger in the audience)
| makes the difference between a $40 /hr design job and a
| $150/hr art direction job, so mastering the technique of
| selling the technique has a certain benefit as well. But
| you must come armed to your client with examples. The
| best way to learn is to look at everything you see around
| you and question all their design choices, why did they
| use those colors, those fonts, etc. and also see what
| trends are developing. Go back to the 1950s, 60s, 70s,
| 80s, 90s and see what they were using then. Now who is
| your target audience, and what feeling do you want to
| give them?
|
| [edit] Just want to add: I was a purely technical child
| who learned to code and run a BBS way before I knew
| anything real about design. I came up doing what I
| thought was cool ANSI art and then "designed" some stuff
| in Photoshop 3.0 for people when I was 12. I didn't
| understand anything. When you're a technical person you
| tend to see design as a problem to solve with programs
| and with code. You don't realize that _design is a
| programming language that runs on human brains_. This was
| a revelation for me when I was about 15, and it 's
| informed all my choices since. So yes - fonts matter.
| jamiecurle wrote:
| > Could you recommend any good books
|
| The Elements Of Typographic Style by Robert Bringhurst
|
| "Five minutes to learn, a lifetime to master" kind of
| thing.
| JimDabell wrote:
| > System fonts were initially created for legibility at
| certain screen resolutions, for dot-matrix printers, etc.
|
| I think you've gotten mixed up between the _system-ui_
| font and _the browser default_ font.
|
| The system-ui font is modern. It was only added to CSS
| about ten years ago. It's not Times New Roman. It wasn't
| designed for dot matrix printers.
|
| Everybody else here is talking about something that fits
| in with the rest of the system. You seem to be talking
| about something from the early 90s.
| noduerme wrote:
| Most current system screen fonts in major OSs - as a
| general group, as a set of letter forms - are not and
| never were printed fonts. They evolved from bitmap fonts
| that were created with 90s constraints in mind. They
| retain some of that aesthetic, and they are not usually
| the best candidate for the job.
|
| Leaving it up to your user's system font is also an
| arguably poor choice.
| alwillis wrote:
| > Most current system screen fonts in major OSs - as a
| general group, as a set of letter forms - are not and
| never were printed fonts. They evolved from bitmap fonts
| that were created with 90s constraints in mind. They
| retain some of that aesthetic, and they are not usually
| the best candidate for the job.
|
| This couldn't be more wrong. Things have progressed since
| the '90s.
|
| Apple, Google, Microsoft hired real typographers to
| create their new fonts. Apple uses San Francisco in their
| printed materials all the time.
|
| On Apple devices, system-ui is San Francisco, a TrueType
| variable font with 2937 glyphs, 4 axes and 369 instances.
| The axes are width, optical size, grade and weight. San
| Francisco also has all of the goodies someone who cares
| about typography could want: ligatures, small caps,
| contextual alternatives, true fractions, etc.
|
| I think this qualifies as "giving a shit". ;-)
|
| BTW, you can see each named instance in the developer
| tools in Firefox and Chrome on macOS.
|
| An instance is a combination of the 4 axes; the instance
| of San Francisco compressed thin uses can be specified in
| CSS as: font-variation-settings: "wdth"
| 47, "opsz" 28, "GRAD" 400, "wght" 120.702
|
| Apple went into detail a few years ago about creating San
| Francisco [1][2].
|
| So developers/designers get all the features variable
| fonts have to offer without having to download anything.
|
| Google has done something similar with Noto.
|
| [1]: "WWDC Introducing San Francisco, the New System
| Fonts" -- https://www.youtube.com/watch?v=OpveNRh-jXU
|
| [2]: "Meet the expanded San Francisco font family" --
| https://developer.apple.com/videos/play/wwdc2022/110381
| sgarland wrote:
| Rebuttal / question: what about Web1.0 sites that still
| exist? Is the subconscious connotation that they're dated
| also carrying an air of wisdom? Or do the people using
| them simply not care? Personally, I feel as though I fall
| into the former camp, mixed with a healthy dose of
| nostalgia for my youth.
|
| Some examples, in no particular order:
|
| NIST's page [0] on TIME Protocol (RFC868 [0.a]) - as an
| aside, TIME has to be the simplest (in terms of crude
| utilities; obviously there exist simpler ways to find the
| time) and most delightful way to find the current time
| that exists. See [4].
|
| Great Britain's National Grid Status [1] - warning,
| doesn't render well on mobile.
|
| No Answers In Genesis [2] - a primer on evolution /
| someone's personal vendetta against creationism. Good
| thing it's Web1.0, because the latency to AUS would be
| horrible.
|
| Frank's Compulsive Guide to Postal Addressss [3] - if you
| have any questions about the address system of any
| country in the world, it is answered here. An absolute
| treasure trove of information.
|
| 0: https://tf.nist.gov/tf-cgi/servers.cgi
|
| 0.a: https://www.rfc-editor.org/rfc/rfc868
|
| 1: https://gridwatch.templar.co.uk/
|
| 2: https://www.noanswersingenesis.org.au/
|
| 3: https://www.columbia.edu/~fdc/postal/
|
| 4: Requires GNU coreutils for `od` and `date` - also if
| you get round-robined onto a server that doesn't support
| TIME, try again. nc -w1 time.nist.gov
| 37 | od -An -tu4 -N4 --endian=big | awk '{print $1 -
| 2208988800}' | xargs -I{} date -d @{} #
| EDIT: you can further shrink this by doing everything in
| awk, assuming GNU awk nc -w1 time.nist.gov 37 |
| od -An -tu4 -N4 --endian=big | awk '{print strftime("%c",
| $1 - 2208988800}'
| noduerme wrote:
| I think you can guess the boundaries of the design answer
| here.
|
| When you're experimenting with a new technology,
| everything looks very different and everything looks new.
| When you look at the net result of people experimenting
| with it 30 years later, you can see that they were all
| constrained by the same limitations, and in aggregate -
| despite many differences - everything takes on a
| recognizable aesthetic that was produced by the
| limitations of the day, the technology, the genre,
| whatever.
|
| These sites are all wildly different and extremely
| creative, yet they're all recognizably from the same
| decade or so.
|
| Okay. Now step back from that. Humans - you, me, everyone
| - have learned a very complex visual language from birth,
| where certain cues indicate certain things and trigger
| certain memories. If you show me a picture of a dude
| wearing bell bottoms, we're probably in the 70s. If it's
| a girl with a nose ring and a midriff showing it's
| probably 2005 - but there are smaller cues within that.
| 99% of people don't think about this consciously when
| they see an image, or a website, or whatever. They just
| associate it with a time or a genre.
|
| In design for the web, we've had decades of constraints
| come and go - we had Flash with its own weird aesthetics,
| Java embeds, etc. People remember a _time_ and they
| associate a design style with that time, without really
| knowing why. So it 's a question of choosing from that
| historical library and constructing something that makes
| people see what you want them to see. If you want them to
| associate something with the early 90s, then totally make
| it look like one of these pages.
|
| The thing I was taught in design school was to attempt to
| make design that was timeless. This is always kind of
| impossible - because you're limited technologically in
| ways you don't even realize at the time, and because
| you're always influenced by what's around you. But _try_
| to make something that will look, in 20 years, like it
| was new. Very hard to do. Why do it? Because in 20 years,
| you can always go and make funny vintage pastiche
| references to what people did 20 years ago. But it 's
| quite hard to make anything that doesn't show its age.
| sgarland wrote:
| Thank you for the sincere and in-depth response. I hadn't
| really meant mine to be troll-esque, but I can see how it
| could come across that way.
|
| My favorite comparison of two sites from the same place
| is HAProxy: haproxy.com is the one meant for the C-Suite
| to be impressed, and haproxy.org is the one meant for
| people who are running it. It's also the reason that I
| suspect it's not just nostalgia that makes me think of
| text-heavy sites as being more authoritative (unless it's
| a share delusion by elder millenials, I guess). If you're
| going there, you probably are interested in finding a
| specific answer in technical documentation, not a sales
| pitch.
|
| Zooming out to other industries entirely, look at cars:
| it's generally pretty easy to guess the decade of a car
| if you have any interest in them. However, with some, the
| designers have occasionally managed to blend the
| different eras together in a way that I would argue
| borders on timeless. The canonical example, IMO, is the
| Porsche 911. Before the 996 model, it had a certain look
| about it that updated, but didn't change. The 996 had the
| oft-mocked "fried egg headlights" (plus it was water-
| cooled, which angered purists), but other than that, it
| started a more gradual shift in the looks of the car. The
| 997, 991, and 992 all look remarkably similar from many
| angles, assuming all are wing-less. That's 21 years of
| models. Also, the 992 changed its rear vents to a
| vertical rather than horizontal configuration, which
| hasn't been used since the 911's predecessor, the 356 - a
| car that ceased production in 1966. That subtle change,
| along with some typography for the logo, makes it look
| way older than it is, but in a good way.
| munificent wrote:
| Counter-point: You certainly do, but mostly subconsciously.
|
| People, especially "left-brained" types, _massively_
| underestimate how much aesthetics affect their
| psychological state. You are not a being of pure reason
| manipulating mathematical symbols in a pure abstract
| aether. You 're a primate with a half-dozen crude senses
| that evolved mostly to make sure we didn't die from getting
| eaten by sabretooth tigers or eating spoiled fruit that
| only very recently monkey-patched that wetware into sort
| being able to reason about abstractions using a big messy
| pile of analogies and visualizations.
| kevincox wrote:
| Or you can leave the default so that the reader gets the font
| they want, because they are the one reading it so it doesn't
| really matter what the author thinks looks good unless it is
| somehow relevant to the text.
| Levitz wrote:
| How often is the default the font the reader wants, as
| opposed to the one that just comes with their OS?
| array_key_first wrote:
| Those are equivalent. You can just open your settings and
| change the font to whatever you like.
|
| Also, if were really going off the argument of design -
| your font choice is almost certainly worse than whatever
| the OS does by default.
|
| The OS, most likely developed by a multi trillion dollar
| corporation, probably chose a font that's highly legible
| and simple in a broad array of contexts.
|
| Your font might be cooler, but is it better? Fat chance.
| smolder wrote:
| Unfortunately efficient CSS is a lost cause. I love doing this
| kind of work and making single page efficient product.
| Unfortunately no one cares how you spend your bytes because it's
| a battle between sociopaths and everyone tired of their shit.
| smolder wrote:
| I could make cool websites for the losers who rob everyone
| around them but the type of people who make a business out of
| online behavior are actually terrible greedy folks.
| cookiengineer wrote:
| You are speaking from my soul, man.
| aborsy wrote:
| What are good static site generators (SSGs) to create a simple
| minimalist academic-like website?
|
| It seems Astro or Hugo (potentially with Tailwind to customize
| CSS) are good options. Astro felt more complex than needed, on
| the other hand, writing html/css manually doesn't work well
| either (predefined layouts and easy to use style customization
| options would be needed). I couldn't find a suitable Astro theme
| either (most themes seem to be made for companies, or needlessly
| fancy, and a few for individual blogs).
|
| In the process of figuring this out, I was surprised how
| complicated designing a website has become. There are so many
| frameworks, components, integrations and significant dependancies
| that I wondered how web developers keep up in this ecosystem.
| xxmarkuski wrote:
| Maybe look into Eleventy [0] or Zola [1]. Both are relatively
| recent developments and have a skilled and forward thinking
| userbase.
|
| [0] https://11ty.dev/
|
| [1] https://getzola.org/
| smolder wrote:
| This line of conversation is distracting people from the
| embarrassing state of the WWW.
|
| If anything good is left outside the temples of Facebook, etc,
| it's not much, and I'm embarrassed.
| zelphirkalt wrote:
| There are many threads here on HN about that as well. But
| this thread here is about CSS styling.
| amoshebb wrote:
| Not that you need more choices, but franklin.jl hit my sweet
| spot for "handles math and code inline well, otherwise is clean
| and gets out of my way"
| sixtyj wrote:
| It is a natural entropy of web system.
|
| We could not hope that everything would remain simple. Thanks
| for all the open standards and frameworks that we don't have to
| license.
|
| And yes, it is a paralysis of choice.
| FranzFerdiNaN wrote:
| No need for a SSG. Just copy something like this:
| https://thebestmotherfucking.website and make every page by
| hand like you are some 80 year old greybeard.
| bonoboTP wrote:
| Yeah, I got fed up with all the dependencies and processes
| and workflows and configurations and just manually made my
| site like it's 2004, just hand-written HTML+CSS+JS. As long
| as it's a small personal site, this is very robust and there
| is no constant churn and deprecations and change for the sake
| of change.
| turnsout wrote:
| I have a couple of 100% handwritten sites as well. The
| challenge is when they go beyond about a dozen pages. If
| you want to change something across pages that isn't a find
| & replace, like adding a meta tag, it starts to be a drag.
| I'm going to be converting one of those sites to Swift
| Publish soon, as it's a low-dependency framework that
| hasn't been updated in years.
| bonoboTP wrote:
| Sure, but many people just want to have a super basic
| academic site with like 1 or 2 pages ("simple minimalist
| academic-like website" as it was phrased upthread), and
| then start to fiddle with a million frameworks and the
| compilation chain is broken in a few months when you want
| to add your new publication to the site, and you have to
| dig through versions and dependencies and environments
| and CI/CD and whatnot. When you could just type up your
| site in one afternoon by hand and it will keep working
| indefinitely.
| aborsy wrote:
| I experimented with customizing a flat page by writing HTML
| and CSS manually, with some help from LLMs. Using this
| approach, it's possible to create something resembling the
| website you linked.
|
| The result is decent, though the organization of the long
| page could be improved. In my view, a good personal website
| would include space for a photo, name, and affiliation, along
| with a simple menu for sections like biography, publication,
| projects, with a professional style (font and colors), but no
| more complex. The publication page could have a style for
| presenting papers in a clean well-formatted list. That may
| require a theme that comes with a layout and a degree of
| customization and novelty.
|
| A lot of themes I looked into are not quite professional.
| dlisboa wrote:
| For what most people are doing with static site generators
| (blogging) going "raw" HTML is honestly not a bad choice.
| Most usage of Markdown is just to avoid writing tags. It's
| not a whole lot more work to write `<em>foo</em>` instead of
| `_foo_`.
|
| HTML was meant to be hand-authored, not a compilation target.
| It's like if people forgot you can still cook rice without a
| rice cooker.
| dijital wrote:
| Quarto (https://quarto.org/) is well regarded in academic
| publishing and supports website projects:
| https://quarto.org/docs/websites/.
| aborsy wrote:
| Thanks for mentioning it, it has relevant templates,
| including an interesting one for a class.
| fragmede wrote:
| if you've been ai-pilled, just have Claude generate it for you
| from the .MD files you wrote by hand
| ivanjermakov wrote:
| Ask LLM to write a 50 LOC program to convert directory of
| markdown files to directory of html files using pandoc.
| nextlevelwizard wrote:
| This actually might be the "correct" solution these days.
| Pre-LLMs I wrote myself a python script to that converts
| markdown to html with custom headers and footers and rest of
| the junk, but today I would for sure give LLM a go first and
| see if what it produces.
| turnsout wrote:
| Having done a fair amount of LLM webpage generation, it
| does an okay job, but repeats a lot of "best practices"
| that are a few years out of date. Specifically around meta
| tags.
|
| If I were doing this, I would have it do Deep Research or
| similar on the most minimal, efficient set of tags to
| include in the `head` tag in late 2025.
|
| It's possible you can get away with a bunch of .md files,
| but you will need a file to store site-wide metadata and/or
| YAML "front matter" in the MD to define page-specific
| variables.
| Vinnl wrote:
| If you really believe things were easier in the past, then just
| do what you did back then. It'll all still work.
| loldot_ wrote:
| I use github pages with jekyll. It took a bit of time to make a
| custom theme and setup the custom domain, but its really simple
| now to just add markdown file and push to github.
|
| https://github.com/loldot/loldot.github.io
| ImPleadThe5th wrote:
| You can find CSS only themes or Tailwind themes to use with
| Astro or Hugo.
|
| I personally liked Astro's approach to "Components", less glue
| more "just writing html/md". That is of course a learning curve
| on its own.
| mb2100 wrote:
| > I was surprised how complicated designing a website has
| become.
|
| Sounds like you would enjoy https://mastrojs.github.io - a
| _minimal_ Astro alternative.
| rossant wrote:
| I like this. But a screenshot after each step would be nice.
| vjk800 wrote:
| I didn't even read the article, but the answer is clearly zero.
| paulddraper wrote:
| Browsers default to serif.
| dijit wrote:
| if people hate it that much then maybe we should consider
| changing the default?
| rplnt wrote:
| Which is an option browsers give you.
| 867-5309 wrote:
| "we" the applooglezilla mediators..
| paulddraper wrote:
| Agreed.
| pinkmuffinere wrote:
| Would this seriously stop you from reading something? How on
| earth did you survive your college textbooks and lecture
| slides?
| tuetuopay wrote:
| Serif is meant to be printed, on paper, with the ridiculous
| DPI of printers.
|
| These fonts have not been designed for pixelated displays.
| Yes, it's better on Retina / HiDPI displays (I even enjoy
| some serif fonts on those), but those have to be designed
| with pixels in mind. But they usually are atrocious on
| "classic" pixel densities.
|
| And tangent: the print industry has a much wider typeface
| selection than "just" Times New Roman, which is rather rare
| in my personal experience (sample size of one, though).
| notapenny wrote:
| Yes it would. People have no choice but to read college
| textbooks. They do have a choice when it comes to the
| usability of your site. You might not care, but you are not
| your users.
| paulddraper wrote:
| I'll remind you the criteria was "decent" not "possible to
| interpret."
| anon7000 wrote:
| Default styles are barely usable on mobile, especially when it
| comes to images. They said "decent looking," after all.
| shahzaibmushtaq wrote:
| Improve the readability and bring clarity, then work on
| modernity.
| stanac wrote:
| An old article, in some regions still relevant, on why not to use
| system ui font family.
|
| https://infinnie.github.io/blog/2017/systemui.html
| IshKebab wrote:
| Interesting, though I'm not sure I want to take font advice
| from a website which such an awful st ligature!
| fleebee wrote:
| I wasn't aware of this phenomenon. I did some digging and this
| is apparently indeed still an issue on CJK Windows.
|
| This PR to Bluesky has more recent discussion about it and
| offers workarounds:
|
| https://github.com/bluesky-social/social-app/pull/6139
| rbits wrote:
| Unfortunate, because I like websites using my font choice
| WhyNotHugo wrote:
| "sans-serif", "serif" and "monospace" still resolve to your
| chosen/preferred font too.
| sph wrote:
| So the strongly worded argument is just because on one locale
| of an unsupported proprietary system, which renders their
| entire desktop and applications with an abysmal font, you might
| get your website rendered with an abysmal font?
|
| What if you get a terrible font choice on the standard `font-
| family: sans-serif`? Should all my visitors have to download
| 100 KB of external fonts because Microsoft are inept?
|
| Meh, for my personal website, I'll keep using system-ui.
| antonvs wrote:
| The issue is broader than that. The article's addendum points
| out that both Bootstrap and GitHub removed system-ui from
| their font stack, and another comment in this subthread
| mentions that Bluesky has done the same. In each case there's
| a link to comments and/or a PR which gives reasons.
|
| Bootstrap later added it back, but in the PR discussion it
| was pointed out that this is still an issue on Chinese and
| Korean Windows, at least.
|
| > Meh, for my personal website, I'll keep using system-ui.
|
| Well sure, but in that case you could also use your own
| personal language that no-one else knows.
| tosh wrote:
| Interestingly Bootstrap has removed "system-ui" in 2017
|
| https://github.com/twbs/bootstrap/pull/22377/files
|
| but it's back in the current one:
|
| https://github.com/twbs/bootstrap/blob/main/scss/_variables....
| Thorrez wrote:
| It was added back in 2020 by
| https://github.com/twbs/bootstrap/pull/30561
| chrismorgan wrote:
| > _img { max-width: 100%; }_
|
| This _must_ be paired with `height: auto`, or your image's aspect
| ratio will be messed up if the width gets capped.
|
| > _img, svg, video { max-width: 100%; }_
|
| ... but beware, Chrome 141 has CSS width/height work on nested
| SVG elements, and auto is being miscalculated. Workaround is to
| change the `svg` to `svg:where(:not(svg svg))`.
|
| > _We'll just use a basic system-ui for this example. It has
| pretty good support these days, and looks good on every system
| without having to worry about loading in any extra fonts._
|
| Please don't. system-ui is a font for matching the _system UI_.
| The UI font is often not good for long content, and in some less
| common OS /language combinations it's almost unusable. Stick with
| sans-serif if that's what you want. People have been using
| system-ui as a proxy for a maybe-better sans-serif. This is not
| what it is, and it is bad to use it so.
|
| > _In general, the font-size is a little small as well, so we can
| bump it up_
|
| This is acceptable for larger screens. I reckon 18-20px is a
| reasonable target, so 1.25rem is fine. But on small screens,
| please don't go above 1rem, it's the platform's customary size
| and you don't have the space to waste.
|
| > _the default line-height is always a bit tight, so anything
| within the 1.5 to 1.7 range should do_
|
| Ouch. 1.7 is _huge_ on smaller displays. If you want a single
| value, I suggest 1.4-1.5. If you want to vary by width, 1.4 on
| small displays up to 1.6 on large will be reasonable.
|
| > _font-family: System UI;_
|
| That's a second glaring error you should instantly observe if you
| use the stylesheet. I am not encouraged about its quality.
|
| > _Some people prefer a dark system theme, but light website
| themes, and vice-versa._
|
| _Sensible_ browsers let you separate the two. Firefox defaults
| to having content follow the system theme, but you can change it
| to just light or just dark.
|
| > _main { max-width: min(70ch, 100% - 4rem); margin-inline: auto;
| }_
|
| This is effectively giving a minimum 2rem margin. Well, actually
| 2rem + 8px once including the default body margin. That's _way_
| too much, and applied in the wrong way.
|
| If you wanted to apply it to the main element, it would be easier
| and I think more logical to use padding: main {
| max-width: 70ch; padding-inline: 2rem; margin-
| inline: auto; }
|
| But I doubt that you actually wanted to apply it to main: if you
| have a site header or footer outside that, you probably still
| want the same side padding. So it's probably better to use body
| margin: body { margin: 1rem; }
| main { max-width: 70ch; margin-inline: auto;
| }
|
| ... and I have there decreased it from the wildly-excessive ~40px
| to the reasonable ~16px.
| easyThrowaway wrote:
| Realistically much of those layout differences and fine tunings
| would be handled by media queries, but by that point the amount
| of code compared to a decently written website with a "regular"
| amount of CSS would be pretty minimal.
| peter-m80 wrote:
| this is a must
|
| * { box-sizing: border-box }
| qbane wrote:
| I prefer the following to ensure the interoperability of
| external libraries:
|
| `body, html { box-sizing: border-box } * { box-sizing: inherit
| }`
| noduerme wrote:
| I don't get it. I mean, yeah I get wanting to make extremely
| minimal web pages that are readable on every screen. But if
| that's your goal, the solutions are pretty well understood. Who's
| the target audience for this, i.e. who are the people who are
| trying to make a bare bones web page but just struggling with
| `max-width` - and why's it at the top of HN?
| sebtron wrote:
| > who are the people who are trying to make a bare bones web
| page but just struggling with `max-width`
|
| Anyone making a personal website?
| noduerme wrote:
| If you want to make a personal website, you have two routes:
| Use a template thing like wordpress, with a GUI, or learn at
| least a bare minimum of HTML, CSS and probably some
| Javascript, as well as how to set up a server. What's offered
| in this article is not very useful to making a personal
| website... it's like if you wanted to bake a cake, and you
| read an article saying that frosting is made from sugar and
| butter. This isn't _news_ and it 's it's not particularly
| useful to baking _your cake_ either.
|
| Just to like, follow up: 99% of the point of making _your
| personal website_ is, like, _making it fucking personal_
| which is to say that you put your own time and energy into
| _learning something in the process_. Copy /pasting random CSS
| from the web is not learning. Also, copy/pasting this
| _particular_ CSS is not even showing the slightest bit of
| interest.
|
| So consider: Why would anyone care about your personal
| website if you don't care enough to learn how to make it, you
| know, _personal_ by actually learning a tiny bit about the
| art you 're trying to put into practice?
|
| And none of this even starts to explain why this junk would
| be popular here. There are some _brilliant_ CSS hacks in the
| wild that deserve attention, but this is sub-par even for
| child 's play that might teach you how to do something
| useful. It's not even a lesson. It's just some crap you don't
| understand that you might copy and paste, with almost no
| explanation.
| monadgonad wrote:
| Me. I'm a backend developer who occasionally wants to make a
| web frontend for a side-project but knows essentially no CSS.
| The solutions are not "well understood" by me because I know no
| CSS.
| berkes wrote:
| > occasionally wants to make a web frontend
|
| In that case I'd say the problem is exactly what you state
|
| > knows essentially no CSS
|
| The solution is quite obvious then too: learn some. It's not
| hard. Understanding the basics is a afternoon job. Diving a
| bit deeper a day, and learning about some often-used more in
| depth features like "responsive" or flexbox, another day. For
| a software developer/engineer that builds backends, CSS
| really isn't that hard.
|
| That's not to say a basic CSS set and some explanation like
| in TLA, isn't useful.
|
| It's my pet-peeve that in software development, I'm convinced
| we should understand the stuff that we work with. Not all,
| and certainly not everything in great detail, but enough to
| know where to find the info and details when working with it.
| From sysadmin to the concepts of cryptography and from
| accessibility to how an OS writes stuff to disk. Even if that
| means constantly learning.
| stephenlf wrote:
| > The solution is quite obvious then too: learn some.
|
| That's the whole point of this article. CSS is a huge
| language. Where do you even begin? This article is a
| perfect response to that very natural question.
| noduerme wrote:
| It really isn't a huge language. It's not even a
| _language_. There are some basic principles, but it 's
| pretty much a bunch of pick-and-choose attributes for
| HTML that you can wrap up into "classes". I've worked
| heavily with it for 25 years and I still basically just
| screw around until something looks good.
|
| There is no point to this article. This is the most
| common kind of trash you can find if you type in "minimum
| css"... it's not even that. Come on. Have integrity in
| your work and learn how to do it.
| noduerme wrote:
| C'mon. I'm a full stack dev but this is like me saying I just
| want to code something quick in C++ but don't know anything
| about it. Maybe I don't know how to tell a pointer from a
| shared_ptr or what a destructor is. Even if I don't know how
| to do them, I'm pretty aware that these things are _very well
| understood and documented_ by a huge community, to the point
| that I probably wouldn 't rely on some AI-written article
| with almost no useful information to show me how to do what I
| wanted to do... I'd want to actually learn what was going on
| under the hood... and if I _did_ somehow find such an article
| useful to explaining pointers in the most vapid way possible
| for my use case, I certainly wouldn 't post it to HN. And if
| I _did_ post it to HN and it suddenly ranked to the top, I
| would think something had gone completely wrong with the
| universe.
| monadgonad wrote:
| > very well understood and documented by a huge community
|
| Is this article not someone in the community documenting
| what's understood? I'm sorry if it doesn't meet your
| expectations, but it's fine for me.
| noduerme wrote:
| It's an objectively terrible article. It gives a bunch of
| arbitrary things to copy without really explaining them,
| and it is completely useless for building anything real.
| It is probably written by an AI. It's trash. What on
| earth makes you think it deserves more attention than the
| other million useless articles on this subject?
| 8474_s wrote:
| max-width: min(70ch, 100% - 4rem); Results in one tiny column of
| text on desktop, both sides are empty margins. Its an interface
| exclusively for mobile phones.
| jesus_666 wrote:
| It's an implementation of an old recommendation to never have
| more than 80 characters per line, ostensibly to limit
| horizontal eye movement but mostly stemming from legacy
| 80-character terminals and punch cards.
|
| The value of that recommendation is rather dubious considering
| today's high-resolution displays that allow for smaller font
| sizes. 80 readable characters at 768p are not the same as 80
| readable characters at 4K.
| CyMonk wrote:
| It actually goes back to mechanical typewriters, which were
| limited to 70 to 90 characters per line. Commonly used punch
| cards also had 80 columns. Both were the inspiration for the
| 80 characters in computer terminals.
| rsolva wrote:
| Weeel, actually! ... It dates back to the early days of the
| printing press, and has been a general convention since
| then.
|
| Rules can be broken, but not without consequence.
| the_other wrote:
| As someone who uses screen zoom tools constantly, I vote in
| favour of the 80ch column width recommendation. If you want
| to support extra wide monitors, consider using multiple
| columns, rather than a single, wider one.
| crote wrote:
| Multiple columns don't really work with websites, as web
| content almost always going to be vertically scrollable.
|
| Columns work great for things like a navigation sidebar or
| an image grid, but it just doesn't play nice with long-form
| blog content.
| trashb wrote:
| The 50-70 CPL is, in general, just well suited to reading.
| This has been researched, and by quickly searching I can find
| the following (beautifully layed out) paper:
| https://journals.uc.edu/index.php/vl/article/view/5765
|
| To my surprise the paper actually concludes that fast readers
| prefer shorter line length.
|
| Edit: Usually books and newspapers are also more or less in
| compliance with this convention and those where around since
| before computers where a thing.
| stephenlf wrote:
| `100% - 4rem` is for mobile. `70ch` is for desktop. The tiny
| column is intentional. It offers a better default reading
| experience than a widescreen monitor full of text.
| driverdan wrote:
| I hate this. Give us a small amount of padding and text wrap.
| Let users with large screens resize their browsers to whatever
| width they want. This isn't 1985, we don't have terminals with
| only 80 characters per line.
| ponooqjoqo wrote:
| > Let users with large screens resize their browsers to
| whatever width they want.
|
| Do people actually do this? I have like 10 tabs in a
| maximized browser window. Am I supposed to keep unmaximizing
| it and fidgeting with the width? Or am I supposed to just rip
| the tab out and have to deal with multiple browser windows?
| driverdan wrote:
| You run a large, high resolution screen with your browser
| maximized?
|
| I have a 4k screen. Most of the time I keep my browsers
| half width. For most sites it seems to be the best use of
| screen real estate. Even at half width that site's CSS
| restricts the width of the content too much, leaving a lot
| of wasted padding on either side.
| lloydatkinson wrote:
| I still believe there should be a `unset user agent styles` that
| could be set somewhere in the document. Why make devs ship reset
| CSS if they are going to be undoing all your pretty janky default
| styles anyway? Here's a list of arguments and refutations I know
| this suggestion is going to get:
|
| > But a browser should have a minimal set of default styles!
|
| They always have done. My suggestion does not affect that.
|
| > Websites shouldn't be able to turn off default stylings!
|
| Many already literally are, either through CSS resets or simply
| doing h1 { color: red }.
|
| > What's the point!?
|
| There's a dozen or so popular CSS resets that literally overrides
| all the browser default styles. It would save time and data to
| not ship the same styles over and over again.
|
| > It's impossible!
|
| No, no it is not. Simply inform the browser to apply no styling
| at all. This would be a straightforward feature for browser
| implementors to create.
| Tepix wrote:
| What about all: unset;
| paulddraper wrote:
| That works.
| futurecat wrote:
| I am personally a big fan of the https://every-layout.dev
| philosophy.
| trashb wrote:
| Or if you want to go even more extreme. Without CSS:
| https://nocss.club/ Without HTML: https://no-html.club
|
| Something similar to plain text can be created with the <pre> tag
| in HTML if you like to add metadata to your page.
|
| Make sure to linewrap on your prefered 50-70ch limit for our
| reading pleasure, otherwise I will be adding the
| style="width:70ch" locally to your body tag.
| stephenlf wrote:
| Kevin Powell makes wonderful content. I am saddened by the
| negative responses here. This article is a great intro for the
| absolute beginner to dip their toes into CSS.
| sph wrote:
| I've been writing CSS for 25 years and still I bookmarked this
| link. Unless you're a masochist and keep up to date with
| frontend dev, there is always something new to learn. I didn't
| know about the `color-scheme` attribute - saves me a lot of
| work! Never heard of `margin-inline` either.
| brettermeier wrote:
| It's kind of crazy how many properties there are... I've been
| working with CSS for a long time and have never heard of
| "margin-inline" either.
| lelandfe wrote:
| IMHO you should completely ignore the -inline/-block
| "logical" properties until you one day are making a site in
| traditional Mongolian or perhaps fanciful Japanese.
| Preparing for that day is unwise.
|
| It does make it kind of useful to write one line centers
| instead of two, but at the expense of people _kind of_
| needing to learn about damn logical properties when they
| read your code /blog.
| LorenzoVella wrote:
| Fair, but skipping logical properties is just asking for
| trouble down the line. They make layouts way more
| predictable across languages and writing modes, and once
| you get them, simple stuff like one-line centers barely
| costs extra. It's future-proofing, not overengineering.
| lelandfe wrote:
| I will feel deep burning shame in the decades hence when
| traditional Mongolian becomes our lingua franca and my
| CSS must be slightly changed
| WorldMaker wrote:
| Given how many people prefer to use the 4-property
| shortcuts even when that doesn't make sense, teaching the
| 2-property shortcuts seems like a good thing, even if you
| don't expect to support localizations where they matter
| the most.
|
| Also, in my experience they interact with Flexbox and CSS
| Grid in useful ways that sometimes the "logical"
| properties are much easier to reason with than the
| 4-property versions or the individual property versions.
| evrimsel wrote:
| Hey, that's a really constructive take. I appreciate you,
| man.
| andrei_says_ wrote:
| CSS has been improving with lightning speed. If you have
| experience writing it, this is a golden age for applying
| these skills.
| rrrx3 wrote:
| I love how quickly things are being added. It has really
| started to make up for years of stagnancy and "I wish CSS
| could..."
| s20n wrote:
| The man is a legend. I remember watching his videos when I was
| just starting out.
| johnnyanmac wrote:
| I don't get the hate. I'm spinning up a portfolio site and I
| want to keep it as minimalist as possible. This kind of styling
| is exactly what I need, since I'm not trying to apply as a
| frontend web dev. Make it look reasonable on mobile and
| desktop.
| erlkonig wrote:
| I can't really enjoy an article on CSS where the third thing he
| does is to override the USER'S PREFERRED FONT SIZE.
|
| Arrogant.
|
| But not as bad as those jerks that use smaller and smaller,
| progressively lower contrast text as the actual content gets more
| important. Huge readable repetitive headings, microfiche gray-on-
| gray for the stuff that mattered.
| reassess_blind wrote:
| At least they're making the font size larger than default, not
| smaller. The users preference will still scale that up or down.
|
| Hell, Hacker News sets the comment font size smaller than
| default.
| eric-burel wrote:
| I would tolerate some js to implement dark mode with a class
| rather than a media query. It allows more control with a toggle
| if user wants some site dark some light. Edit: it's covered in
| the article actually.
| tom_alexander wrote:
| FWIW you can add a light/dark toggle button without any
| javascript. You only need javascript if you want to persist
| that preference in localStorage.
|
| Here is an article that was posted to HN which implements the
| three-state (auto/light/dark) toggle in HTML and CSS only:
| https://lyra.horse/blog/2025/08/you-dont-need-js/
| sevenseacat wrote:
| yo that article is amazing
| freestingo wrote:
| I went down the same rabbit hole when designing my own website,
| and I came out of it feeling like css as a whole is redundant. I
| also do not agree on not using default font families (not sure
| what's wrong with them except for aesthetic reasons, something
| that I have never looked for in any of the websites I ever
| visited) or restricting content width (sometimes you may actually
| want longer lines to adapt to your window). One other thing that
| I would suggest is to make sure the font size is the same in both
| portrait and landscape mode on smartphones (landscape text is
| bigger than portrait text iirc).
| elevation wrote:
| There are human limit to the lengths of the lines of text that
| you can reasonably ingest before it becomes difficult to seek
| to the next line. If you measure the number of characters in a
| line of text in a newspaper, magazine, or novel, you'll find
| that there is an upper limit of around 100 characters and a
| lower limit of perhaps 30. Exceeding either of these degrades
| reading comprehension and looks amateurish. Using styles to
| enforce good readability is a great use of CSS.
|
| For tips see: https://practicaltypography.com/
| javier123454321 wrote:
| It's funny, the tech purists sometimes really forget that
| typography has been studied to death for 100s of years before
| the web came to be. The backlash over wikipedia implementing
| a design considered to be higher readability and conducive to
| better comprehension was a funny case.
| bbx wrote:
| Reminiscent of Web Design in 4 minutes: https://jgthms.com/web-
| design-in-4-minutes/
| SquareWheel wrote:
| > While this is really handy, it is a best practice to allow
| users to manually toggle the color-scheme as well. Some people
| prefer a dark system theme, but light website themes, and vice-
| versa.
|
| It can make sense for a theme selector that works on the server,
| since you can serve specific HTML when building the page.
| However, if using a JavaScript-based solution that fetches the
| theme preference from localStorage, I find this almost always
| results in a "flashbang" in dark mode, as the retrieval is slower
| than the first browser paint.
|
| I've been implementing (and recommending) pure CSS-based theming
| to avoid this problem. Users seem much happier with them, and I
| haven't heard anybody ask for a theme switcher. We just respect
| their existing preference. However, I can see this being a
| problem if you offer multiple color schemes (beyond just light
| and dark).
|
| I'd be curious to know if anybody has found a way to avoid this
| issue with JS switchers -- ideally without needing to delay the
| initial paint.
|
| I do think an interesting approach would be a browser extension
| that lets you override the prefers-color-scheme property on a
| per-domain basis, similar to the toggle in dev tools.
| hucklebuckle wrote:
| Where can I learn more about CSS-based theming?
| bobbylarrybobby wrote:
| You might be surprised how little there is to know. There are
| basically three strategies: 1. set your light theme color
| variables in :root and your dark theme colors in `@media
| (prefers-color-scheme: dark) { :root { ... } }` 2. use the
| newish `--var: light-dark(light-value, dark-value)` syntax
| with `:root { color-scheme: light dark; }` 3. use a class on
| the body to determine whether to apply light or dark
| variables (can be used in combination with the above to
| default to user's current theme while letting javascript
| toggle the theme by toggling the class)
| tom_alexander wrote:
| If you're just concerned about light vs dark, then this
| article (which was posted to HN) does an auto/light/dark
| toggle button without javascript, and it shows using CSS
| variables for your colors:
| https://lyra.horse/blog/2025/08/you-dont-need-js/
| quest88 wrote:
| I've never tried it but the first thing that comes to mind is
| to use a service worker. The service worker would append a
| parameter to the initial request to indicate what theme is set
| in local storage. Then the initial response can use that as the
| default theme.
| marcosdumay wrote:
| You can always default to the user mode, and make a switcher
| that fetches another CSS file.
|
| That way you will have a flash, but if the user set dark mode
| on their browser/DE, they'll flash in dark, not light.
|
| Or, alternatively, you can always make it flash in dark. I
| never heard about anybody being annoyed by a dark flash.
| woodrowbarlow wrote:
| a dark flash would definitely be annoying; it would feel like
| i'm using a first-gen e-reader.
| MarcelOlsz wrote:
| That's why I made my site all pixelated and bitmappy. The
| lack of performance is part of the _aesthetic_. Might even
| throw a dummy loading bar on it if I 'm feeling extra
| cheeky.
| marcosdumay wrote:
| Ok, that comparison is ridiculous. A two monitor frames
| flash after the first load doesn't look at all like a
| first-gen e-reader.
| wry_discontent wrote:
| imo it's best practice to not use light/dark themes. The site
| looks the way I want it to look. This isn't your site, it's
| mine.
| sionisrecur wrote:
| Well if it's my site I want to give users choice between 2
| styles.
|
| I remember Firefox used to have an option in the menu for
| selecting alternative stylesheets, multiple ones not just
| light and dark, I think it was a standard from CSS, but only
| Firefox had a way to select them through the UI, for other
| browsers you had to use Javascript to make a selector.
| reaperducer wrote:
| _imo it 's best practice to not use light/dark themes. The
| site looks the way I want it to look. This isn't your site,
| it's mine._
|
| Thank you for illustrating the fact that the phrase "best
| practice" means nothing, and is little more than a synonym
| for "I heard this somewhere."
| ryandrake wrote:
| Sad that the state of affairs is that "offering a light and
| dark mode" is seen as a best practice for user choice in web
| styling. Oh, thank you, web developer, for _letting me_ choose
| between _two_ color schemes! Meanwhile, I can choose my desktop
| window colors, text colors, fonts, text size, down to the
| individual element, and have been able to do this since at
| least the 90s. If I want yellow comic sans on purple window
| backgrounds, I can have it. But not on a web page! How far we
| have regressed when it comes to user preferences and honoring
| them.
| im3w1l wrote:
| It's possible you just didn't look hard enough for how.
| ryandrake wrote:
| Sure, it's buried in settings on all browsers. My point is
| it's not a path that most web developers care about, and a
| lot of web sites are not robust to turning off styling
| and/or substituting your own.
| im3w1l wrote:
| Use an extension (Stylus?) to inject css.
| hamburglar wrote:
| You seem to take offense at the idea that you have to read
| something that someone else designed. How do you cope with
| books, magazines, presentations, signs, menus in restaurants,
| etc?
|
| Calling this a "sad state of affairs" is pretty dramatic. You
| have to gaze upon _things_ that aren't in your preferred
| colors, oh my!
| array_key_first wrote:
| It's a sad state of affairs because it's a regression.
|
| This was trivial for websites 15 years ago, but due to
| increasing complexity, it's no longer feasible. We've put
| more and more styling type things in JS, which really
| undermines web as a platform.
|
| This is _why_ CSS exists. This isn 't some weirdo use case,
| this is THE use case. We're all losing the plot.
| imiric wrote:
| The aspects you mentioned are part of a _theme_. The light
| and dark settings control the visual _scheme_ , which is
| entirely different.
|
| It is ludicrous to expect every web page to give the user
| control over individual theme elements. If you want such
| level of control, you can override them yourself with a
| custom style sheet.
| nativeit wrote:
| Weird, I'm offended by the opposite end of this. Why am I
| "theming" websites? What, is this MySpace? I want the
| professional paid/trained developer to design the site. If
| it's light, I expect there to be good reasons for it. If not,
| ditto.
|
| I feel the same way about salads in restaurants--I don't want
| to have to slice produce, add dressing, and toss my own salad
| at the table without a bowl or proper utensils. I want the
| professionals who I am paying to prepare my meal to handle
| that. If I have problems with any of the ingredients, or some
| desire for unreasonable quantities of dressing, then I can
| make requests. Serving me a plate of neatly partitioned
| ingredients strikes me as an insane thing to do...I suppose
| unless it comes with fondue or I have signed up for some
| hibachi nonsense to make my dinner more "interactive".
|
| I have fully lost the thread, apologies, carry on.
| kelvinjps10 wrote:
| You change the css stylesheet of the website, there is
| extensions for that.
| EMM_386 wrote:
| This is way too old school for me (and I've been developing
| with JS/CSS since 1997 and HTML since ... before that. On my
| site I just use prefers-color-scheme and have a toggle to
| switch light/dark it if the user wants, persisting the choice
| locally. I detect Dark Reader and honor the user's choice
| with that.
|
| What would you do if you had the option to choose any font of
| your choosing? What color for the headers? The background of
| the buttons? Should you be able to define the border radius?
| The CSS transitions? All of CSS?
|
| You can do that. There are extension for that.
|
| I don't think this is a concern for the vast majority of
| users.
| linhns wrote:
| Well it's his/her own website that you're viewing. Be
| thankful that they care about your and others' preferred
| scheme because some don't.
| jrm4 wrote:
| OP's way of thinking is correct and better than all of the
| self-centered and callous replies I've seen here - y'all are
| the REASON we have to do things like, e.g. onerous ADA
| compliance measures and similar fights for user rights.
|
| The ideal web would give the option of better separating form
| and function when possible. I'm well aware that this is an
| old set of values from another time, but today they're more
| important than ever, not just aesthetically, but with
| reference to ability and power and dare I say, freedom.
| mb2100 wrote:
| > if using a JavaScript-based solution that fetches the theme
| preference from localStorage, I find this almost always results
| in a "flashbang" in dark mode, as the retrieval is slower than
| the first browser paint.
|
| Not if you blockingly inline the three lines of JavaScript with
| a good old script tag right in the HTML.
| myfonj wrote:
| > _I do think an interesting approach would be a browser
| extension that lets you override the prefers-color-scheme
| property on a per-domain basis, similar to the toggle in dev
| tools._
|
| Presumably, most users wanting flashbang-less browsing
| experience use Dark Reader extension or similarly radical
| solutions.
|
| The sad truth is that the user preferences and per-site
| persistence for stuff like this should always have been
| browser's responsibility to begin with: just the same way like
| the font-size/page zoom already is, and likewise some
| (blatantly limited) security settings. (Bitterly) amusing fact
| is that there was (and still is) concept of "alternate
| stylesheets" from the beginning of CSS (still part of the spec
| [0], no support outside Gecko), that _also_ fade into
| obsolescence for it 's lack of persistence. So to this days,
| Firefox, for example, has View - Page Style menu, where user
| can choose alternate stylesheet but the choice is not preserved
| across navigations, so is pretty useless on its own.
|
| Similarly userstyles: specifications dictate there is like CSS
| origin level and how they should behave and that all "user
| agents" are supposed to give user a way to enter the cascade
| this way, but does not give any official way how to scope
| individual recipes to concrete origins. That's what the
| unofficial `@-moz-document` extension was that, and briefly had
| a chance to be formalised [1]. But I digress.
|
| (Likewise all the "European" cookies banners: tragic example of
| regulation applied on the wrong level. Instead of putting users
| in charge with help of their "user agents": implicitly blocking
| pretty much everything and using permissions system that
| actually would have a chance to be more than _" pinky promise
| we will not track you if you don't click this toggle inside our
| banner"_. But I digress even more, sorry.)
|
| > _I 'd be curious to know if anybody has found a way to avoid
| this issue with JS switchers -- ideally without needing to
| delay the initial paint._
|
| At this point, when browsers do not support per-site user
| preference for that natively, pragmatic (most robust) way would
| be to respond with properly set HTML payload straight away.
| There is even specified HTTP header for this, so once adopted
| in browsers, we could even ditch HTTP cookies [2] for the
| persistence, but it seems quite demanding on the server (IIUC
| negotiating these "Client Hints" takes extra initial request
| round-trip).
|
| Pragmatically, I guess having early running JS in the HEAD that
| ensures the proper color-scheme is set on the root not and only
| proper stylesheets load should pretty much prevent most
| flashbangs, provided the relevant bit would arrive early enough
| from the server. I think there does not exist any good no-JS-
| no-Cookie (or any JS-less persistence) solution that supports
| navigations, sadly.
|
| [0] https://html.spec.whatwg.org/multipage/links.html#rel-
| altern...
|
| [1] https://www.w3.org/TR/2012/WD-
| css3-conditional-20121213/#cha...
|
| [2] https://developer.mozilla.org/en-
| US/docs/Web/HTTP/Reference/...
| WorldMaker wrote:
| Firefox does have a global setting to override the System
| setting if you want system dark but webpages light, for
| instance.
|
| Most browsers also support per-page overrides, but the only
| consistent place to find it is Dev Tools, which is a shame.
|
| I think browsers decided to invest in "Reader Mode" as a UX
| over more direct control of user styles and page styles, and
| I'm not always sure that is the correct choice, but I can
| understand how it seems the simpler "one-button" choice.
| hypertexthero wrote:
| Here's what I use, with localStorage instead of cookies to
| remember user setting: https://hypertexthero.com/dark-mode-
| website-theme-switcher-l...
| SquareWheel wrote:
| Sorry to say, but your site does flashbang when navigating
| pages in dark mode. It would also be good if it inherited its
| initial state from the user preference, rather than requiring
| a manual adjustment.
| tremon wrote:
| > Your setting preference is saved with web browsers'
| localStorage instead of cookies to help avoid needing "Accept
| Cookies" notes.
|
| I'm not aware of the specifics of regulations in other parts
| of the world, but this distinction is irrelevant for the EU
| ePrivacy directive: a) it was never about cookies only, and
| b) purely functional cookies that record user preferences do
| not need explicit consent.
|
| From [0]:
|
| > 34,35 Storage of information in the sense of Article 5(3)
| ePD refers to placing information on a physical electronic
| storage medium that is part of a user or subscriber's
| terminal equipment [..] this includes making use of
| established protocols such as browser cookie storage as well
| as customized software, regardless of who created or
| installed the protocols or software on the terminal
| equipment.
|
| > 43 This might also be the case for web browsers that
| process information stored or generated information [sic]
| inside the device (such as cookies, local storage, WebSQL, or
| even information provided by the users themselves). The use
| of such information by an application would not be subject to
| Article 5(3) ePD as long as the information does not leave
| the device
|
| https://www.edpb.europa.eu/our-work-
| tools/documents/public-c...
| ge96 wrote:
| You don't want a tailwind paragraph class in your html? /s
| defanor wrote:
| I have gradually reduced CSS to zero myself, since pretty much
| every tweak seems to mess up accessibility more than improve
| things, and generally it is the client that should control the
| style, and the user who should configure it for themselves,
| knowing their own requirements better. As for suggestions from
| the article:
|
| > Granted, if you have images they can cause some overflow
| issues.
|
| The "fix" breaks zooming in.
|
| > In general, the font-size is a little small as well
|
| It is quite annoying when websites mess with your preferred font,
| its size, style, and so on, often turning texts illegible. In
| this case it is made awkwardly large, but often it is made
| illegibly small, apparently also with the intention to fix the
| defaults.
|
| > Many people love dark mode, so let's enable it based on a
| user's system preferences.
|
| "color-scheme" is like "viewport": an invocation to tell the
| browser that the website is not too broken, and the web browser
| should act more sensibly. Those are practical, but still awkward,
| not quite how things should be: I wish web browsers defaulted to
| sensible behaviors. So I rather view it as a choice between
| adapting to how things are and pushing for how they should be.
|
| > We generally want to try and fall somewhere in the 45-90
| characters per line range (for body text, not headlines).
|
| I used to set max-width in ch before removing CSS completely as
| well, but usually desktop web browser windows are resizable, with
| the space being there to be used, not to fill with background
| color. I see it in epub files sometimes as well: huge margins are
| enforced, being rather annoying when you do not want those, while
| if you do, you can simply adjust the window size (or set such
| default styles, as another option).
| balder1991 wrote:
| So you went straight https://motherfuckingwebsite.com/ ?
| bryanhogan wrote:
| Reminds me of my guide about CSS for styling all relevant
| components when using markdown:
| https://webdev.bryanhogan.com/miscellaneous/styling-markdown...
| sema4hacker wrote:
| Decades ago, laying out text required using tools like troff,
| where the user had to memorize and embed codes to do the
| formatting. Then WYSIWYG tools like PageMaker finally became
| available to the masses, and you simply dragged things around on
| the screen to get what you wanted. HTML and CSS is a step
| backwards. I don't think anyone can remember all the CSS codes
| and side effects, and new ones keep appearing all the time.
| Myself, I can't "program" a non-trivial layout from scratch, I
| always have to find an example I can copy.
| g8oz wrote:
| Is this the new reset.css?
___________________________________________________________________
(page generated 2025-10-07 23:01 UTC)