Live data from Hacker News

Hell Yes CSS

wizardzines.com

81–90 of 120 posts

Re: Hell Yes CSS

#81
post #67

Earlier quoted context omitted.

This is more a failure of the tutorials than of CSS itself though. CSS has a pretty simple and elegant core. You just have to understand the problems it was designed to solve. - Readable documents at any screen dimensions or resolution (i.e. you should not need to scroll horizontally back and forth to read each line just because you have a smaller screen.) - Incremental rendering - the document could be rendered as t…

> CSS has a pretty simple and elegant core. Where can I read about this - has someone written "CSS: the good parts", for example?

"box model" is the term to google.

Re: Hell Yes CSS

#82
post #25

So, I’m an experienced backend dev, who only occasionally dabbles in frontend. And whenever I do, my CSS experience is basically: https://media1.giphy.com/media/13FrpeVH09Zrb2/giphy.gif I’d like to fix that, and learn CSS well. I’m not looking for a quick zine like this, more of an in-depth course, say roughly 5-10 hrs. Ideally free, but I’d pay if it’s good. Anyone have any favourites?

I'm actually working on this, releasing it in about a week or so (doing the final edits).

It's called "How To Debug CSS"[1], if you go through my post history, you'll get a good idea of the backstory behind it.

Essentially, what I'm trying to do is help developers like you (who are like me, or at least how I was), in that I knew CSS for a long time, but never really felt like I 'got it', in the same way that I 'got' many of the other aspects of web development.

I've now gotten to a point where this is almost the complete opposite. I now feel like I have gained a certain level of mastery over CSS. And most of it had to do with a simple change of perspective.

Here's an article I wrote as sort of a subset of the book, that covers a lot more about how you can truly start to get better at CSS, as a developer: https://planflow.dev/blog/how-to-get-better-at-css.

[1] - https://gumroad.com/l/Debbg/z823cp8 (I've added a pre-order discount code to the book for those interested).

Re: Hell Yes CSS

#83
post #79
post #67

Earlier quoted context omitted.

This is more a failure of the tutorials than of CSS itself though. CSS has a pretty simple and elegant core. You just have to understand the problems it was designed to solve. - Readable documents at any screen dimensions or resolution (i.e. you should not need to scroll horizontally back and forth to read each line just because you have a smaller screen.) - Incremental rendering - the document could be rendered as t…

I'm not convinced. Literally none of these 3 bullet points are problems with plain HTML since at least 1993 or so - it's responsive by default, incremental by default and user agents are free to zoom in or out at will by default.

But HTML doesn't say anything about how things need to be rendered / presented. It was never intended to do that.

All it does is mark the structure in a document. "This is a header", "this is a paragraph", "this is a quote". That's basically it. The "hypertext" part of HTML refers to the notion that it uses URI's that can be used to identify resources, and dereference them.

It's entirely up to the consumer of a HTML document to decide how it gets rendered. A browser engine comes with a layout component that determines how the constituent parts of a document need to be painted before they are actually painted on the canvas.

Browsers in a GUI come with a default CSS definition that will be used if the document doesn't reference a companion CSS stylesheet.

Moreover, a browser doesn't have to be a GUI browser. What about text browsers on the command line?

I'll give you an example:

This is the hard coded default style definition of the Lynx browser when running through curses:

https://github.com/kurtchen/Lynx/blob/8b3a9d48dc6737e2062c56...

And this is the parser that will parse whatever limited user CSS is provided, as it is a text browser.

https://github.com/kurtchen/Lynx/blob/8b3a9d48dc6737e2062c56...

CSS was exactly designed to solve those 3 problems and much more.

The separation of structure and presentation is by design. Why? Because HTML and CSS never were intended to be used as tools for building "Rich Web Applications". They were originally intended to render hypertext and static web pages.

As it happened, the world wanted rich, interactive, animated web applications. And it needed technology to build such complex applications. Web technologies have evolved over 30 years to get to that point. Remember Flash? Java applets? Silverlight? Those were all attempts to do what HTML and CSS didn't do. Until the big vendors who came to dominate the browser market expanded on what HTML, CSS offers, and build new API's into their browsers that allow for exactly that.

There's nothing wrong with wanting to build rich web applications, and trying to leverage these affordances. But if you get hit by the limits of what web technologies have to offer in terms of maintainability, performance and what not, that's because you're still building on top of a historical foundation of basic principles that was never intended to be used in ways that it is used today, 30 years into the future.

Re: Hell Yes CSS

#84
post #79
post #67

Earlier quoted context omitted.

This is more a failure of the tutorials than of CSS itself though. CSS has a pretty simple and elegant core. You just have to understand the problems it was designed to solve. - Readable documents at any screen dimensions or resolution (i.e. you should not need to scroll horizontally back and forth to read each line just because you have a smaller screen.) - Incremental rendering - the document could be rendered as t…

I'm not convinced. Literally none of these 3 bullet points are problems with plain HTML since at least 1993 or so - it's responsive by default, incremental by default and user agents are free to zoom in or out at will by default.

