[HN Gopher] 58 bytes of CSS to look great nearly everywhere
___________________________________________________________________
58 bytes of CSS to look great nearly everywhere
Author : thunderbong
Score : 456 points
Date : 2022-09-25 15:04 UTC (7 hours ago)
(HTM) web link (gist.github.com)
(TXT) w3m dump (gist.github.com)
| marcosdumay wrote:
| And it sets a text color, but no background color, ensuring it
| will fail on most non-standard color schemes.
|
| Not really "everywhere".
| swyx wrote:
| I wrote my version here last year:
| https://www.swyx.io/css-100-bytes html {
| max-width: 70ch; padding: 3em 1em; margin:
| auto; line-height: 1.75; font-size: 1.25em;
| }
|
| if you have 100 more to spare:
| h1,h2,h3,h4,h5,h6 { margin: 3em 0 1em; }
| p,ul,ol { margin-bottom: 2em; color: #1d1d1d;
| font-family: sans-serif; }
|
| explanation in the blogpost
| curlftpfs wrote:
| Element-based selectors, setting the root font-size, mixed
| units, text color with no background color...I guess the
| assumption is that you won't add ANY other styling? Big
| headaches down the road if you do.
| swyx wrote:
| well yeah thats the gimmick with these things, ultra
| minimalist drop in css. its not like its hard to modify later
| on
| scorpios77 wrote:
| evandale wrote:
| Does this actually look great to people? I can't stand forced
| line lengths and these ones feel way too short for the text size.
| This seems that it looks great for mobile, not desktops.
| pgt wrote:
| font-family: Georgia;
| uhtred wrote:
| We bloat websites with ridiculously huge js frameworks but sure,
| let's focus on a few bytes of css
| makeworld wrote:
| Also restated here: https://www.swyx.io/css-100-bytes
| worldmerge wrote:
| Does anyone know what theme that blog is using? It looks really
| nice.
| swyx wrote:
| uh wow, this is the first time anyone's complimented anything
| I designed lol!
|
| it's a handrolled theme, with a lot of inspo from @leerob of
| vercel. i keep a clonable version here https://github.com/sw-
| yx/swyxkit/
| magnio wrote:
| A comparison using danluu's website:
|
| Default: https://postimg.cc/k2Zwffms
|
| With the 100 bytes version: https://postimg.cc/645d9vKT
| xani_ wrote:
| That line spacing is obnoxiously big tho
| skyfaller wrote:
| Yeah, I agree the line spacing is far too much. Butterick's
| Practical Typography recommends 1.2 to 1.45:
| https://practicaltypography.com/line-spacing.html
|
| Really the only reason to use a line spacing of 2 is if you
| are printing it and then editing the text with a pen. So...
| maybe in a print stylesheet in a very specific situation? But
| never on the web, IMHO.
| rossjudson wrote:
| I think the line spacing is "comfy". Approved. For me.
| baud147258 wrote:
| I honestly prefer the default version. Less scrolling to do.
| phist_mcgee wrote:
| Try reading his site on a 21:9 and your eyes start bleeding.
| _def wrote:
| But more horizontal eye movement, which at least I find
| unpleasant
| mod wrote:
| Thanks for taking a minute to do this, it gives a nice side-by-
| side for a real-world example. What a great improvement.
| c0mptonFP wrote:
| Line spacing is atrocious
| [deleted]
| TheWoodsy wrote:
| It seems like I'm permanently in some sort of dystopian nightmare
| 'unpopular opinion' group where wasting two thirds of my monitors
| useful space is the right way about doing things.
|
| I have monitors either side of my primary in portrait mode
| specifically for looking at a bunch of code/text and it still
| wastes at least half of the useful display area.
|
| https://i.imgur.com/Qk7fM35.png
|
| If I wanted this, I'd press the reader button in Firefox or
| squish my browser window. Why? _Shakes fist at sky_
| ryan-duve wrote:
| We're in the same group if that makes you feel any better. BTW,
| since you mentioned reader view in Firefox, here's the
| userContent.css that I've been using for the past few years:
| @-moz-document url-prefix("about:reader") {
| .container{ max-width:100% !important;
| } .toolbar-container{ display:none
| !important; } }
|
| Make sure to set your preferred size/color first.
| demindiro wrote:
| I limit the width on my website because I find moving my eyes
| constantly from left to right annoying. For me it's harder to
| find the beginning of the next line if lines are very long.
|
| Besides, the other half of my monitor is usually taken up by
| another window or two.
| jccalhoun wrote:
| yep. I hate it. I've seen people say this is a result of
| studies but I've never been able to find the studies that claim
| this is better. It seems to have been stated in elements of
| typographic style and taken as truth
| http://webtypography.net/2.1.2
| iLoveOncall wrote:
| Well you must have not searched very hard if you didn't find
| studies, because it took me a grand total of 3 minutes:
| https://www.semanticscholar.org/paper/Optimal-Line-Length-
| in...
|
| There are many citations that lead to other studies on the
| same topic.
| jccalhoun wrote:
| Thanks.
| IshKebab wrote:
| Because reading paragraphs of text with extremely long lines is
| really annoying. If the lines get too long it makes it hard to
| subconsciously find the next line when you scan back.
|
| What's your solution? The only other option I can think of is
| multi-column newspaper style, but that's pretty fundamentally
| incompatible with the scrolling model of the web.
|
| That's probably why you only see multi-column formats in page-
| based media like physical newspapers and PDF papers.
| wruza wrote:
| _that 's pretty fundamentally incompatible with the scrolling
| model of the web_
|
| It isn't though. If browsers supported overflowing text into
| a "next" container (defined via hierarchy, selectors,
| whatever), designers could just design repeating pages of
| layouts like they usually do with full-height marketing
| stripes.
| Arnavion wrote:
| >What's your solution?
|
| I don't need solutions to problems I don't have.
|
| If people find it hard to read long lines on my website they
| can make their browser window thinner. I don't feel compelled
| to impose my reading abilities (or lack thereof) on them.
| Arnavion wrote:
| For real. I have a dozen style overrides for websites that are
| just variations of `max-width: none !important` to make them
| actually usable.
| mikl wrote:
| Why? Because so many users just run the browser in full screen
| mode because they don't how or simply can't be bothered to
| manage windows, not because they actually want their screen
| filled edge to edge with text.
|
| So because long lines are hard to read, line length is clamped
| to at least provide a decent experience to all those users.
| zahllos wrote:
| I think this is due to the desire to fall in the approx 40-75
| characters per line that are considered ideal (numbers vary
| depending on the source of the study but broadly fit this
| definition) for users to read. It is also why some prefer
| double-columns in academic papers, because each 'column' has
| closer to ideal lines, rather than have wide margins on the
| page.
|
| Of course, this looks like wasted space when you have a
| landscape-oriented monitor... I personally very rarely maximize
| my browser so that I read in more of a portrait-style mode,
| regardless of the orientation of my display.
| Accacin wrote:
| But, you're the one wasting it, right? You have a huge monitor
| with one window open. I use a WM and very rarely have one
| window on a whole screen, because that would be a waste of
| screen.
|
| If that text was full width along your screen you'd be wasting
| vertical screen space instead. Will you ask them to write more
| to fill your screen up?
| Arnavion wrote:
| If resizing the browser is an acceptable solution then not
| setting the max-width already works. Setting the max-width
| only makes it worse for people who want the space to be
| filled regardless of their browser size.
| TheWoodsy wrote:
| Well, OK sure. I'm not the most effective communicator but in
| the end I'm still genuinely 'not getting it' though.
|
| In my image you can see that either portrait or landscape
| orientation, there is considerable 'dead' area (edit: either
| side), by default, even if the text was many paragraphs long.
|
| The usual solution is to smash "ctrl numpad +" four times til
| things fit perfectly at (usually) 150%. It's actually uncanny
| how I'll do this without even thinking while browsing.
| wruza wrote:
| There's no easy way to organize lots of windows, and there is
| no way your approach would work nice with all web apps, sites
| and articles in different tabs of the same window.
|
| What would be nice is a special element <viewport sizeable
| style="width:n"> so a user could either enjoy a default width
| or drag one side of it to resize its margin at both sides,
| without resizing a window. Or, instead of an element it could
| be purely a browser viewport-resize feature, like they do for
| textareas.
|
| Meta: it's really frustrating that every time an argument
| about web ui starts, nobody thinks of how to actually make it
| better and just holds on some particular use case or
| preference.
| croes wrote:
| Even worse when the text has things like code examples that
| aren't completely readable without horizontal scrolling.
| zora_goron wrote:
| A little more heavy and less generalizable than this, but I've
| used this Drop-in Minimal CSS bookmarklet [0] several times to
| quickly try out drop-in CSS frameworks on my projects!
|
| [0] https://dohliam.github.io/dropin-minimal-css/
| OJFord wrote:
| Should you take this sort of advice from someone using block
| quotes for explanatory sections?
|
| That oddity aside, seems the explanation didn't start 101 enough
| for me - I've not come across `main` before! Though it's not at
| all new: https://developer.mozilla.org/en-
| US/docs/Web/HTML/Element/ma...
| Blackthorn wrote:
| People who use that accursed max-width style are the bane of my
| existence. Let it fill the entire browser! I have no idea how
| this became a trend.
| RobbieGM wrote:
| Isn't it more readable not to have really long lines?
| curlftpfs wrote:
| We can have both! Wide containers with narrow line lengths.
|
| We call them "columns" and they're part of CSS now.
| thunky wrote:
| People are using 48+ inch OLED tvs for monitors now. Someone
| reading full width text will look like they're watching a
| tennis match.
| Blackthorn wrote:
| People can set the exact width they're comfortable with by
| making the browser window the size they want. But the moment
| that max-width is added, the choice is removed.
| xigoi wrote:
| Then they'll have to resize it every time they visit a
| website where a wide window is actually beneficial.
| thunky wrote:
| That's a good point and I feel the same way about links
| that open in news tabs.
| mikewarot wrote:
| I've got a screen that is much wider than it is tall, this throws
| away so much of it. It's as bad as Facebook, where the stuff you
| want to see is a band about 1/4 the area of the screen.
| clairity wrote:
| browsers have been working on multiple column text for a while
| now[0], so by employing a container/media query, you could have
| multiple columns for wide screens and content containers. i
| experimented with it a couple years ago and found quirks (which
| i can't remember offhand) that made it not quite ready for
| primetime then.
|
| [0]: https://developer.mozilla.org/en-
| US/docs/Web/CSS/CSS_Columns...
| phil294 wrote:
| Hope you don't mind the self-promo: Here's a GH project of mine
| which attempts to provide styles for popular websites to remove
| large paddings and max-widths:
| https://github.com/phil294/density-userstyle
| ricardobeat wrote:
| In theory sites could optimize for wide screens by adding
| columns, but 1) its a very small audience 2) most content is
| not suitable for that (how would you scroll a feed that spans 3
| columns?)
| shadowofneptune wrote:
| https://www.nasm.us/xdoc/2.15.05/html/nasmdoc2.html
|
| The NASM website is an example of this. Personally, I don't
| like it and would prefer a single column.
| sen_armstrong wrote:
| That has a small number of long columns down the entire
| page, which doesn't give any of the benefits of having
| columns. Actually, it's only _worse_ in terms of
| readability, as a big factor is how well your brain can
| spatialize the location of what you 're reading for
| backwards jumps or subconscious memory palace stuff. Here
| that's complicated by the mental overhead of "I'm halfway
| down the page, but the page is really twice as long as it
| is, so that's actually 1/4 of the way through."
|
| Proper column layout involves limiting columns to screen
| height, probably by paginating. Then the reader can
| perceive the text as a tree of Page > Column > Paragraph >
| Row. Tangentially, I think there are studies positing that
| this, helped by the notion of physical pages in space, is
| what's behind the readability advantage of books.
|
| Alternative to pagination is scroll-direction: horizontal.
| Now the experience is even closer to reading a book. And to
| Windows 8! IMO there's a shortage of novelty sites with
| true (non-slideshow or carousel) horizontal scrolling.
| hoherd wrote:
| This whole design pattern of wasting screen real estate in
| desktop browsers drives me crazy. If I want narrow text I'll
| make my browser window narrow.
|
| On mobile, so many times it ends up creating a bad UX, but I
| will say that it does make more sense there where you can't
| change your browser width.
| pronlover723 wrote:
| I'd add :root { color-scheme: light
| dark; }
|
| This makes the browser choose dark colors for those that prefer
| them, including form widgets etc...
| breck wrote:
| Love things like this. This is why I can't stop reading HN.
|
| I disagree about the font-size. I say go very small (pack more
| info on a screen). Very easy for people to make it bigger. People
| have known this for hundreds of years (old newspapers pack in the
| text, older readers can wear spectacles or use magnifying glass).
| shadowofneptune wrote:
| I've moved towards a larger size with the knowledge that I'll
| have trouble reading small text in 20 years. With the state of
| modern medicine, most people reading this will be old for a
| long time.
| pGuitar wrote:
| I tend to agree but modern designers are doing the opposite and
| post the least amount of content in a specified amount of
| space. I bet that they will come to their senses eventually.
| coldtea wrote:
| > _I disagree about the font-size. I say go very small (pack
| more info on a screen)_
|
| Why, is it a contest who can cram the more? People can always
| scroll, and they know how to do that better than they know how
| to increase the text (not to mention most read on mobile
| phones, were even fewer know how to change the text size)
|
| > _old newspapers pack in the text, older readers can wear
| spectacles or use magnifying glass_
|
| Seems like the worst argument one could chose in favor of this
| idea...
| simonw wrote:
| "Very easy for people to make it bigger"
|
| I wonder if that's true for the average (non-nerd) user on a
| smartphone though. They can likely pinch-and-zoom, but that's a
| terribly way of reading text since you constantly have to pan
| back and forth. Have they definitely found the text size
| adjustment buttons?
| stevebmark wrote:
| Not explicitly mentioned here, but worth bringing up: Text width
| should always be constrained to a maximum width to optimize for
| human reading. Every book ever printed has text with set within
| the same range for a reason. Full width text guarantees most
| users will have a poor reading experience.
| dv_dt wrote:
| Large margins are also distracting and a waste of human time. I
| wish browsers or sites would automatically flow the text into n
| columns depending on the view window size. It's not trivial but
| if one is optimizing for reading, then extra window scrolling
| to get to newer sections of text is not particularly optimal
| either.
| sorenjan wrote:
| Newspapers use columns for the same reason, to not get too wide
| lines. Unfortunately I don't think I've ever seen a site use
| columns, even though CSS supports it.
|
| https://developer.mozilla.org/en-US/docs/Web/CSS/columns
| galaxyLogic wrote:
| I think that shows that different mediums need different
| solutions and also different content.
|
| Newspapers don't have scrollbars. So they use columns.
|
| This may be why phone-apps are so popular, their content is
| designed to be viewed only through the app.
|
| CSS columns is cool, I didn't know about it. But not sure
| where I would use it either.
| SquareWheel wrote:
| Personally I find column-style layout to be more difficult on
| the web. Though probably just due to lack of familiarity.
|
| As one example, the "Golf with your Friends" subreddit always
| throws me for a loop due to its use of columns. I have no
| idea how to read it!
|
| https://old.reddit.com/r/GWYF/
|
| Note this example will only work on a widescreen desktop
| browser.
| swid wrote:
| I almost agree, but there's a difference between number of
| characters and width, and also graphics and tables are a
| different beast.
|
| Personally, I think websites should fill up the available
| space, increasing font size if it makes sense, perhaps using
| resizing images. So, no - text should not be constrained to a
| maximum width. If width were a problem, billboards wouldn't be
| a thing.
| cerved wrote:
| the maximum width for readability is in characters per line
| so it should be expressed in that
| xcambar wrote:
| Have you ever seen a long text on a billboard?
|
| I guess not.
| swid wrote:
| I'm pretty sure you misunderstood what I wrote.
|
| > there's a difference between number of characters and
| width
|
| Billboards use large letters to fill the space, but
| normally they would be readable on a business card.
| xcambar wrote:
| Fair enough. But your point requires discussing
| nonetheless.
|
| You seem to suggest that fontsize should adapt to width
| to fill the space (seemingly to a billboard, as per your
| example).
|
| If the billboard technique was used on the web, I guess
| we might not have more than a handful of lines on screen
| (on a 16:10 or so). That would disable skimming on long
| texts and even more, barely display a single paragraph
| (that's a gut guessing).
|
| Plus, and more importantly, the distance to the screen is
| such that a font too big is not more readable. There's a
| tradeoff to he found for the fontsize that not only has
| to take into account the size of the screen but also the
| distance of the reader from the medium.
|
| Or so I assume.
| michaelsalim wrote:
| That's a great point. I gave it some thought and I think it's
| a matter of the relative distance from the start to the end
| from your perspective.
|
| Billboards are meant to be read from far away. So even though
| the physical width is large, we perceive it to be much
| smaller. Maybe similar to a big banner on a Desktop monitor.
|
| Imagine reading the billboard at a much closer distance, say
| 2 meter. You'll have to move your neck from left to right. It
| doesn't matter how big or small the font size is.
|
| As a subjective test, I lowered the font size of a random
| article to see if I would have trouble reading it. Other than
| having to focus more to make out the text, I don't have
| problems reading the entire paragraph. On the other hand,
| removing the max width made it more uncomfortable to read.
|
| So the distance from where the text will be viewed from is an
| important factor to take into account. Phones, Desktops &
| Banners all are viewed from different distances.
| isaacremuant wrote:
| I don't like that. I can adjust the full text width by
| adjusting my window but if have a big wide screen and you limit
| it, then I'm wasting a lot of what I can see.
|
| Give me customization, not "alleged optimization" that turns
| out not to be so
| stevebmark wrote:
| Don't confuse constraining an entire website's width for
| constraining the text reading width. You can gracefully have
| maximum reading width text columns with other content to the
| left and right of it to maximize real estate.
|
| Also, don't ask users to resize their browsers to accomodate
| for a site's poor UX. That's called "blaming the user."
| cerved wrote:
| paragraphs are less readable past 90-100 characters width
| r3trohack3r wrote:
| I really like the minimal CSS on Nat's website, I frequently
| reference it when styling my own content: https://nat.org
| mwcampbell wrote:
| Do you still have to explicitly add CSS to do something
| appropriate for the user's dark mode setting? I'd rather not
| specify any colors at all and just let the browser use system
| defaults, but last time I checked, that used black-on-white even
| in dark mode.
| schemescape wrote:
| Yes. Sadly, iOS Safari defaults to dark blue links on a dark
| background for dark mode.
| wildrhythms wrote:
| That would introduce yet another set of defaults that
| developers would then need to inevitably override.
| mwcampbell wrote:
| I'd accept that. The user-agent knows better than I do what
| the user needs. Especially if the user is low-vision, color-
| sensitive, or whatever.
| curlftpfs wrote:
| You do, via `color-scheme` or media query
| jraines wrote:
| Shot in the semi-dark: there was a blog post posted here --- I
| haven't been able to find it with HN search --- some years ago
| that started from scartch/browser-defaults and proceeded in like
| 5 steps to some nice minimal defaults. Not exactly a plain reset;
| there were some opinionated choices. Step one was something like
| the parent article. Anyone have an idea what this was, or have
| some similar recommendations?
| joeriddles wrote:
| Perhaps this or this? Excuse the language.
|
| [1] http://motherfuckingwebsite.com/
|
| [2] http://bettermotherfuckingwebsite.com/
| WallyFunk wrote:
| And this: https://watercss.kognise.dev/
| Herodotus38 wrote:
| I had to through my saved favorites, but I knew what you were
| talking about. From 5(!) years ago:
|
| https://jgthms.com/web-design-in-4-minutes/
| [deleted]
| sdoering wrote:
| Instantly thought of the same ressource. Still something I
| recommend regularly to people.
| dmitriid wrote:
| Great, with one nitpick: "Black text on a white background
| can be harsh on the eyes. Opting for a softer shade of black
| for body text"
|
| Why are people so afraid of black text on white background?!
| In the end, after all the colors and custom fonts the website
| has gray text with poor readability which instantly fails
| WCAG AAA. Had he kept #555 (which is still not ideal), the
| author would have had a WCAG AAA-compliant design with
| minimal effort.
| yakubin wrote:
| Yup. My eyes started getting tired exactly at the point
| when the text became gray.
| coffeeblack wrote:
| Well done step by step presentation.
|
| But I still prefer how the page looked initially, without all
| the styles.
| jraines wrote:
| Amazing! Thanks :)
| Herodotus38 wrote:
| Glad to help
| metayrnc wrote:
| Would have been nice to have some examples showing it in action.
| hit8run wrote:
| Line height 1.75 lol no thanks.
| divbzero wrote:
| Could the default style in browsers be adjusted so nearly any
| webpage can look great with plain HTML?
| zzo38computer wrote:
| In my opinion, it does already, without needing much CSS except
| to limit pictures to the width of the viewable area (you can
| click on them and select "view picture" to zoom them, if
| desired). I rarely need to add my own CSS code to web pages
| that do not already have CSS; it is those that do, that I need
| to fix.
|
| I made up a attribute feature="usercss" which is supposed to
| mean to use the user-specified CSS (or suitable defaults for
| semantic HTML) instead of this one, if the client supports that
| feature; it can also use the user-specified CSS (or suitable
| defaults) if the web page does not specify any CSS at all. As
| far as I know no browsers implement this, but some of the
| people making up some newer browsers (the less common ones)
| might consider to add such a feature when user-specified CSS is
| implemented.
| growt wrote:
| "max-width: 38rem it appears that the default font size for most
| browsers is 16px, so 38rem is 608px. supporting 600px displays at
| a minimum seems reasonable."
|
| I'm not an expert in CSS, but I don't think this makes sense. Why
| base the width on the default font size when you know you're
| aiming for 600px? Just write 600px. Also that's a max width, so
| what makes this support 600px screens at a minimum?
| noizz wrote:
| Quick example of how it looks: https://jsfiddle.net/n8Lqypb7/
| schemescape wrote:
| Is there some way to view the result full screen, namely for
| viewing on mobile?
| new_user_final wrote:
| result: https://jsfiddle.net/n8Lqypb7/show
|
| Original page: http://web.archive.org/web/20210318102514/http
| s://jrl.ninja/...
| wirrbel wrote:
| I will never understand inflated line height. It doesn't make
| Text more legible.
| javchz wrote:
| I just love this. I still don't get it how in this year,
| something like wikipedia, and newspapers in a 4k/1440p monitor
| are a pain to read. I get it, mobile first it's a thing, but with
| something as simple as this your readers will have a great time.
| enriquto wrote:
| This is useless bloat.
|
| Default browser styles are perfectly alright.
|
| When they aren't, this is mainly a self-inflicted problem by your
| browser (that can set whatever default it wants), and by yourself
| (who can easily override the default browser style with either a
| personal css file or just by CTRL+scrolling to change your text
| size). Text size, window width, margins, should never be a
| responsibility of the website.
| civilized wrote:
| So long as we're talking about making websites legible, why is it
| that so many websites these days have content that's too wide for
| a mobile screen and there's no horizontal scroll, so the content
| simply can't be seen?
| achn wrote:
| Is there a html/css only way to automatically "columnize" text
| into multiple columns of reasonable width?
| iza wrote:
| There is the columns CSS property:
| https://developer.mozilla.org/docs/Web/CSS/columns
|
| You probably don't want to apply it to a whole document because
| then you need to scroll back to the top to read the second
| half. But it can be effective to columnize text sections
| between headings.
| achn wrote:
| Thanks. I'd love to see automatic pagination as well so it
| builds full window columnized "pages".
| ranger_danger wrote:
| no example screenshot or demo page? really?
| mort96 wrote:
| The original page seems to be gone from the web, but here's an
| archive of it:
| http://web.archive.org/web/20210318102514/https://jrl.ninja/....
| That shows the described CSS in practice.
| cerved wrote:
| there's a lot of studies about optimal typography for
| readability in terms of fonts and characters per line etc.
|
| Having dead space on the side is kind of a different problem,
| more on the lines of the appropriate default settings of the
| application (or system)
| sva_ wrote:
| It also references this previous discussion:
| https://news.ycombinator.com/item?id=19607169
| freediver wrote:
| What is wrong with browser default styling, and why do browsers
| ship with something that is wrong?
| nawgz wrote:
| Nothing is explicitly wrong, but the spacing on lists and
| headers can look kind of silly. For instance, consider in
| Google Docs - the headers stack nicely, look clean, and lists
| have perfect indentation / spacing
|
| Those changes pretty much cover all this does, and it doesn't
| do a great job IMO. I'd let them get away with "look slightly
| better than defaults nearly everywhere"
| marginalia_nu wrote:
| Historical reasons. Default browser styling still carry a lot
| of heritage from back when screens were 640x480 and you had to
| squeeze as many lines as possible onto the 14" screen.
|
| Of course, if you change the default CSS now that 30 years of
| HTML have been written to rely on these defaults, almost every
| website will break.
| marcosdumay wrote:
| I doubt this. Almost every website overrides all of the
| relevant CSS attributes, because the default is just
| atrocious. Changing the default won't impact them.
|
| Anyway, the browsers still can update the CSS and add a
| "reverse read mode" button that changes it back.
| marginalia_nu wrote:
| They override the CSS attributes that don't fit what they
| are doing now, but changing the defaults would introduce
| new attributes, which may not presently be overridden.
| BrainVirus wrote:
| The modern approach is to do a universal rest:
| *, *:before, *:after { all: unset;
| display: revert; box-sizing: border-box; }
| marginalia_nu wrote:
| Would that actually work as a safeguard against this?
| What you're reverting and unsetting to is the very
| defaults we're talking about changing.
| 411111111111111 wrote:
| That's true, but there could theoretically be more then one
| default. I'm not arguing in favour of it, just pointing out
| the possibility. it would be pretty simple to create a <html
| styling="modern"> so that it's opt-in.
|
| I personally just don't see the point. There are a lot of
| bare bone frameworks around and if you're doing a static
| website (which would likely be the only type to benefit from
| that)... The <10 kilobytes gzipped css won't matter for the
| most part.
| mwcampbell wrote:
| I would still appreciate an opt-in "modern" default that
| browser developers should feel free to change going
| forward. For me, it's not about minimizing download size;
| it's about maintaining a proper division between content
| and functionality, which are what I as an author and
| developer provide, and appearance, which should be up to
| the user agent, to best meet the user's needs and
| preferences. Sure, since I work on accessibility and am
| visually impaired myself, my perspective on this is skewed.
| Still, there are clearly others who wish the browser would
| have more sensible defaults.
| treis wrote:
| It will (maybe) matter in five years when standards have
| changed and that bare bones framework you grabbed isn't
| maintained.
|
| IMHO it's a fairly big miss that default styling is bad,
| we're missing basic controls like drag & drop, and there's
| no native layouts like heros or hamburger menus and so on.
| A lot of cumulative effort has gone into reimplementing
| these things thousands of times.
| wpietri wrote:
| Allow me to go off on a tangent and say:
|
| > 30 years of HTML
|
| holy fucking shit
| amelius wrote:
| > What is wrong with browser default styling, and why do
| browsers ship with something that is wrong?
|
| The problem with browser default styling is that there should
| be another level: user default styling. I.e., the styling as
| chosen by the user.
| phil294 wrote:
| I think this is a valid point. For example, I have always
| wondered why default browser styles don't at least adjust to
| the OS's theme - be it Metro, Material, Qt, Gtk, whatever. It
| would solve a lot of issues for bare-bones websites, while
| still allowing full configurability for websites via
| override. And if we really cannot have nice things because of
| backwards compatibility, make OS integration optional via
| <meta> tag etc.
|
| Why does every website have to reinvent the wheel?
| djbusby wrote:
| Browsers ship with defaults that are now 20 years old - there
| was a cool post here about 8px body padding a while ago.
|
| It's not "wrong" it's legacy.
| postalrat wrote:
| Why is it legacy though? Shouldn't browsers be free to change
| it?
| soulofmischief wrote:
| Web browsers have a hard constraint of backwards
| compatibility. Eventually we could see some CSS directive
| which enables "modern" default styling, both for mobile and
| desktop, but it would be opt-in so that existing sites
| which rely on defaults do not break.
| postalrat wrote:
| I bet if they did an experiment where they changed the
| default styles a bit very very few would complain. Most
| people visiting tiktok or whatever wouldn't even notice.
| pajamanaut wrote:
| Most people visiting tiktok don't do it in their browser
| postalrat wrote:
| And the people visiting it in a browser wouldn't notice.
| soulofmischief wrote:
| Think for a moment. This has nothing to do with tiktok.
| This has to do with your favorite personal website which
| hasn't been updated since 2001.
|
| And any change in default styling would be immediately
| noticed. Pages suddenly centered, or half the width?
| Increased padding?
|
| And "most people wouldn't notice" is a harmful mentality
| in web design which allows minorities to suffer. Most
| people aren't blind, either. Should we not worry about
| them when designing websites?
| marginalia_nu wrote:
| If you change them, almost every website will look bad in
| your browser because most rely on some of these defaults.
| dagurp wrote:
| It would be nice if you could choose between defaults in the
| html tag <html style-default="2022">
| cyral wrote:
| Without max-width the content will stretch across your entire
| screen, which isn't great for readability. It's faster to read
| when you don't have to look across your entire monitor and move
| your neck/head.
| mort96 wrote:
| Default styling looks terrible and is hard to read. Humans are
| good at reading columns at around roughly 80 characters, while
| browsers default to filling the whole width of the screen with
| text, resulting in a column that's hundreds of characters wide.
| Text also gets easier to read when more spaced out; the default
| line height makes the text too close together.
|
| Browsers still ship the bad defaults because changing defaults
| would break existing websites.
| ravenstine wrote:
| I much prefer the default styling other than that the margins
| are nearly nonexistent. Any time I come across a site that
| uses mostly default styling (such as some academic webpages
| from the 90s), I always think to myself "wow, this is
| pleasant to read."
|
| > Text also gets easier to read when more spaced out; the
| default line height makes the text too close together.
|
| The opposite is easily true in my experience. Making text
| large, using ample line height, and even greater spacing
| between paragraphs, makes for text that is more _readable_
| but makes the experience of reading much worse. This is of
| course entirely subjective unless someone comes up with
| measurable evidence, like a study on the sentiment of users.
|
| Something tells me that designers have been taking principles
| that are appropriate to hero page sections, advertisements,
| magazine covers and such, and applying them inappropriately
| to bodies of prose. Larger text with spacing and huge margins
| (or smaller max width) helps the reading impaired, but I
| don't really buy that people actually prefer it.
| roelschroeven wrote:
| I feel that large text with large line heights makes small
| pieces of text (maybe a couple paragraphs maximum) easier
| to read, but makes comprehension of a larger piece of text
| more difficult. It makes you loose overview of the larger
| structure.
|
| It's very well possible that it's all different for
| different people, but I much prefer having a larger piece
| of text in view; smaller font, smaller margins and smaller
| line height all help with that. Longer lines of text too.
| All within reason, of course.
|
| You know how books for children have ridiculously large
| fonts and spacing, in stark contrast with (most) books for
| grown ups? It seems there is a trend now to make websites
| look like the books I had when I was just a little kid. I
| don't like it.
| screamingninja wrote:
| > Humans are good at reading columns at around roughly 80
| characters
|
| What makes you say that? Anecdotally, I prefer using the full
| width of my screen.
| danielvaughn wrote:
| There is a huge amount of research devoted to this. Of
| course personal preferences exist, but there are physical
| constraints like the degree to which your eyes can move
| without turning your neck and other things. It's somewhere
| between 60-120 I think, with 80 right in the sweet spot.
| reaperducer wrote:
| It's actually smaller than 80 characters.
|
| There has been over a century of research into this. It's
| why newspapers print their stories in columns, instead of
| across the entire page, which would be easier.
| maweki wrote:
| Newspapers have been using columns to break up long lines
| for well over a century.
|
| It's hard to find to the next line, if they are too long.
| roelschroeven wrote:
| And it's annoying to have to find the next line every few
| words if the lines are too short.
|
| Newspaper columns have always felt way too short for me.
| Most books have longer lines, and I much prefer that.
| magnio wrote:
| Just look at any physical book. I also wonder how many
| people would read Wikipedia more if they serve the mobile
| version on desktop.
| kylebyproxy wrote:
| Same, I lose my place every time moving from the bottom of
| a column to the top of the next.
| sdenton4 wrote:
| Especially for long blocks of text or becomes easy to go to
| the wrong line when scanning back to the left side of the
| page.
|
| There exist decades of empirical research on this topic.
|
| https://en.m.wikipedia.org/wiki/Line_length
| mort96 wrote:
| Here's a literature review on the topic: https://www.resear
| chgate.net/publication/234578707_Optimal_L.... The article
| content is inaccessible, but from the abstract:
|
| > Research has led to recommendations that line length
| should not exceed about 70 characters per line. The reason
| behind this finding is that both very short and very long
| lines slow down reading by interrupting the normal pattern
| of eye movements and movements throughout the text.
|
| And a document on the topic from the US government:
| https://www.usability.gov/get-involved/blog/2006/08/line-
| len...
|
| > The best available research suggests that users will read
| fastest if the line lengths are longer (up to 10 inches).
| If the line lengths are too short (e.g., two and a half
| inch columns), the line length probably will impede rapid
| reading. Users tend to prefer lines that are relatively
| short (about four inches).
|
| Wikipedia cites a whole bunch of studies on the topic
| (https://en.wikipedia.org/wiki/Line_length):
|
| > Legibility research specific to digital text has shown
| that, like with printed text, line length can affect
| reading speed. If lines are too long it is difficult for
| the reader to quickly return to the start of the next line
| (saccade), whereas if lines are too short more scrolling or
| paging will be required. [...] One proposal advanced that,
| in order for on-screen text to have the best compromise
| between reading speed and comprehension, about 55 cpl
| should be used.[11] On the other hand, there have been
| studies indicating that digital text at 100 cpl can be read
| faster than text with lines of 25 characters, while
| retaining the same level of comprehension.
|
| There's a decent amount of variance, but common across all
| research in this area is that many hundreds of characters
| per line is never found to be the optimal length of a text
| column.
| pronlover723 wrote:
| > (up to 10 inches)
|
| here on HN in my 16" MBP, 10 inches is ~230 characters
| chipotle_coyote wrote:
| The context from the linked article, which dates to 2006:
|
| > Her results showed that passages formatted in the
| longest line length (95 characters per line or 10 inches)
| resulted in the fastest reading speed.
| zvmaz wrote:
| > Humans are good at reading columns at around roughly 80
| characters
|
| Do you have some evidence backing this up? Thanks.
| eslaught wrote:
| This is the sort of thing you can Google, because it is
| extremely common advice. A few of the top hits:
|
| https://www.fonts.com/content/learning/fontology/level-2/te
| x...
|
| https://pimpmytype.com/line-length-line-height/
|
| https://material.io/design/typography/understanding-
| typograp... (see under Line Length)
|
| I don't have any studies at hand, but I think it's been
| pretty well established.
| mort96 wrote:
| I collected a few links here:
| https://news.ycombinator.com/item?id=32972710
|
| 80 is somewhat arbitrary, I could've said 50 or 70 or even
| 100, but it's in the ballpark of what studies find. Studies
| never find 400 characters per line to be optimal.
| alerighi wrote:
| > Humans are good at reading columns at around roughly 80
| characters
|
| Depends. The reason why it may seem better to have narrow
| column is so you can skip ahead more easily and thus read
| faster (reason why newspaper divide an article into columns).
| Otherwise it doesn't make difference.
|
| To me it's absurd that this day the trend is to have wide
| screen displays (16:9 but nowadays even 21:9 is common) and
| then all the text is vertical in a column that makes it
| impossible to read.
|
| I prefer to give the use a choice: after all if the user
| prefers narrow text all he has to do is to take the mouse and
| resize the browser window at the width that he likes! But
| doing the opposite is not possible (at least without an
| extension that modifies CSS), and thus you have to keep
| scrolling something that otherwise would have fitted in a
| single screen.
| mort96 wrote:
| The problem with your preferred solution is that it
| requires changing the window width for each web page. My
| web IRC client requires a somewhat wide window, since it
| has a sidebars of channels on the left and a sidebar of
| users on the right, both of which provide utility and I
| don't want to hide. Reddit is unreadable on narrow screens.
| But blogs would need an 80 column window (I.e 1/4 the width
| of the screen) to be comfortable, unless the blog has some
| sidebar which makes that too narrow. I don't know about
| you, but I switch between tabs frequently, and I'm
| extremely happy that I don't have to resize my browser for
| every tab switch.
|
| I keep my browser window maximised (usually on a secondary
| screen). I like that all web pages are more or less
| readable in that configuration.
| bawolff wrote:
| > it appears that the default font size for most browsers is
| 16px, so 38rem is 608px. supporting 600px displays at a minimum
| seems reasonable.
|
| I dont get the logic here. If the goal is 600px, why are we using
| rem?
| cantSpellSober wrote:
| If the units don't match, changing the user's base font size
| will only affect one of them. Part of why we stopped using rem.
|
| Why are we even _setting_ a font-size on root of we want to
| base the width on the "default?"
|
| Why are we even setting a max-width? Just split text into
| columns to maintain a legible line length.
| [deleted]
| FrontAid wrote:
| I think this does not work well for mobile devices. Spacing and
| the font size is too large. Hence, a lot of screen space is
| wasted and the user has to scroll more. Larger font sizes on
| mobile are usually not a good idea as the device tends to be
| closer to your eyes anyway.
|
| A snippet that could work better in my opinion is the following:
| html { max-width: 70ch; /* larger spacing on
| larger screens, very small spacing on tiny screens */
| padding: calc(1vmin + .5rem); /* shorthand for margin-
| left/margin-right */ margin-inline: auto; /*
| fluid sizing: https://frontaid.io/blog/fluid-typography-2d-css-
| locks-clamp/ */ font-size: clamp(1em, 0.909em +
| 0.45vmin, 1.25em); /* use system font stack:
| https://developer.mozilla.org/en-US/docs/Web/CSS/font-family */
| font-family: system-ui } /* increase line-
| height for everything except headings */ body
| :not(:is(h1,h2,h3,h4,h5,h6)) { line-height: 1.75;
| }
| antics9 wrote:
| This will work in obscure browsers like Netsurf as well:
|
| html{ margin:0 auto; max-width:80ch; padding:0.6em; font-
| family:serif; line-height:1.6; background:#FFF; color:#222 }
| h1,h2,h3{color:#444} img{width:100%}
| logifail wrote:
| > Hence, a lot of screen space is wasted and the user has to
| scroll more
|
| Unfortunately that appears to be the case for a great many
| sites when viewed on a mobile device.
|
| My current pet hate is British Airways,
| https://www.britishairways.com/travel/home/public/en_gb/ has so
| much wasted space that on my Pixel I have to scroll to reach
| the buttons "Manage My Booking" and "Check In". Further down
| the page the "Your account" and "Sign up" bits are so large and
| generously padded that they fill my mobile device's screen all
| by themselves.
|
| Is this by design? Maybe in some warped design brief
| "scrolling" = "[potential] customer interaction" = a KPI gets
| fulfilled?
| bbarnett wrote:
| I bet you think autos should not have wood interiors, too!
| Heathen!
|
| (I wonder if it is a "posh / classy" style or what not?)
| maccard wrote:
| Frankly my pet hate is that page takes 7 seconds to load on a
| 500Mb WiFi connection on a high end android device.
| dwringer wrote:
| I wonder if everyone has a different optimum here based on
| different eyesight, screen size, and usage patterns. I always
| have a slightly different zoom on every website I visit.
|
| With this one I tend to agree, I can't see enough text at once
| and the margins seem a bit wide.
| rch wrote:
| Content on the web used to flow pretty well irrespective of
| those factors. The 'liquid' layout in Adobe's pdf reader
| works as it should, as does the simplified view in Chrome
| (which is suspiciously only offered on sites without ads).
| So, I'm optimistic that simplified layouts are worth
| pursuing.
| bbarnett wrote:
| If Google would stop the absurd block on text reflow and
| resize, on Chrome Android, we'd really be good.
|
| Seeing how slick and smooth and beautiful and handy it is
| on Opera, puts any ridiculous dev team rejections to waste.
|
| Text reflow missing from Chrome -- valid proof end user
| convenience is not a primary concern.
|
| I bet text reflow moves ads into the wrong position, thus
| the decade long block.
| rch wrote:
| Designers want the latitude to place ads where they're
| likely to be effective. How does an ads company which
| incidentally also provides a browser balance that
| interest?
| bbarnett wrote:
| _How does an ads company which incidentally also provides
| a browser balance that interest?_
|
| Another argument for forced Alphabet breakup. Browser in
| one corp, on its lonesome.
|
| Amusingly, Alphabet has given us the number of new
| companies. 26. Maybe Chrome can be called C, Google
| search G of course, M for gmail, etc.
| FrontAid wrote:
| > I wonder if everyone has a different optimum here based on
| different eyesight, screen size, and usage patterns. I always
| have a slightly different zoom on every website I visit.
|
| I would think so. And because of that, accessibility is an
| essential topic. Luckily, this snippet will automatically
| follow your zoom level and/or font size settings.
| mwcampbell wrote:
| But it would be better still if browsers offered an opt-in
| modern default style, to relieve us developers of having to
| make assumptions about the user's visual needs, which
| should be the domain of the user agent.
| jcynix wrote:
| Yeah, the zoom, that almost needs to be customized per
| website, sigh. But one of the worst misfeatures for old (and
| maybe not so old) eyes, is the gray text on some "pastel"
| background. Contrast helps readability (as does a carefully
| chosen font), but "modern" designers seem to think contrast
| is bad or outdated or whatever.
| wolpoli wrote:
| Well modern designers deliver mockup filled with Lorem
| Ipsum so no one notices that the text is hard to read.
| alberth wrote:
| > body :not(:is(h1,h2,h3,h4,h5,h6)) {
|
| That seems both clever and hard to maintain over the long run.
| DaveInTucson wrote:
| hopefully not too dumb a question, but why put this on html
| instead of body?
| FrontAid wrote:
| Au contraire. That is good question. Everything in the
| snippet except the font-size should also work with the body
| selector. The font-size is an exception here as it defines
| the root font size that the `rem` unit is based on. And that
| has to be defined on html.
|
| https://css-tricks.com/html-vs-body-in-css/
| clairity wrote:
| in my personal css framework, i only do fluid type on
| headers, not body text, as i found the effect to be too
| subtle to matter. but header text can be overwhelming on
| small devices without it.
|
| then you can let the user (agent) set the default font size
| on root/html.
___________________________________________________________________
(page generated 2022-09-25 23:00 UTC)