4 ms·

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 des

by goto11 6y ago

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 the data arrives over the network. - The user should be able to increase the text size. The "normal flow" layout model is designed in such a way that these constraints are fulfilled by default. You can make a layout which only works on a screen of a particular size, or where the user have to scroll horizontally for every line, but you have to do it deliberately. I'd say the fundamentals of CSS is to understand the "normal flow" and the box model.

randomsearch 6y ago
> CSS has a pretty simple and elegant core. Where can I read about this - has someone written "CSS: the good parts", for example?
- goto11 6y ago
  Dunno if this exists. Maybe I should write one? The CSS 2 spec was actually a good introduction to the fundamentals, but it is 20 years out of data now, and the new modular specs does not works well as a tutorial.
- sanderdlm 6y ago
  I like this page: https://www.taniarascia.com/overview-of-css-concepts/ https://www.taniarascia.com/overview-of-css-concepts/
- nicoburns 6y ago
  "box model" is the term to google.
ivanche 6y ago
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.
- CaptArmchair 6y ago
  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/8b3a9d48dc6737e2062c5678a28e2829f05094d0/src/LYStyle.c#L480 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/8b3a9d48dc6737e2062c5678a28e2829f05094d0/src/LYStyle.c#L280 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.
weare138 6y ago
>This is more a failure of the tutorials than of CSS itself though. But therein lies the rub. Where do you go for authoritative information on CSS that doesn't involve digging through winding, terse technical specifications? That may be fine for developers making web browsers but becoming an 'expert' in CSS shouldn't be a requirement just to make a web page. Hell, even the experts struggle with it otherwise all web browsers would have consistent CSS rendering. A good example is centering an element in CSS. What's the right way to do it? There's a multitude of techniques with varying advantages and trade-offs. I first cut my teeth in web development in 2001 and we still don't have a simple, straight forward, codified way to accomplish this seemingly simple task. Instead we have an ever changing standard coupled with a dizzying amount of opinions on the matter and inconsistent browser support on mobile devices. We can't really blame the failure of tutorials when there's no clear authoritative reference point to work from.

by goto11 6y ago

randomsearch 6y ago

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

goto11 6y ago
Dunno if this exists. Maybe I should write one? The CSS 2 spec was actually a good introduction to the fundamentals, but it is 20 years out of data now, and the new modular specs does not works well as a tutorial.
sanderdlm 6y ago
I like this page: https://www.taniarascia.com/overview-of-css-concepts/ https://www.taniarascia.com/overview-of-css-concepts/
nicoburns 6y ago
"box model" is the term to google.

ivanche 6y ago

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.

CaptArmchair 6y ago
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/8b3a9d48dc6737e2062c5678a28e2829f05094d0/src/LYStyle.c#L480 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/8b3a9d48dc6737e2062c5678a28e2829f05094d0/src/LYStyle.c#L280 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.

weare138 6y ago

>This is more a failure of the tutorials than of CSS itself though. But therein lies the rub. Where do you go for authoritative information on CSS that doesn't involve digging through winding, terse technical specifications? That may be fine for developers making web browsers but becoming an 'expert' in CSS shouldn't be a requirement just to make a web page. Hell, even the experts struggle with it otherwise all web browsers would have consistent CSS rendering. A good example is centering an element in CSS. What's the right way to do it? There's a multitude of techniques with varying advantages and trade-offs. I first cut my teeth in web development in 2001 and we still don't have a simple, straight forward, codified way to accomplish this seemingly simple task. Instead we have an ever changing standard coupled with a dizzying amount of opinions on the matter and inconsistent browser support on mobile devices. We can't really blame the failure of tutorials when there's no clear authoritative reference point to work from.