6 ms·

This seems to fall into the 'simplistic, not simple' school of thought. You can have a relatively simple website if it doesn't do anything and if it cuts corner

by gwern 3y ago

This seems to fall into the 'simplistic, not simple' school of thought. You can have a relatively simple website if it doesn't do anything and if it cuts corners. Take your dark mode, which is just about the only nontrivial feature I see on this page. (One could also criticize the low contrast of the appearance and other problems, but that's less relevant to the simplicity thesis you're claiming.) First, your dark mode is implemented wrong in the lazy corner-cutting way of doing JS post-load instead of the correct way of CSS body classes; so you get the 'flash of white' unavoidably on every page load - just what every dark mode user with their phone to their face at midnight wants to see! (If your solution doesn't work, it doesn't matter if it's 'simple' or 'complex'.) Second, you implement what is like 3 lines of JS (setting localstorage & dark-mode) by pulling in what looks like an entire interpreter for a custom 'hyperscript' https://hyperscript.org/ https://hyperscript.org/ language which seems to mostly just offer some sugar over JS; now, maybe you use 'hyperscript' elsewhere for reasonable purposes, but surely pulling in a 96kb (uncached) library solely to run def saveMode() if first classList.value of <html/> contains 'dark' set localStorage.kkColorMode to 'dark' else set localStorage.kkColorMode to 'light' end end init if localStorage.kkColorMode is empty set localStorage.kkColorMode to 'light' end if localStorage.kkColorMode is 'dark' add .dark to <html/> end is a bit against the spirit of this "simplicity is the ultimate perfection" enterprise...? Personally, I feel like I see some easy perfection to add right there. (And is this hyperscript stuff also why the HTML doesn't validate?) Third, this binary toggle is a bad way to implement dark mode because it ignores system/browser settings, so if a user has, say, enabled dark-mode on their smartphone OS, they still get served light-mode until they manually enable it; note that some systems change it based on local time/ambient light too, which is quite nice... if websites & apps respect it instead of overriding it. And since localstorage expires and users switch devices, they would have to do so repeatedly. Is this a good thing? A user probably would disagree with the developer who is touting how 'simple' the dark-mode implementation is because they cut corners in handling system settings/auto-dark-mode...

nickelpro 3y ago
> First, your dark mode is implemented wrong in the lazy corner-cutting way of doing JS post-load ... I agree with your whole comment, but the media query approach is also tricky. You typically still want to offer a toggle while respecting prefers-color-scheme, and you may want to give priority to whatever choice the user has made with that toggle if they've used it on your site before. This still requires JS and localstorage. So what to do? My preferred choice is having an inline style element of: body {visibility: hidden; opacity: 0;} This will maintain the previous page until DOMContentLoaded, at which point you can query prefers-color-element and localstorage, set the body class correctly, and let the page paint.
- onion2k 3y ago
  This still requires JS and localstorage. I've been considering this recently for my site and I settled on having prefers-color-scheme on the root domain with dark. and light. subdomains. If the user chooses a color they just get bumped to a subdomain that sets a cookie with their preference. If they come to the site from an external link and they have a preference cookie they get redirected to the subdomain again. Absolutely no clientside JS is needed anywhere, no FOUC issues, and it's trivially simple to code because it's literally just a redirect in the server config based on a cookie value. I really should spend the time to actually build it, but Diablo 4 came along and I got sidetracked.
  - gwern 3y ago
    I don't know whether to be fascinated or horrified by this proposal, but I admire the novelty - I can definitely say that in all the dark-mode proposals/implementations I've looked at over the years we've been fiddling with ours, I've never seen that suggested.
  - porridgeraisin 3y ago
    Wouldn't the following be a better version of the above. Use css variables everywhere, and have a defs-dark.css and a defs-light.css that define the colors. Then, on nginx, serve the correct stylesheet based on cookie value. Better than subdomains for dark and light, no?
    - onion2k 3y ago
      My idea has the benefit that users can block the cookie if they want to and still use whatever mode they want, although they'd lose the redirection 'functionality' if they do that.
  - account42 3y ago
    This sounds like it would have the same problem as redirects to mobile subdomains - users will share links to light. and dark. subdomains, unknowingly forcing their preference onto the recipient. The proper solution is to only implement the media queries and yell at browser vendors to make this easier to toggle either for all websites or for specific websites. Implementing a light/dark mode switch in every website is absurd.
