Algorithm? I see a design process but using the word algorithm to describe a CSS layout is a bit baffling to me. It's like creating a library of json snippets and calling it a json algorithm.
While these are really just boilerplate snippets for some common layouts, you can easily have an actual algorithm for CSS, too. For instance complex recipes/tricks for selecting just some of the nodes using different combinations of n-th child and sibling selectors are definitely algorithms, offering very generalized list of steps to follow to implement the logic on any number of elements.
I guess I can concede that. If you can compose an algorithm using a flow-based visual programming language I suppose you can consider a series of selectors an algorithm for applying styles, but by that logic every selector is an algorithm.
For me algorithm is simply an explanation/strategy of a list of steps needed to implement some logic and/or solve some problem. IMO it can even be a paper with IKEA instructions how to assemble a desk. Might not seem so, but if you'd tried to program a robot to do it, you'd probably call those steps the desk building algorithm. However I wouldn't call every css selector an algorithm on its own, just like print() function is not an algorithm - but if we have a routine to print say only odd numbers, that is definitely the (very simple) algorithm. Equally if you come up with a recipe how to combine css selectors into a series of rules to select e.g. N particular elements in an arbitrary list of DOM nodes, in my mind it's the full-blown algorithm too. Just my $.02 of course...
I’d agree using the word ‘algorithm’ feels a little misleading from the point of view of a programmer. But just to defend the glass half full point of view: it does feel reasonable to call the design processes in the article “recipes”, and once something is a “recipe”, “algorithm” feels more synonymous. Maybe the way to look at this article is that “algorithm” refers to what the person is doing, not to what the CSS is doing.
That’s not really what the article is saying, as far as I can tell. It describes the process for writing a CSS algorithm, not an algorithm for writing CSS. So in this use, the algorithm is something the CSS is doing, not the person.
I think the issue is that an algorithm is typically an unambiguously defined, imperative solution to a problem. It involves step by step instructions that happen in a certain order. Even though you can argue that these CSS patterns are clearly defined solutions to specific problems, the fact that there are no steps involved, no procedure, nothing imperative, makes it odd to call it an algorithm. There are other established words to use, like pattern, utility, hack.
There’s added confusion since CSS obviously involves actual algorithms, like how the engine calculates selector matching, specificity, layout, filters, etc.
I hear you and I think you're making a reasonable point, but just for fun, I'll double down on the devil's advocate defense.
I still think it's fair to include the person's activity in the broader idea of what constitutes an "algorithm" here, and I believe the article's language does support my interpretation.
First, the author explicitly acknowledges that "algorithm" is being somewhat misused compared to it's conventional programmer usage, and gives a bunch of reasons why she thinks it's still "useful" to co-opt this word. Some of the point behind this article is precisely to explain and defend her use of the world "algorithm" in this context. Language is fluid, and that's okay & sometimes fun & useful & interesting, right?
Also, there are steps listed in the article, such as defining boxes for layout, then naming them, then listing changes, then determining dependencies. That counts as step-by-step instructions, I think.
The author also said: "A CSS algorithm is well-defined declaration or set of declarations that produces a specific styling output." and "Phrased another way, a CSS algorithm is a very intentional and well thought-out utility pattern."
That's pretty explicitly including the design & thinking in the "algorithm" as I read it, don't you agree?
> an algorithm is typically an unambiguously defined, imperative solution to a problem
The English definition of an algorithm is closer to "a process or set of rules to be followed", and that's basically the extent of it. We programmers can use the word to mean more specific things if we want, but can't claim that the word always means the same thing to others as it does in our expert domain, or even that it always means the same thing in our domain.
I'd have to disagree with the qualification of "imperative", math algorithms and functional algorithms are widely accepted as algorithms by programmers. Unambiguous is always desirable, but can't be the definition. The words "process" and "rules" imply minimal ambiguity.
I have to admit, you're doing a pretty good job of playing the devil's advocate. I absolutely agree that any word can be used in creative and novel ways and to express new ideas, I just find this example to be much more confusing than useful. :)
FWIW, I've been trying to find examples of things conventionally called algorithms, but which are not in essence imperative (in the sense that there are multiple operations that must happen in a certain order - "procedural" is perhaps a more precise word than "imperative"), but I can't really find anything, so I would like to insist that it's one of the defining characteristics of an algorithm.
Thanks, and I agree with you too, css algorithms can be confusing for most of us and useful for some at the same time. ;) I’ll concede to order and dependency in an algorithm being important, you’re right, it doesn’t feel right to exclude.
Whats a good place to learn CSS for someone with programming experience?
I've been in my low-level C++ world for a long time and am pretty out of touch with GUI/Web things. I was writing some JavaFX code and saw it can be extended with CSS, but I don't know where to start. I'd also like to tweak the CSS on my webpage, but also don't know what's what. What I've found online is targeted towards people starting out coding with Javascript so it's very slow and hands on and doesn't step back and explain the big picture
+1 to HillRat's answer (especially hacking around in Codepen). On top of his, I want to plug the Mozilla Web Docs [0]. They're absolutely wonderful to reference for all your CSS needs, especially if you learn well from reading the docs. On top of that, they have excellent tutorials as well. I would consider checking out their one on CSS [1], you might find it easier to get through than an O'Reilly book.
A little unrelated but as someone who also loves their C++ and low-level programming I really enjoyed Lin Clark's articles on Firefox's Stylo [2] and WebRender [3], I think they do a great job of intuitively explaining the back-end behind CSS rendering, if that's of any interest to you.
These are great. Thanks for the breakdown - the whole webdev space has so much jargon that I probably should take the time to learn a bit of everything through the Mozilla tutorials and then pick up that book once I want some more
Eric Meyer’s CSS books for O’Reilly are unsurprisingly exhaustive. For incremental, hands-on work, try using Codepen to slowly work your way through bounded use cases (e.g., set up a pen and just work on styling buttons, or flex layout, or transforms); Codepen also lets you use preprocessors like SASS and LESS inline, so it’s a great way to get used to the various quirks of CSS and its toolchains without having to set up entire projects.
I learned a lot of CSS early in my career by experimentation, but everything that has been added to the language since css 3 I have learned from MDN, CSS Tricks[0], and the autocomplete in chrome dev tools.
I learned it from the CSS spec, and playing around with a text editor and a browser open. It is very much a "hands on" activity, but if you want to see "the big picture" then the introductory sections of the CSS spec are quite useful.
Now is a really good time to learn. This is because CSS has been done spectacularly badly to date and very few people have taken time to learn how to effectively use much of what has arrived in the last couple of years. Therefore you don't have to learn the bad stuff, you can get stuck in with the better ways of doing it.
I have watched the talk that goes with this post and I think that this is useful to better understand where Laura is coming from. She has gone deep reading the code for implementing the 'cascade' and you have to give her credit for getting people talking.
However, in the article there is some idea of solving responsiveness. There is a better starting point and it is this - CSS variables.
In the olden days people would have one chunk of common CSS and then media queries that would have other chunks of CSS in them. The better way is to only have CSS variables in media queries and then to have all the style declarations use the CSS variables. In this way you can have maintainable CSS where it is clear to see what changes.
An example, if you have an image in a figure then you might want it to appear on the right hand side in a desktop layout and full width on mobile. So in the root element of the CSS you can define --my-figure-grid-column as 1 and then in the media query for desktop you can then set the variable to 2. Then in the style rule for the image you can have grid-column: var(--my-figure-grid-column). If you review the code a few months later and decide you want the image on the left you can see what is going on and what you need to change. With old CSS you would probably decide to just bolt yet more style rules to the bottom with !important to hack it good.
CSS Grid is a good place to start, this is the new layout engine and it works in 97% of used browsers. If you start from content with sensible HTML5 elements instead of 'div soup' and make it responsive with CSS Grid and CSS variables then you will have as much fun as a kid with LEGO.
There are a few other things on starting out, one being to forget about pixels and percentages. Go with ems and 'vh/vw/vmin/vmax' instead. Document structure matters too, if you are using CSS Grid then you don't need the div tags or the spans. You also don't need the clutter of many classes added to every div. So maybe strip your webpage back to bare content, burn the existing CSS and any 'reset.css' type of files that are there for Internet Explorer 6 related reasons. Get the page structured with the HTML tags of header, main, footer, article, section, aside, nav, figure and the ones you know already for doing lists. Then get it looking good on all browsers with CSS Grid with layout problems solved with CSS variables. You can then move on to the more decorative things.
Don't waste your time... use clever css frameworks and solve the problem on spot... doesn't matter how nice your css code, your colleagues will mess it up quickly... let the intern fix it. ;)
A good general approach to problem solving that is not CSS specific -- prototype something that just works to get familiar with the problem space, then refactor/reiteratively improve the solution.
Why does sass have to be ‘compiled’ in 2019? It’s not like some heavy duty compilation is being performed. It should be as standard and supported as css.
When I do have to do any web gui work, I'm starting to lean toward Parcel because I can import SCSS/SASS, Less, or CSS right into the javascript/typescript file, and it will spit out web-usable CSS without configuration. Of course this only helps if you're including JS anyway. I don't know enough about the system to know if you can configure for just SASS. But that just returns to your problem, anyway.
Interestingly enough, LESS (a similar concept to SASS, though less powerful last time I looked at it) offers a JavaScript component to compile .less files that are included via <link rel="stylesheet/less">, though they do recommend that in production the files be pre-compiled.
“New ideas will come along, but they will extend CSS rather than replace it. I believe that the CSS code we write today will be readable by computers 500 years from now.” — Håkon Wium Lie, co-creator of CSS.
Athough I think CSS could be more than it is, I have never felt any need to use SCSS. Writing a complete new style for a typical blog costs me half a day with clever use of nesting, css variables and such.
The pain points usually stem from inconsistencies in browser implementations. Except for missing functionality like not beeing able to select a element who has no child of a given type I never really felt that it took longer than it had to (most of my time goes into deciding the design and not into wrangling with fine details of css).
I don't think CSS Nesting Level 3 is implemented anywhere (it only really got added last year [1]). And there are still ongoing discussions around it (e.g. media-queries [2]).
> But maybe I should check out SCSS?
Definitely, yes. There are quite a few things that would be wonderful to see in CSS:
- better, less verbose syntax for variables
- mixins and extends
- nesting
... I forget what else, as I haven't done frontend work in a while :)
Thanks, maybe nesting was the wrong word, I meant inheritance. SCSS nesting is super nice – althoughvone could argue it could be counted as syntactical sugar.
Algorithm? I see a design process but using the word algorithm to describe a CSS layout is a bit baffling to me. It's like creating a library of json snippets and calling it a json algorithm.
Should have seen it coming after “object oriented CSS”, “functional CSS” and “immutable CSS”, none of which has anything to do with OOP or FP.
What’s next? CSS data structures?
While these are really just boilerplate snippets for some common layouts, you can easily have an actual algorithm for CSS, too. For instance complex recipes/tricks for selecting just some of the nodes using different combinations of n-th child and sibling selectors are definitely algorithms, offering very generalized list of steps to follow to implement the logic on any number of elements.
I guess I can concede that. If you can compose an algorithm using a flow-based visual programming language I suppose you can consider a series of selectors an algorithm for applying styles, but by that logic every selector is an algorithm.
For me algorithm is simply an explanation/strategy of a list of steps needed to implement some logic and/or solve some problem. IMO it can even be a paper with IKEA instructions how to assemble a desk. Might not seem so, but if you'd tried to program a robot to do it, you'd probably call those steps the desk building algorithm. However I wouldn't call every css selector an algorithm on its own, just like print() function is not an algorithm - but if we have a routine to print say only odd numbers, that is definitely the (very simple) algorithm. Equally if you come up with a recipe how to combine css selectors into a series of rules to select e.g. N particular elements in an arbitrary list of DOM nodes, in my mind it's the full-blown algorithm too. Just my $.02 of course...
I’d agree using the word ‘algorithm’ feels a little misleading from the point of view of a programmer. But just to defend the glass half full point of view: it does feel reasonable to call the design processes in the article “recipes”, and once something is a “recipe”, “algorithm” feels more synonymous. Maybe the way to look at this article is that “algorithm” refers to what the person is doing, not to what the CSS is doing.
That’s not really what the article is saying, as far as I can tell. It describes the process for writing a CSS algorithm, not an algorithm for writing CSS. So in this use, the algorithm is something the CSS is doing, not the person.
I think the issue is that an algorithm is typically an unambiguously defined, imperative solution to a problem. It involves step by step instructions that happen in a certain order. Even though you can argue that these CSS patterns are clearly defined solutions to specific problems, the fact that there are no steps involved, no procedure, nothing imperative, makes it odd to call it an algorithm. There are other established words to use, like pattern, utility, hack.
There’s added confusion since CSS obviously involves actual algorithms, like how the engine calculates selector matching, specificity, layout, filters, etc.
I hear you and I think you're making a reasonable point, but just for fun, I'll double down on the devil's advocate defense.
I still think it's fair to include the person's activity in the broader idea of what constitutes an "algorithm" here, and I believe the article's language does support my interpretation.
First, the author explicitly acknowledges that "algorithm" is being somewhat misused compared to it's conventional programmer usage, and gives a bunch of reasons why she thinks it's still "useful" to co-opt this word. Some of the point behind this article is precisely to explain and defend her use of the world "algorithm" in this context. Language is fluid, and that's okay & sometimes fun & useful & interesting, right?
Also, there are steps listed in the article, such as defining boxes for layout, then naming them, then listing changes, then determining dependencies. That counts as step-by-step instructions, I think.
The author also said: "A CSS algorithm is well-defined declaration or set of declarations that produces a specific styling output." and "Phrased another way, a CSS algorithm is a very intentional and well thought-out utility pattern."
That's pretty explicitly including the design & thinking in the "algorithm" as I read it, don't you agree?
> an algorithm is typically an unambiguously defined, imperative solution to a problem
The English definition of an algorithm is closer to "a process or set of rules to be followed", and that's basically the extent of it. We programmers can use the word to mean more specific things if we want, but can't claim that the word always means the same thing to others as it does in our expert domain, or even that it always means the same thing in our domain.
I'd have to disagree with the qualification of "imperative", math algorithms and functional algorithms are widely accepted as algorithms by programmers. Unambiguous is always desirable, but can't be the definition. The words "process" and "rules" imply minimal ambiguity.
I have to admit, you're doing a pretty good job of playing the devil's advocate. I absolutely agree that any word can be used in creative and novel ways and to express new ideas, I just find this example to be much more confusing than useful. :)
FWIW, I've been trying to find examples of things conventionally called algorithms, but which are not in essence imperative (in the sense that there are multiple operations that must happen in a certain order - "procedural" is perhaps a more precise word than "imperative"), but I can't really find anything, so I would like to insist that it's one of the defining characteristics of an algorithm.
Thanks, and I agree with you too, css algorithms can be confusing for most of us and useful for some at the same time. ;) I’ll concede to order and dependency in an algorithm being important, you’re right, it doesn’t feel right to exclude.
Yeah, i personally thought this post would be about actually designing algorithms that determine where the HTML elements are rendered on the screen.
A heuristic maybe?
"Styleless"
Whats a good place to learn CSS for someone with programming experience?
I've been in my low-level C++ world for a long time and am pretty out of touch with GUI/Web things. I was writing some JavaFX code and saw it can be extended with CSS, but I don't know where to start. I'd also like to tweak the CSS on my webpage, but also don't know what's what. What I've found online is targeted towards people starting out coding with Javascript so it's very slow and hands on and doesn't step back and explain the big picture
+1 to HillRat's answer (especially hacking around in Codepen). On top of his, I want to plug the Mozilla Web Docs [0]. They're absolutely wonderful to reference for all your CSS needs, especially if you learn well from reading the docs. On top of that, they have excellent tutorials as well. I would consider checking out their one on CSS [1], you might find it easier to get through than an O'Reilly book.
A little unrelated but as someone who also loves their C++ and low-level programming I really enjoyed Lin Clark's articles on Firefox's Stylo [2] and WebRender [3], I think they do a great job of intuitively explaining the back-end behind CSS rendering, if that's of any interest to you.
[0] https://developer.mozilla.org/en-US/
[1] https://developer.mozilla.org/en-US/docs/Learn/CSS
[2] https://hacks.mozilla.org/2017/08/inside-a-super-fast-css-en...
[3] https://hacks.mozilla.org/2017/10/the-whole-web-at-maximum-f...
These are great. Thanks for the breakdown - the whole webdev space has so much jargon that I probably should take the time to learn a bit of everything through the Mozilla tutorials and then pick up that book once I want some more
Eric Meyer’s CSS books for O’Reilly are unsurprisingly exhaustive. For incremental, hands-on work, try using Codepen to slowly work your way through bounded use cases (e.g., set up a pen and just work on styling buttons, or flex layout, or transforms); Codepen also lets you use preprocessors like SASS and LESS inline, so it’s a great way to get used to the various quirks of CSS and its toolchains without having to set up entire projects.
I learned a lot of CSS early in my career by experimentation, but everything that has been added to the language since css 3 I have learned from MDN, CSS Tricks[0], and the autocomplete in chrome dev tools.
[0] https://css-tricks.com/
I learned it from the CSS spec, and playing around with a text editor and a browser open. It is very much a "hands on" activity, but if you want to see "the big picture" then the introductory sections of the CSS spec are quite useful.
I'm sure you'll get over the basics pretty quick. After that, check this out http://learnlayout.com/.
I've got two nice books.
https://www.packtpub.com/web-development/professional-css3
https://www.packtpub.com/web-development/responsive-web-desi...
Now is a really good time to learn. This is because CSS has been done spectacularly badly to date and very few people have taken time to learn how to effectively use much of what has arrived in the last couple of years. Therefore you don't have to learn the bad stuff, you can get stuck in with the better ways of doing it.
I have watched the talk that goes with this post and I think that this is useful to better understand where Laura is coming from. She has gone deep reading the code for implementing the 'cascade' and you have to give her credit for getting people talking.
However, in the article there is some idea of solving responsiveness. There is a better starting point and it is this - CSS variables.
In the olden days people would have one chunk of common CSS and then media queries that would have other chunks of CSS in them. The better way is to only have CSS variables in media queries and then to have all the style declarations use the CSS variables. In this way you can have maintainable CSS where it is clear to see what changes.
An example, if you have an image in a figure then you might want it to appear on the right hand side in a desktop layout and full width on mobile. So in the root element of the CSS you can define --my-figure-grid-column as 1 and then in the media query for desktop you can then set the variable to 2. Then in the style rule for the image you can have grid-column: var(--my-figure-grid-column). If you review the code a few months later and decide you want the image on the left you can see what is going on and what you need to change. With old CSS you would probably decide to just bolt yet more style rules to the bottom with !important to hack it good.
CSS Grid is a good place to start, this is the new layout engine and it works in 97% of used browsers. If you start from content with sensible HTML5 elements instead of 'div soup' and make it responsive with CSS Grid and CSS variables then you will have as much fun as a kid with LEGO.
There are a few other things on starting out, one being to forget about pixels and percentages. Go with ems and 'vh/vw/vmin/vmax' instead. Document structure matters too, if you are using CSS Grid then you don't need the div tags or the spans. You also don't need the clutter of many classes added to every div. So maybe strip your webpage back to bare content, burn the existing CSS and any 'reset.css' type of files that are there for Internet Explorer 6 related reasons. Get the page structured with the HTML tags of header, main, footer, article, section, aside, nav, figure and the ones you know already for doing lists. Then get it looking good on all browsers with CSS Grid with layout problems solved with CSS variables. You can then move on to the more decorative things.
Don't waste your time... use clever css frameworks and solve the problem on spot... doesn't matter how nice your css code, your colleagues will mess it up quickly... let the intern fix it. ;)
I was expecting something along the lines of https://news.ycombinator.com/item?id=10734966 or https://news.ycombinator.com/item?id=2300836, or a discussion on how to implement CSS in a browser, but this article seems to be really more about "algorithms for writing CSS".
A good general approach to problem solving that is not CSS specific -- prototype something that just works to get familiar with the problem space, then refactor/reiteratively improve the solution.
What a waste.
To quote: «You call throwing dynamite around martial arts?»
How about... _not_ writing CSS algorithms?
I'm mostly joking, this is neat.
Why does sass have to be ‘compiled’ in 2019? It’s not like some heavy duty compilation is being performed. It should be as standard and supported as css.
No comment on the core question, but:
When I do have to do any web gui work, I'm starting to lean toward Parcel because I can import SCSS/SASS, Less, or CSS right into the javascript/typescript file, and it will spit out web-usable CSS without configuration. Of course this only helps if you're including JS anyway. I don't know enough about the system to know if you can configure for just SASS. But that just returns to your problem, anyway.
Interestingly enough, LESS (a similar concept to SASS, though less powerful last time I looked at it) offers a JavaScript component to compile .less files that are included via <link rel="stylesheet/less">, though they do recommend that in production the files be pre-compiled.
http://lesscss.org/usage/
downvoted, because..?
I stand by my statement. JavaScript has progressed, and styling should too.
Modern JavaScript has progressed.. by compiling in more features. CSS is no different.
I didn't downvote you, but in answer to your question: compiling first means it works without javascript.
“Make CSS interesting/here’s a methodology blah blah”.... Sets up SCSS.
Can we just agree that current CSS is a mistake and bring more of SCSS into it?
“New ideas will come along, but they will extend CSS rather than replace it. I believe that the CSS code we write today will be readable by computers 500 years from now.” — Håkon Wium Lie, co-creator of CSS.
Athough I think CSS could be more than it is, I have never felt any need to use SCSS. Writing a complete new style for a typical blog costs me half a day with clever use of nesting, css variables and such.
The pain points usually stem from inconsistencies in browser implementations. Except for missing functionality like not beeing able to select a element who has no child of a given type I never really felt that it took longer than it had to (most of my time goes into deciding the design and not into wrangling with fine details of css).
But maybe I should check out SCSS?
> with clever use of nesting
I don't think CSS Nesting Level 3 is implemented anywhere (it only really got added last year [1]). And there are still ongoing discussions around it (e.g. media-queries [2]).
> But maybe I should check out SCSS?
Definitely, yes. There are quite a few things that would be wonderful to see in CSS:
- better, less verbose syntax for variables
- mixins and extends
- nesting
... I forget what else, as I haven't done frontend work in a while :)
[1] https://github.com/w3c/csswg-drafts/issues/2701#issuecomment...
[2] https://github.com/tabatkins/specs/issues/56
Thanks, maybe nesting was the wrong word, I meant inheritance. SCSS nesting is super nice – althoughvone could argue it could be counted as syntactical sugar.
Do you have a realtime workflow for scss?