“58 bytes of CSS to look great nearly everywhere” mkws theme
t.mkws.sh
t.mkws.sh
This entire idea is about size first and second, accessibility and look go dead last.
There is no advantage to using 58 bytes only. Just use 14KB if you care that much, which is the size the first 10 TCP packets that your server sends to the client before the first ACK anyway [1].
[1]: https://www.tunetheweb.com/blog/critical-resources-and-the-f...
However, there is a marked difference between "the content is centered in the browser with whitespace on the sides" and the browser default "it's on the left with all the whitespace on the right". The first one wins. That _should_ have been the browser default in absence of a stylesheet rel, but CSS was born when screens were majestically tiny and the idea of a 24" widescreen was literally a vapourware joke, so it wasn't, and so it never will.
Hot take - we need to get over maximizing browser windows. We aren't often using 14" screens anymore, and neither are we browsing at 480p. We're rapidly approaching the point where it just makes no sense, yet people persist in old habits and then can't see that their (now) counterproductive behaviors are causing some of their problems.
I switched to a 40" 4k TV a few years back. It took me a while to break myself of wanting to maximize things, but I had to because the screen is on a desk in front of me, and it's close enough that it's impossible to focus on all at once. I often use a quarter of it for an equivalent 1080p screen, but far more often I'm just throwing windows where I want sized for what I want, zoomed to appropriate comfort, because it's a wall of screen in front of me and ignoring that is counterproductive.
If you have a small screen and you want to maximize windows because of that and the website you're looking at isn't using the space effectively, zoom it. All the browsers support zoom now. Stop trying to fit square pegs into round holes.
But what I was actually saying is less to do with the design in question and was more about people letting habits continue past the point of them being useful and sometimes well past the point of being harmful. What spurred my statement could have had nothing to do with some new design (and this isn't the first time I've stated it).
Another way to look at it is that I can and have made this statement in isolation to design, in a discussion that was more about maximizing windows in the general case. Linking it too closely to the design in question would be to miss a lot of the point I was trying to make.
Line length too long in the current container width? Divide the text into columns.
Hardly. The user centric take is mobile, is the majority of all website traffic and I'm not even addressing at all.
What I'm doing is making a case that desktop users actually make better use of their monitors that have gotten larger over time, and not just maximizes windows, and for developers to not assume everyone else maximizes windows.
Most people browse using a mobile device now, so really this is about the dwindling few left that have a personal desktop computer they use. That's gamers, professionals and office workers. I think most of those have already learnt this lesson, that when you need to have multiple programs opened at once, maximizing one isn't super effective.
> Line length too long in the current container width? Divide the text into columns.
Or just maximize for no reason and have room for other windows if you want, or zoom the content, whichever makes the most sense for your current situation. Requiring someone design their site around being able to dynamically expand to multiple columns, and figure out how to make that work well with what may be side menus and any number of other design choices all because a minority (probably a minority of a minority) set of users wants to maximize to their own detriment seems kind of ridiculous.
People know how to zoom. They do it all the time on sites that are legitimately hard to read or when they are having problems (if I happen to be without my glasses I zoom the shit out of sites). The only people I hear complaining about this are developers who expect maximizing to continue to have the same benefit it did a decade or two ago even though everything else has changes, which is why I think it's rich that this is being called developer centric.
Mobile-first, but supporting wide displays too. Optimize for line length, break into columns in wide containers. Don't "blame" your users for maximizing windows or prescribe an optimal viewport width.
(thanks for discussing)
As for websites providing a singular column view, and sized specifically, there are a lot of reasons for that, and there are also reasons why a multi-column view makes little sense (which of the possible ways does scrolling work if the content can't fit on the screen?). Multiple text columns worked for print media because they had a fixed format, and were also size constrained in pages, meaning they were heavily incentivized to put as much on a page as they could. Text books often have some similar constraints (because there's so much information contained), so rather than 700 smaller pages, they use less pages but multiple columns, but even then they often try to break it up with images and diagrams so it's less common. Recreational reading is probably the closest to the optimal form of comfortably reading, and that uses smaller format singular column pages.
That's not going to translate exactly to the web, but something that is taken into account is that longer line sizes make for things harder to read. With a maximum number of characters in a line size, to fill a window your choices are to either leave white space or use larger characters unless we want multiple columns, but those are harder to read and follow as well. Larger characters will result in less information on the screen at a time, and above a certain size is probably only minimally better than smaller characters, so what we commonly have is white space, for numerous reasons.
There are many good reasons to have a singular column of specific size. People complaining about all the unused space when they can easily rectify that by zooming or resizing is silly, given all the other constraints that make that format optimal.
> I could care less [sic] about this design
We can design it to be legible on narrow and wide displays
> your choices are to either leave white space or use larger characters unless we want multiple columns
We want multiple columns. That way you don't have to prescribe one single viewport width, you can support a range (this is called "responsive")
I think it’s more of a Windows thing too. I don’t see much maximized stuff on Mac OS X.
> full screen is on a secondary monitor
Bizarre habit of yours! Personally, I can’t understand maximized windows on desktop at all.
Personally, I can’t understand maximized windows on desktop at all.
Maximized windows, yeah it’s all kinda gross to me.
Personally, I can’t understand maximized windows on desktop at all. Apparently you use them though.
99% of the time I don’t have an external monitor
It isn't. Just looks that way because the first few sentences are short.
<link rel=stylesheet
href=s.css?2020-12-12T18:42:29Z>
Um… did you really just spend 53 bytes on loading a 62-byte (plus HTTP overhead) external stylesheet?Here, let me fix that with these 61 bytes:
<style>main{max-width:38rem;padding:2rem;margin:auto}</style>6 days ago (242 comments)
https://news.ycombinator.com/item?id=32972004 (gist.github.com)
This older submission with the same title links to a 404[0]!
https://news.ycombinator.com/item?id=19607169 (jrl.ninja)
3 years ago (255 comments)
[0] Web Archive link https://web.archive.org/web/20210318102514/https://jrl.ninja...
pre {
overflow-x: auto;
}
to solve the side scroll.https://stackoverflow.com/questions/8937591/is-it-possible-t...
A 64 byte CSS dark theme with a monospace font based on the 58 byte CSS theme [1] and a page that could be an entry for the 1kB club [2].
[1] https://gist.github.com/JoeyBurzynski/617fb6201335779f8424ad...
The CSS is just:
html{filter:invert();font:2em monospace;max-width:32em;margin:auto;}
The "dark theme" is just an inversion of the HTML colours. It assumes the HTML page will be loaded with the default black on white.It seems as though the browser doesn't correctly apply inversion across the the background and foreground, or applies its implementation of the dark theme incorrectly after. Either way I believe this is weirdness caused by Bromite.
I saw on Netscape and Dillo that it just ignores the inversion as it doesn't support it, but I don't know what Chrome/Chromium (desktop) does. If you have Chrome/Chromium desktop would you mind testing it? (My local Chromium is borked for complicated reasons.)
Works in Firefox though.
Edit: upon some further investigation, the CSS is inverting the elements correctly, except the html (or maybe body) background from white to black. Chromium seems to not want to do that. Now I'm curious and gonna find out why tomorrow
> Edit: upon some further investigation, the CSS is inverting the elements correctly, except the html (or maybe body) background from white to black. Chromium seems to not want to do that. Now I'm curious and gonna find out why tomorrow
I think this is an implementation mistake by Chromium? Body is a subset of HTML, and body sets the background colour? This is probably related: https://stackoverflow.com/a/61265706/2847743
EDIT: Maybe try switching `html` for `body` in the CSS?
UPDATE: I pushed some new CSS:
html{filter:invert(.9);font:2em monospace;width:9in;margin:auto}
As a workaround it inverts at 90%, so should leave the text at least readable if the inversion fails.I also realized it no longer was within the 64 bytes I claimed, so I did some work on reduction too.
The CSS fragment referred to can be found here: https://gist.github.com/JoeyBurzynski/617fb6201335779f8424ad...
html{margin:0 auto;max-width:80ch;line-height:1.6}
Example: https://chai.guru/www/