fluidcruft 3y ago
I don't notice any "flash of white" (Firefox, Chrome, Safari on Mac; Firefox, Chrome on Android). Not on initial page load, refresh nor toggling between Dark and Light. It seems to just work.
- deleted 3y ago
  [deleted]
- shthed 3y ago
  the pages flashes light mode when refreshing the page with dark mode enabled, chrome on windows.
  - fluidcruft 3y ago
    Ohh... yeah that happens. I thought it was describing the entire page flashing as solid white.
    - gwern 3y ago
      Well yes, the entire page flashes white if you have FOUC because you implemented it wrong. And since mobile browsers are usually fullscreened, it means the entire device flashes you; I assume you don't use dark-mode much if you haven't noticed this. But dark-mode users do notice and once in a great while, even complain to you about it.
eviks 3y ago
Excellent point, unfortunately the broken, but simplistic school of thought is also prevalent along with the broken and bloated one...
SPBS 3y ago
Honestly if the goal is a website as simple as possible, dark mode should not belong there at all. We've had simple readable websites in 90s long before the dark mode fad was a thing, only having light mode is fine. > Third, this binary toggle is a bad way to implement dark mode because it ignores system/browser settings, so if a user has, say, enabled dark-mode on their smartphone OS, they still get served light-mode until they manually enable it; note that some systems change it based on local time/ambient light too, which is quite nice... if websites & apps respect it instead of overriding it. There's so much complexity here that goes against the philosophy of a simple website if simplicity is the goal. They should just skip dark mode entirely. HN itself is perma light mode, it doesn't stop me from reading it at night.
- grogenaut 3y ago
  hn isn't pure white and it does kill me at night on powerful monitors... just like I can't do dark mode outside on a laptop. Sure we did readable websites in the 90s, on dialup or slow dsl, and they took forever to load on small monitors. We also didn't have USB or SSDs. Dark mode and light mode is a nice tradeoff for varied lighting conditions.
  - SPBS 3y ago
    Well I don't really mean white, but more of pick a default theme that works in both day and night and stick with it. So that it's all kept very simple. You could use a dark theme as the default as well, but light mode tends to be more accessible in more situations so I prefer light over dark. As an example, I think the Solarized Light palette is pretty usable in all situations.
  - simondotau 3y ago
    If you have ergonomic issues with mostly white screens, it should be the job of your operating system or web browser to police this. It wouldn’t be difficult to implement a feature that sets a maximum total luminance for each page. Perhaps even automatically inverting the colours if it’s over a certain threshold.
vintagedave 3y ago
I was reading this thinking "that's a great analysis" and then read _who_ posted it. OP, this is the author of https://gwern.net https://gwern.net, which has been very influential in the design of many technical blogs / personal sites and has some very inventive and fantastic ideas. Ie, the author knows what they're talking about. My site uses CSS to respect light/dark theme, so has no manual toggle. It requires Javascript and I have a personal goal to have a JS-free site, just pure HTML and CSS. I also think that a site should respect the user's own light/dark settings, and so a toggle, if one ever exists for a site, should really be a browser setting on the browser toolbar. /u/gwern, in case you read this, your design along with Tufte.css were one of the influences of my own site: https://daveon.design/ https://daveon.design/ . (Also present is inspiration from older-style publishing and manuscripts, and personal preferences. But your site was the first one -- a key influence -- I saw that inspired me with what a modern, clean personal website could be and how it could look, as well as what it might contain. It's a real honour to see you here and reply!)
- flanbiscuit 3y ago
  > My site uses CSS to respect light/dark theme, so has no manual toggle. It requires Javascript and I have a personal goal to have a JS-free site, just pure HTML and CSS. I also think that a site should respect the user's own light/dark settings, and so a toggle, if one ever exists for a site, should really be a browser setting on the browser toolbar. I agree that it should definitely respect the OS level setting but I really like it when I'm given the option to override that setting. What if I don't like the way a site implemented their dark mode styles and I would rather switch back to light mode for just that one site. Having no toggle on the site I would have to go to my OS level settings, turn dark mode off, then later remember to go back to my OS level settings and turn it back on.
