Live data from Hacker News

339 Bytes of Responsive CSS

blog.koley.in

91–100 of 101 posts

Re: 339 Bytes of Responsive CSS

#91
post #48

Earlier quoted context omitted.

> It becomes hard when you need a grid CSS includes a grid. It works in every current browser.

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.

Re: 339 Bytes of Responsive CSS

#92
post #55

All this CSS minimalism reminds me of Dan Luu's post about Web Bloat: https://danluu.com/web-bloat/ His website is refreshingly light and fast, but that's still no excuse for Times New Roman. Maybe it's a retro irreverence thing.

This is not CSS minimalism, this is NO CSS. How that site is rendered on your device is the default look of any website in your browser before any CSS is applied. This site would actually profit a lot from this minimal CSS as the defaults are bad and on mobile they are even worse.

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.

Re: 339 Bytes of Responsive CSS

#95
post #83

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.

Re: 339 Bytes of Responsive CSS

#96
post #78
post #35

Earlier quoted context omitted.

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.

Re: 339 Bytes of Responsive CSS

#97
post #48
post #39

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.

> It becomes hard when you need a grid CSS includes a grid. It works in every current browser.

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.

Re: 339 Bytes of Responsive CSS

#98
post #91

Earlier quoted context omitted.

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.

Re: 339 Bytes of Responsive CSS

#99
post #81

Earlier quoted context omitted.

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.

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. If they do in your case, though, I understand.

So I guess following your point, accessibility should not be a thing, on or offline.

Re: 339 Bytes of Responsive CSS

#100
post #98
post #91

Earlier quoted context omitted.

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.
Post reply on HN