That's nice but really, the problem with css (or what's hard difficult about it) is not designing a single page that has a single column of text with some titles. Any large css files that this is supposed to counter will probable have very similar (and as small) css rules for that same thing. It becomes hard when you need a grid, templates, images, and other more complex designs.
Lack of server side modularization of HTML strikes again. It makes no sense that we still have no declarative way of modularizing content apart from using IFRAME. Why can I dynamically load parts and merge it in the DOM via JS but not via a declarative HTML feature?
Sure, but that's only easy if you choose to ignore the 1 in 10 users that it doesn't work for, which is too many for most real world use cases, especially for something as fundamental as the layout of the page.
Not everyone needs to have the same experience. A common pattern is to make a responsive layout where CSS Grid isn't used on the smallest screens and that's the default. Many of the browsers that don't support CSS Grid are mobile ones anyway but even in a desktop browser they can get a not-ideal but usable layout.
you are right, and that is a great solution if you don't care about offering the actual experience to all users.
If the original problem you need to solve is "using css to style a website so all users have the expected experience" then you need more than 5 lines of css.
"The" actual experience is a myth, all users are not going to have the same experience no matter what, that's one of the points behind responsive design. What I was presenting was an alternative to ignoring CSS Grid because someone thinks it doesn't have sufficient browser adoption.
Those 1 in 10 users don't provide enough revenue to warrant doubling our front end budget to support every polyfill, every workaround for every non-polyfillable thing, and the vast quantities of extra support they require.
You're limiting 'accessibility' to the current 'boil the ocean' approach pushed by the accessibility industry, which has a perverse profit incentive in the problem not being solved.
Accessibility is better addressed in the client than in the server.
True. Grid still has a long way to go. Flexbox works as a nice alternative in the meanwhile. However, the semantics of the flex is too confusing and cumbersome.
yes it has a grid. What I meant was that showing 5 lines of css saying "css is simple we don't need more" is kind of irrelevant, because that's not where we face challenges with css.
CSS has a grid system, but even assuming 100% compatibility, you still need to declare your grid and elements inside it, etc. and that is not done in 5 lines of css.
There is a small accessibility problem with the CSS presented on this page. The author set `text-decoration: none;` on the links, relying only on color to identify them. This should be avoided.
339 bytes which load an additional 241 bytes of CSS to load a 53k custom font...
What is the point people are trying to make with titles like this? It's like claiming "50 bytes to make a website" after you figure out that you can just iframe Google.
The less code you write the less you have to maintain.
Or at least that's how I understood this. Not attempting to save the few kb of network traffic, rather trying to reduce the complexity and the amount of code one has to maintain in the future.
That may be true, but in this case simply listing a few system fonts in their order of precedence resulted in less code to maintain since you lose the import directive. See the updated article.
In general, the way I see it, relying on code and data from a third party at run-time is a liability. The code and data you no longer have to maintain is now impossible to audit because the vendor may replace it, stop providing the service, start using it for tracking etc. at any moment. It's code that you should be maintaining but can't.
What is it with all those reduced font/background contrast styles? To me these are terribly hard to read. As a matter of fact a large part of my Stylish/Greasemonkey sets are just there to get back decent contrast on text.
Why such thin grey text? Why sacrifice readability as a matter of principle? What's wrong with black on white, like a regular f*cking book or newspaper?
Because paper is paper and screens are different. The white paper is slightly on the grey side compared to white on screen. And that hurts to look at for long.
Thin text is a personal preference that I made here. No principles there.
It becomes an accessibility problem, because the contrast is too low, and not all eyeballs are the same. Low contrast combined with a thin font makes it very difficult to read.
The problem isn't the colour choice for the font. The problem is with the colour choice of the background combined with the weight of the font and a thin-stroked sans font.
This is spectacular, thank you. It's small enough to just inline into the webpage and provides a nice enough experience to just leave it alone for a very basic page.
Sometimes I wish some of those markdown viewers would come with such an effective CSS. For example, the KDE document viewer Okular can display markdown files but they look just awful.
Once I tried finding the source of the Okular style but ended up creating a custom script to convert Markdown files to PDF files with a custom CSS (via Chromium...).
Times New Roman is fine - serif fonts are supposedly more readable - it's the line widths that kill me here - figuring out which line you're due to start on next really disrupts flow
You can resize the window and the text flows to fit, which is something a weird amount of websites prevent you doing. You can ctrl+ to increase font size if it's too small, or ctrl- if it's too big.
I dislike the white background, but otherwise it's very readable for the way I use web browsers -- one of some open windows.
Browsing the web using half of 1600 pixels in width is a surprising amount of pain in the ass, but perfect for CSS-free sites. It seems that designers tend to design for full screen, which I guess reflects their own workflow, but not at all mine as a programmer.
Hardly anyone is writing their styles to set the body text to Times New Roman. Aside from serif typefaces not actually being so bad, if you're seeing Times New Roman on sites like these, it's because you haven't set your default font and your browser is falling back to it on your system.
Fixing this in Firefox is as easy as opening about:preferences in a new window and selecting your preferred sans font. Dan's site will instantly be transformed, and every other site like his (e.g. http://cr.yp.to/https://motherfuckingwebsite.com etc) will be rendered similarly for all future visits.
The web bloat page does have a little CSS in the header. If there was a limit on the words per line, that's all I need on desktop. In mobile Safari, the text size is a little small; I think mobile Safari's default font-size is 16px, same as desktop, it should probably be 18px. This site's CSS could make it bigger (wouldn't even need to make it mobile-only).
Mobile Safari is doing an okay horizontal scroll for the data tables because they don't fit in the portrait width on my phone; to make it nicer on mobile calls for using different HTML, either repeating the data in the original HTML and selectively displaying them with CSS or using JavaScript to manipulate the data.
There's also the site (can't find it anymore, anyone got a link?) that offered a different metric for how bloated your site is: divide the total page weight by the same page's contents rendered into a jpeg.
Is there anybody here who is deeply in the frontend rabbithole and can recommend a JS free CSS framework that we can use for a project where readability & UX matters a lot? Somebody recommended material.io but is it not JS free. I was wondering if there is a JS free CSS framework that looks great.
It was funny the first time, but the gimmick was run straight into the ground with all the followup versions that tried to double down on the writing style.
Same will happen with this. Yesterday it was 55 bytes of CSS or whatever, today it's 339, pretty soon people will be creating "Responsive CSS in 69 lines LOL GEDDIT" and the cycle will begin anew.
i still have not. "pseudo-masculine tough guy" aesthetic are efficient, especially for learning/reading space (80% of my time spent on the net). It does not have to be as ugly as "better fing website", but still.
It's "responsive" in the way a single column of content can be responsive. Really the only gain was that a max-width property was set, so content won't stretch to the edges of your desktop display.
Kinda funny... While I understand your point I feel the opposite. I hate it when people do not include a max-width because then I have to care about it. Yes, the Firefox reader view makes it quite easy, but I still prefer having a ready-to-read layout by default.
But you are right, in this case, it all comes down to personal preference.
That wouldn't go well with the font I was using. Fira Light is very thin as it is. A lighter shade of black would affect readability on certain screens.
It's 339 bytes of CSS which loads 2.3k of font css which loads 21k of woff2. 23k requiring two round trips (three if the stylesheet is in a separate file, four including the initial HTML load), and to prevent FOUT, the browser won't show any text at all until all the round trips are completed (or it decides it's taking too long and shows the wrong font). Plus you're adding a dependency on Google for no good reason.
I mean, it's not exactly worse than other websites, it's maybe honestly worth it because Fira looks pretty good, it's just not really 339 bytes.
I agree completely regarding light weight fonts. Wikipedia recently changed their mobile view font to Segoe UI Light for body text, and my old eyes can barely read the damn thing.
We're talking about different pages - one is the page with the blog post about this 339 bytes of responsive CSS (it's 2+MB). The other is the demo page with 339 bytes of CSS + the web font. The former is what the parent was talking about.
Yep ... the first thing I did was to see if he was "eating his own dog-food". As an aside, I'd recommend against putting the linked site on a projector at work (or at least look at it first to determine whether it fits your organization's culture).
Yes ... I didn't even think about the fact that "linked site" is ambiguous in this case. I wonder if you can play the "six degrees of separation" game (Kevin Bacon) with web-sites. How many links do you need to follow to get from any random site to any other? If the web is fully connected, then "linked site" is fully ambiguous!
Of all the people who over use css frameworks like bootstrap, I'm one of them as well and this is an attempt to start correcting that mistake.
I'm not sure what "over use" really means here, but I think calling it a mistake is wrong. Using bootstrap (or any other framework) is optimizing for something other than download size. That might be development speed, better design than you're capable of, cross-browser compatibility, etc, but it's not wrong unless you're building a site that really needs to be fast and small.
If you're building an admin page that'll be accessed by 5 people in total and can be cached for a year between updates then Bootstrap is great.
If you're building a blog that's going to get 2000 readers a month and want to concentrate on writing articles instead of writing frontend code, Bootstrap works really well.
If you're making a new login form for Facebook's homepage that'll get 100,000,000 visitors in the first hour it's live, maybe Bootstrap is the wrong choice.
CSS frameworks are tools, and they have their place. There isn't a universal rule that says using one is wrong.
What I meant by overuse is this. A lot of people I know, use bootstrap for literally everything. Even if it is just a 2 page website with a block of text and image and a form the first instinct is to drop in the entirety of bootstrap and just go on the way. Do you really need so much of css, hundreds of unused classes just because you wanted a grid, even when you can probably use flex and a lot of native css stuff.
My target for this post was people who use css frameworks are a UI standardising tool rather than a UI styling tool.
I'm curious, how do you plan on styling going forward?
Have you had a look at https://tailwindcss.com? I'm just finishing a large redesign project using tailwind on a Rails/Vue platform and the experience has been great. The idea is that all classes are small, focussed and do one thing only. The downside is that the markup starts to look like 1995 again. The upside is the speed at which you can style a site, and the lack of mysterious hard to track bugs. I really recommend trying it for a small project, but it's not for everyone.
Not parent but going forward I am hopping to get away without using any framework. Approach will be style all basic html elements and just use classes when there's no other way <button class="danger">.
I feel latest developments in css (especialy grid, flexbox...) make a lot of thing that where really useful before not needed anymore.
On the other hand I think this articles are a bit clickbaithy. Yest you can have a very small stylesheet but are you sure you don't want to style your form components? not having more than one type of button. Not dealling with navigation for both desktop and mobile?
I can make a 0 byte stylesheet for a empty body page and that's the perfect amount of css that page will need but has 0 usefullness in the real world.
> Approach will be style all basic html elements and just use classes when there's no other way <button class="danger">. I feel latest developments in css (especialy grid, flexbox...) make a lot of thing that where really useful before not needed anymore.
Thats the endgame. Style the html elements rather than introducing classes for every frigging thing. Reserve classes for special purposes.
This article was just an introductory piece. I wanted to show that a majority of what non-tech/non-design people perceive about the website can be achieved in a very small amount of CSS.
My point was to move away from class based styling as much as possible.
CSS classes like "hover:bg-blue-dark" clutter the markup and if you have generated or user provided text in your website, things start to look out of place very soon.
That being said, tailwindcss seems to be a really great project for people who are building a website quickly and without major changes in structure.
I believe the criticism was fair here. The author specifically used "339 bytes" on the headline which implies a certain level of precision. Being orders of magnitude away from the claimed file size is not excusable. It just feels like click bait. Not counting imported CSS is simply wrong here. I can have a full-featured responsive CSS framework in <50 bytes if I @import bootstrap.css
`font-family: -apple-system,system-ui,BlinkMacSystemFont,"Segoe UI",Roboto,"Helvetica Neue",Arial,sans-serif`
It'd remove the unnecessary font and still look good.