- gwern 3y ago
  That's very flattering. So I'll relay some comments on your site: - you make sentence-spacing a major design goal. I looked into that a bit ago and I found little or no real evidence that sentence-spacing is a good idea (https://gwern.net/doc/design/typography/sentence-spacing/index https://gwern.net/doc/design/typography/sentence-spacing/ind...) and it would be expensive to implement: you do the only reasonable thing of injecting <span>s... but oh so many <span>s. If you get long pages like mine, that is going to cost you - DOM nodes are not free, soldier! - one issue with sentence-spacing is that you are fighting HTML & CSS the entire way. They just do not want to do it. You correctly note that it's hard, but you accidentally demonstrate it's even harder than you thought: you have justification enabled but not hyphenation... so all that happens is that sentences get stretched out to make them fully-justified and you get large double-spaces everywhere! Your current implementation winds up being not so much 'sentence-spacing' as 'every few words spacing'. (This is especially glaring in the sidenotes, like on the page I'm looking at right now, 'Stephen Zamadics' looks like 'Stephen_________Zamadics'. Since you set the column narrow, you probably want good hyphenation too... perhaps server-side, if you're deadset against JS.) - Dropcap positioning is hard, especially if you'd like it to work on more than one browser, and I'm not surprised yours has problems; pretty much everyone screws those up. (At least, I assume you don't intend the positioning problems like the '1' almost overlapping the 'someone' in cases like https://daveon.design/creating-joy-in-the-user-experience.html#emotion-in-digital-interaction https://daveon.design/creating-joy-in-the-user-experience.ht... .) - I think the dotted underlining is too hard to see: much too small and close to the link. Are you sure you don't need `text-decoration-thickness: from-font` & `text-underline-position: from-font`? - Rubricating the entire sidenote on hover seems excessive. - Sidenote numbering is very confusing. They get numbered 1/2/3/4... and then all lose their numbers in favor of ''? Mixing numbered & unnumbered is confusing enough, but then transitioning at the utterly arbitrary '5' let me baffled and wondering if the ''s were supposed to be a separate kind of sidenote like a margin-note. Definitely a case for 0/1/infinity. - Sidenotes come off as cluttered and hard-to-read, at least partially because they are all 1 big paragraph. Breaking them up would increase readability. I hope you didn't inherit Tufte-CSS's unnecessary and artificial limitation to non-block elements...? (I can't believe they refuse to fix that.) - EB Garamond is a variable font, which is a bit of a questionable choice because OS+browser support is still relatively low. (Just browser-wise, it's only at ~95% global https://caniuse.com/?search=variable%20font https://caniuse.com/?search=variable%20font so add on OS incompatibility... The text should still render, but it won't look like you expect it to. Example: https://share.obormot.net/screenshots/Arcturus_Screen%20Shot%202023-07-06%20at%208.55.34%20PM.png https://share.obormot.net/screenshots/Arcturus_Screen%20Shot... Also shows the sentence-spacing problems & dropcap problems.) - The use of auto-smallcaps (after H1s, I guess?) winds up feeling busy and confusing. Look at a page like https://daveon.design/about-dave-on-design.html https://daveon.design/about-dave-on-design.html where the sections so short - it winds up feeling like smallcaps is just being sprayed around at random, and the logic is lost. - Your image dragging widget is mysterious. The icons are unfamiliar and so small that they signal non-interactive. - am I imagining it or are your <hr>-asterisk-thingies weirdly offset to the right? - The lack of any header or obvious site navigational apparatus, despite the very large header, makes the site feel somehow cramped and confining. You must like your tree - have you considered the classic HTML approach of an image map? - The use of triangles in the ToC is a bad idea. They look too much like collapse/disclosures, which are becoming increasingly common, especially in ToCs like this, especially when the reader has already seen you use black-dots for unordered list markers. - Easter eggs like `X-Clacks-Overhead` are fine, but the page should still validate... (Doesn't look like a legal http-equiv to me: https://html.spec.whatwg.org/multipage/semantics.html#attr-meta-http-equiv https://html.spec.whatwg.org/multipage/semantics.html#attr-m... ) - You have low-hanging fruit in performance and can definitely render faster: https://pagespeed.web.dev/analysis/https-daveon-design-about-dave-on-design-html/3sc6h93ine?form_factor=mobile https://pagespeed.web.dev/analysis/https-daveon-design-about... - Tooltips, tooltips, tooltips!

by gwern 3y ago

nickelpro 3y ago

> First, your dark mode is implemented wrong in the lazy corner-cutting way of doing JS post-load ... I agree with your whole comment, but the media query approach is also tricky. You typically still want to offer a toggle while respecting prefers-color-scheme, and you may want to give priority to whatever choice the user has made with that toggle if they've used it on your site before. This still requires JS and localstorage. So what to do? My preferred choice is having an inline style element of: body {visibility: hidden; opacity: 0;} This will maintain the previous page until DOMContentLoaded, at which point you can query prefers-color-element and localstorage, set the body class correctly, and let the page paint.

onion2k 3y ago
This still requires JS and localstorage. I've been considering this recently for my site and I settled on having prefers-color-scheme on the root domain with dark. and light. subdomains. If the user chooses a color they just get bumped to a subdomain that sets a cookie with their preference. If they come to the site from an external link and they have a preference cookie they get redirected to the subdomain again. Absolutely no clientside JS is needed anywhere, no FOUC issues, and it's trivially simple to code because it's literally just a redirect in the server config based on a cookie value. I really should spend the time to actually build it, but Diablo 4 came along and I got sidetracked.
- gwern 3y ago
  I don't know whether to be fascinated or horrified by this proposal, but I admire the novelty - I can definitely say that in all the dark-mode proposals/implementations I've looked at over the years we've been fiddling with ours, I've never seen that suggested.
- porridgeraisin 3y ago
  Wouldn't the following be a better version of the above. Use css variables everywhere, and have a defs-dark.css and a defs-light.css that define the colors. Then, on nginx, serve the correct stylesheet based on cookie value. Better than subdomains for dark and light, no?
  - onion2k 3y ago
    My idea has the benefit that users can block the cookie if they want to and still use whatever mode they want, although they'd lose the redirection 'functionality' if they do that.
- account42 3y ago
  This sounds like it would have the same problem as redirects to mobile subdomains - users will share links to light. and dark. subdomains, unknowingly forcing their preference onto the recipient. The proper solution is to only implement the media queries and yell at browser vendors to make this easier to toggle either for all websites or for specific websites. Implementing a light/dark mode switch in every website is absurd.

fluidcruft 3y ago

I don't notice any "flash of white" (Firefox, Chrome, Safari on Mac; Firefox, Chrome on Android). Not on initial page load, refresh nor toggling between Dark and Light. It seems to just work.

deleted 3y ago
[deleted]
shthed 3y ago
the pages flashes light mode when refreshing the page with dark mode enabled, chrome on windows.
- fluidcruft 3y ago
  Ohh... yeah that happens. I thought it was describing the entire page flashing as solid white.
  - gwern 3y ago
    Well yes, the entire page flashes white if you have FOUC because you implemented it wrong. And since mobile browsers are usually fullscreened, it means the entire device flashes you; I assume you don't use dark-mode much if you haven't noticed this. But dark-mode users do notice and once in a great while, even complain to you about it.

eviks 3y ago

Excellent point, unfortunately the broken, but simplistic school of thought is also prevalent along with the broken and bloated one...

SPBS 3y ago

Honestly if the goal is a website as simple as possible, dark mode should not belong there at all. We've had simple readable websites in 90s long before the dark mode fad was a thing, only having light mode is fine. > Third, this binary toggle is a bad way to implement dark mode because it ignores system/browser settings, so if a user has, say, enabled dark-mode on their smartphone OS, they still get served light-mode until they manually enable it; note that some systems change it based on local time/ambient light too, which is quite nice... if websites & apps respect it instead of overriding it. There's so much complexity here that goes against the philosophy of a simple website if simplicity is the goal. They should just skip dark mode entirely. HN itself is perma light mode, it doesn't stop me from reading it at night.

grogenaut 3y ago
hn isn't pure white and it does kill me at night on powerful monitors... just like I can't do dark mode outside on a laptop. Sure we did readable websites in the 90s, on dialup or slow dsl, and they took forever to load on small monitors. We also didn't have USB or SSDs. Dark mode and light mode is a nice tradeoff for varied lighting conditions.
- SPBS 3y ago
  Well I don't really mean white, but more of pick a default theme that works in both day and night and stick with it. So that it's all kept very simple. You could use a dark theme as the default as well, but light mode tends to be more accessible in more situations so I prefer light over dark. As an example, I think the Solarized Light palette is pretty usable in all situations.
- simondotau 3y ago
  If you have ergonomic issues with mostly white screens, it should be the job of your operating system or web browser to police this. It wouldn’t be difficult to implement a feature that sets a maximum total luminance for each page. Perhaps even automatically inverting the colours if it’s over a certain threshold.

vintagedave 3y ago

I was reading this thinking "that's a great analysis" and then read _who_ posted it. OP, this is the author of https://gwern.net https://gwern.net, which has been very influential in the design of many technical blogs / personal sites and has some very inventive and fantastic ideas. Ie, the author knows what they're talking about. My site uses CSS to respect light/dark theme, so has no manual toggle. It requires Javascript and I have a personal goal to have a JS-free site, just pure HTML and CSS. I also think that a site should respect the user's own light/dark settings, and so a toggle, if one ever exists for a site, should really be a browser setting on the browser toolbar. /u/gwern, in case you read this, your design along with Tufte.css were one of the influences of my own site: https://daveon.design/ https://daveon.design/ . (Also present is inspiration from older-style publishing and manuscripts, and personal preferences. But your site was the first one -- a key influence -- I saw that inspired me with what a modern, clean personal website could be and how it could look, as well as what it might contain. It's a real honour to see you here and reply!)

flanbiscuit 3y ago
> My site uses CSS to respect light/dark theme, so has no manual toggle. It requires Javascript and I have a personal goal to have a JS-free site, just pure HTML and CSS. I also think that a site should respect the user's own light/dark settings, and so a toggle, if one ever exists for a site, should really be a browser setting on the browser toolbar. I agree that it should definitely respect the OS level setting but I really like it when I'm given the option to override that setting. What if I don't like the way a site implemented their dark mode styles and I would rather switch back to light mode for just that one site. Having no toggle on the site I would have to go to my OS level settings, turn dark mode off, then later remember to go back to my OS level settings and turn it back on.
gwern 3y ago
That's very flattering. So I'll relay some comments on your site: - you make sentence-spacing a major design goal. I looked into that a bit ago and I found little or no real evidence that sentence-spacing is a good idea (https://gwern.net/doc/design/typography/sentence-spacing/index https://gwern.net/doc/design/typography/sentence-spacing/ind...) and it would be expensive to implement: you do the only reasonable thing of injecting <span>s... but oh so many <span>s. If you get long pages like mine, that is going to cost you - DOM nodes are not free, soldier! - one issue with sentence-spacing is that you are fighting HTML & CSS the entire way. They just do not want to do it. You correctly note that it's hard, but you accidentally demonstrate it's even harder than you thought: you have justification enabled but not hyphenation... so all that happens is that sentences get stretched out to make them fully-justified and you get large double-spaces everywhere! Your current implementation winds up being not so much 'sentence-spacing' as 'every few words spacing'. (This is especially glaring in the sidenotes, like on the page I'm looking at right now, 'Stephen Zamadics' looks like 'Stephen_________Zamadics'. Since you set the column narrow, you probably want good hyphenation too... perhaps server-side, if you're deadset against JS.) - Dropcap positioning is hard, especially if you'd like it to work on more than one browser, and I'm not surprised yours has problems; pretty much everyone screws those up. (At least, I assume you don't intend the positioning problems like the '1' almost overlapping the 'someone' in cases like https://daveon.design/creating-joy-in-the-user-experience.html#emotion-in-digital-interaction https://daveon.design/creating-joy-in-the-user-experience.ht... .) - I think the dotted underlining is too hard to see: much too small and close to the link. Are you sure you don't need `text-decoration-thickness: from-font` & `text-underline-position: from-font`? - Rubricating the entire sidenote on hover seems excessive. - Sidenote numbering is very confusing. They get numbered 1/2/3/4... and then all lose their numbers in favor of ''? Mixing numbered & unnumbered is confusing enough, but then transitioning at the utterly arbitrary '5' let me baffled and wondering if the ''s were supposed to be a separate kind of sidenote like a margin-note. Definitely a case for 0/1/infinity. - Sidenotes come off as cluttered and hard-to-read, at least partially because they are all 1 big paragraph. Breaking them up would increase readability. I hope you didn't inherit Tufte-CSS's unnecessary and artificial limitation to non-block elements...? (I can't believe they refuse to fix that.) - EB Garamond is a variable font, which is a bit of a questionable choice because OS+browser support is still relatively low. (Just browser-wise, it's only at ~95% global https://caniuse.com/?search=variable%20font https://caniuse.com/?search=variable%20font so add on OS incompatibility... The text should still render, but it won't look like you expect it to. Example: https://share.obormot.net/screenshots/Arcturus_Screen%20Shot%202023-07-06%20at%208.55.34%20PM.png https://share.obormot.net/screenshots/Arcturus_Screen%20Shot... Also shows the sentence-spacing problems & dropcap problems.) - The use of auto-smallcaps (after H1s, I guess?) winds up feeling busy and confusing. Look at a page like https://daveon.design/about-dave-on-design.html https://daveon.design/about-dave-on-design.html where the sections so short - it winds up feeling like smallcaps is just being sprayed around at random, and the logic is lost. - Your image dragging widget is mysterious. The icons are unfamiliar and so small that they signal non-interactive. - am I imagining it or are your <hr>-asterisk-thingies weirdly offset to the right? - The lack of any header or obvious site navigational apparatus, despite the very large header, makes the site feel somehow cramped and confining. You must like your tree - have you considered the classic HTML approach of an image map? - The use of triangles in the ToC is a bad idea. They look too much like collapse/disclosures, which are becoming increasingly common, especially in ToCs like this, especially when the reader has already seen you use black-dots for unordered list markers. - Easter eggs like `X-Clacks-Overhead` are fine, but the page should still validate... (Doesn't look like a legal http-equiv to me: https://html.spec.whatwg.org/multipage/semantics.html#attr-meta-http-equiv https://html.spec.whatwg.org/multipage/semantics.html#attr-m... ) - You have low-hanging fruit in performance and can definitely render faster: https://pagespeed.web.dev/analysis/https-daveon-design-about-dave-on-design-html/3sc6h93ine?form_factor=mobile https://pagespeed.web.dev/analysis/https-daveon-design-about... - Tooltips, tooltips, tooltips!