Exactly! The default CSS browser stylesheet is a reverse engineering of how Netscape 2.0 rendered HTML. It had to be, since otherwise CSS wouldn't be backwards compatible, which would have killed it. But it was also a good starting point because browsers had to solve this exact problem: Layout text so it it readable regardless of screen dimensions.

Except that HTML rending was never specified (and varied significantly between browsers), so CSS basically codified the defacto HTML rendering in mainstream browsers, and then described this as the "browser style sheet".

CSS then allowed the author to override anything they wanted to change. But the default for anything not overriden was the browser style sheet, which was a sane default which adapted to all screen sizes.

Re: Hell Yes CSS

#85

Earlier quoted context omitted.

LOL IE :)

Anyone who learned CSS in the first 2000s decade was living in a world where designing a webpage was 5% getting the design down and working in Firefox, and 95% getting something to kinda sorta work in IE6. Just be glad we’re not trying to use “float” to make multi-column layouts anymore.

The trick was to know beforehand what would work and what wouldn't. That way you only had to spend a couple of hours in the end fixing small things that were broken in IE. A couple of well-placed "zoom: 1" could fix a lot.

Re: Hell Yes CSS

#86
post #79

Earlier quoted context omitted.

I'm not convinced. Literally none of these 3 bullet points are problems with plain HTML since at least 1993 or so - it's responsive by default, incremental by default and user agents are free to zoom in or out at will by default.

But HTML doesn't say anything about how things need to be rendered / presented. It was never intended to do that. All it does is mark the structure in a document. "This is a header", "this is a paragraph", "this is a quote". That's basically it. The "hypertext" part of HTML refers to the notion that it uses URI's that can be used to identify resources, and dereference them. It's entirely up to the consumer of a HTML…

HTML absolutely used to “say how things needed to be rendered”: with tags like B, I, FONT and so on. It was developed when documents were expected to be WYSIWYG-style markup (Word/WordPerfect, Latex, etc).

CSS was designed to strip that away only after people decided the future of hypertext should look more like XML. In doing so, they added the constraint that you should be able to get completely different outputs depending on which media you use to access the content - which at the time largely meant printing vs browsing.

But I agree that the whole thing was fundamentally document-based and has been bent out of shape in the subsequent decades. Once the content/presentation separation was abandoned, all bets were off. Now we are in a situation where content is driven by CSS properties via JS manipulation. We have the worst of both worlds. Ironically, this was enabled by something called XMLHttpRequest...

Re: Hell Yes CSS

#87

The amount of ignorance around CSS is astounding. CSS doesn’t control how a page looks, it controls how the browser ”flows” a sequence of boxes and text onto the page one by one. Block boxes are 100% wide, grow to fit their content, and stack vertically with other boxes. Inline boxes grow to fit their content, and flow into the same rows with other inline content. They cannot have margins or paddings like block boxes…

Some of these are self-inflicted wounds, though. For instance, why do you have to declare inline boxes to be inline-block before you can add padding to them? Perhaps just because of backwards compatibility, which could perhaps have been solved a bit more elegant.

Re: Hell Yes CSS

#88

I wrote a (much shorter) article in a similar vein a few years ago: https://css-tricks.com/css-is-awesome/ I find it fascinating (saddening, but fascinating) that so many programmers are so turned-off by CSS and find it so unintuitive. I almost want to set out on a research project to figure out why that is. My experience with it couldn't be more different. Here's one way of looking at CSS (which I didn't think of un…

I have a feeling people like to hate on CSS because making GUIs is hard and tedious work in general and introducing bugs is way easier than fixing them.

And since many applications nowadays run in your browser, people end up having to use CSS, thus getting blamed for the general pain it is to make a good GUI. I have used native GUI kits like Tk and Qt and found myself fiddling just about as much as I would with CSS.

YMMV of course.

Re: Hell Yes CSS

#89
post #78

CSS sucks and I don't think I'll ever be convinced otherwise.. it's just a mess of tricks you have to remember. The people that do spend time memorizing the tricks turn around and say "hey! look! it's awesome" but that doesn't convince me.

Modern CSS (e.g. flexbox and grid) is much less painful for layout, although the number and naming of properties makes it unpleasantly complex. Additionally, I'm still baffled why CSS gained transitions and animations as features. Now it's a jumbled mix of layout, styling, transitions and animation.

Despite the recent improvements to CSS, I agree that it is quite horrible to work with.

Re: Hell Yes CSS

#90
post #22
post #5

Earlier quoted context omitted.

Programming, I'm guessing. Page layout was its own weird world even before HTML came along, and the explosion of devices and use cases has made the domain much weirder. Put 25 years of CSS evolution on top of that and it's very much its own beast. As somebody who's done mostly back-end work lately, whenever I approach CSS it's one WTF after another. I keep hearing that it has settled down, though, so I am looking for…

My biggest tip of advice for anyone dipping into CSS is to focus on _why_ CSS is behaving the way it is instead of memorizing the different properties and selectors. Some principles in CSS won't ever go away, and they will even explain how the newer features that "settled down" CSS work and make then even easier to use.

Where do you recommend learning those principles?
Post reply on HN