17 ms·

Relearn CSS layout

985 points by aarohmankad 7y ago

aarohmankad 7y ago
Saw this awesome project on Lobsters. I went ahead and ported these components to generalized, composable Styled Components. There's also an npm package at `every-layout`. https://github.com/aarohmankad/every-layout https://github.com/aarohmankad/every-layout
- WA 7y ago
  You mean "React Components" right? Nice effort, but please mention that these components are supposed to work with React. If we now use the word "Component" as a synonym for React, you make it look like there are no other frameworks than React.
  - osdiab 7y ago
    No, he meant Styled Components, a popular library for styling React components.
    - WA 7y ago
      I see, didn’t know about this. Thanks for pointing it out!
codedokode 7y ago
Poor quality articles. They use flexbox and provide no fallback for older browsers. They could use at least non-responsive layout for desktop resolution for older browsers. Probably the reason why they didn't do it is lack of knowledge of CSS.
- majewsky 7y ago
  Flexbox has been supported by all browsers for years now, even by IE11. What on earth do you need to support if you cannot use flexbox?
  - codedokode 7y ago
    Caniuse says that IE11 has a lot of bugs regarding flexbox. Firefox supports flexbox only since 2013-2014. So it would make sense to add a simple non-responsive fallback for older browsers. Also, if I remember correctly, the default browser in Windows 7 is IE9. It makes sense to support default browser in the most popular desktop OS. Some of older browsers, released in 2012-2014 support flexbox only with vendor prefixes, but the article doesn't has rules with prefix. As frontend devs tend to copy the code without much thinking, we cannot expect that they will add the prefixes or fallback code themselves. So it will be author's responsibility for web sites being less accessible in different browsers.
    - mixmastamyk 7y ago
      Win7 and IE9 are both EOL in six months. Makes sense to drop in new articles.
      - codedokode 7y ago
        HTML/CSS was designed to be forward/backward compatible and not to be written only for version of Safari installed on dev's macbook. This is against the spirit of HTML.
        jrochkind1 7y ago
        If I understand right, you are suggesting it is "against the spirit of HTML" to write CSS that isn't backwards compatible... infinitely? You have to draw the line somewhere, right? An ancient enough browser won't support CSS at all. Using only CSS that would be supported by a, say, year 2005 browser would also be pretty limiting. You can choose to do that if you want, but I think your opinion about the "spirit" is a minority one.
        CamperBob2 7y ago
        That ship sailed the day people first started using HTML for page layout in general. The spirit of HTML was not adequate to meet requirements, so the spirit has been upgraded. Pray all you want, it's going to be upgraded further.
- chiefalchemist 7y ago
  Andy Bell? Lacks CSS knowledge? That's a bit over the top.
- proyb2 7y ago
  You may be surprise to know who is Heydon who co-author in the article. https://inclusive-components.design/ https://inclusive-components.design/ IE11 is meant for supporting legacy sites and Microsoft doesn’t recommend consumers to use it. It make sense to work on Grid and Flexbox for new sites.
- robdachshund 7y ago
  You do realize that most projects do not target ie11 whatsoever right? I do mainly ecommerce and private web apps for clients. I have never needed to worry about if one of my users is on any version of internet explorer. If you are building some enterprise platform for the government or something, sure. But basic sites and apps are not trying to attract 90 year olds on xp using ie6. I'm not going to avoid using a css feature that is supported by modern browsers that makes my job much much easier.
- plausibilities 7y ago
  Maybe their target audience doesn't primarily consist of entry-level devs relegated to maintaining legacy eCommerce web properties and back-office portal/intranet systems?
vedantroy 7y ago
Out of curiosity, why doesn't the stack layout use flexbox? It seems like flexbox is the perfect fit for such a layout.
- chiefalchemist 7y ago
  Because it's a just a simple stack. The intent is concistent margins between siblings within the wrapper. What came to mind were paragraphs. Or perhaps images. Or both?
- codedokode 7y ago
  Display: block fits better because it has been around for more than 15 years unlike flexbox. And flexbox has no advantages in this case.
- have_faith 7y ago
  Margins of flex child elements won't collapse automatically like regular elements. It can be solved but it would be unnecessarily complex for the simplicity of the layout.
- sureaboutthis 7y ago
  Flex is great for one directional layout within a box. It is not great for two dimensions which most layout is concerned with.
  - nhooyr 7y ago
    The stack is not two dimensional.
    - sureaboutthis 7y ago
      Has nothing to do with what we're talking about.
- threehams 7y ago
  If other browsers besides Firefox add support for the gap property, Flexbox will be perfect for this. The owl approach has some subtle issues, like not taking into account elements which show/hide based on breakpoint.
codedokode 7y ago
The code examples are overengineered. For example, the code generator for stack uses rem units and CSS variables, while it could be written without them and have better cross browser support (and the code would be easier to read and maintain in long-term perspective). The author just wants to use modern CSS features without clear rationale for this. Rem units can cause issues in long term. For example, imagine if a sidebar widget is coded using rems. When later the main font size is changed, margins within widget will change its size, although the font size in it is fixed and didn't change. There are cases when rem is useful and there are cases when it is not, but the author doesn't give a choice and doesn't explain it. He just uses his authority to push his personal preferences to frontend developers who tend to copy the code from tutorials without much thinking. I recommend using pixels for projects that are going to be maintained and developed in the long term.
- Tomte 7y ago
  I find your counter-argument against rem units very weak. What are cross browser concerns here? Why should he even mention the possibility that someone might "fix" an elements font-size? Sure, the author doesn't explain all of CSS and all of UX/UI in an article focussed on a single issue. That's not a mistake. Your px recommendation is... strange. The article is one of those "newer" CSS articles that care a lot about responsiveness. You seem not to care. Fine, but I guess you're in the minority there. Your insult against front-end developers (in both your comments!) is simply childish, and frankly, it seems you just have an axe to grind with the author(s).
- jffry 7y ago
  > There are cases when rem is useful and there are cases when it is not, but the author doesn't give a choice and doesn't explain it. and > I recommend using pixels for projects that are going to be maintained and developed in the long term. Directly after lambasting the author for failing to elaborate, perhaps you could go into more depth yourself?
  - codedokode 7y ago
    A website that is maintained in a long term will be worked on by many people, and CSS will become quite large and complicated. So using the simple constructs like pixel units is better than using rems that create implicit dependence on main font size. This way there are less chances to break something in one place when editing code in other place. The same is about CSS variables. An example with one variable might look nice. But what if your code has hundreds of variables? It would take more time to understand how they are related and how do I change the size of this button without breaking something on another page.
ctidd 7y ago
I've written a series of very similar articles, and seeing as some of the ones in this site don't seem to be available yet, and otherwise as another point of view, they may be of interest to anyone looking at this: https://ctidd.com/2017/css-ui-patterns/content https://ctidd.com/2017/css-ui-patterns/content
have_faith 7y ago
The knowledge contained in the articles is very good but I got the feeling that it was written for an audience that already undertands the problems being solved. The Stack for instance is written in a language that only really makes sense if you've spent a lot of time with CSS and contains some extraneous paragraphs. I only mention this as the problems and solutions being explored are very valuable to learn but I think it could be written simpler and more succinctly so that meaning isn't lost for new-comers. I'd be happy to contribute if it was open to suggestions.
- gary__ 7y ago
  Bear in mind the tutorial is prefixed "Relearn..." Though I'd class myself as a "full stack developer" css for a long time was the 2nd class citizen, with most of my time spent on learning to use front end frameworks in their idiomatic way, the "it depends" peculiarities of SQL and RDBMSs and making inroads on the vast tomb that represents architectuliary sound back ends. So an article focussed on improving my "it's only css but it works" knowledge is one of the best things I've seen on HN in quite some time :)
  - wolco 7y ago
    A good full stack developer should have double the salary of a frontend/backend developer. Do you find this is the case? You need to be an expert at both roles plus have a third skill connecting them together.
    - gary__ 7y ago
      I think there's often a leeway given to the full stack dev that they have strengths and limitations. I haven't got to the point where I could compete with the true / good front end dev with my skills. Even at the backend you have the application backend (c# or whatever) and then sql/rdbms. If you are that good perhaps you deserve thrice the pay by this logic ;). Jokes aside, at the last good company I worked for where I knew other people's pay, I was compensated for the entirety of my skills compared to the good front end dev. We earned the same, and I was quite happy with that. Jack of all trades...
Theodores 7y ago
There is more than way to do all of these layouts. I don't have time to learn all of them, I just want my content to look great on all devices. I also want to stick to the specifications of HTML as it applies to all the browsers that do HTML5 - so no Internet Explorer. Sticking to the specs means no hacks and the likelihood that someone can make sense of my code in ten years time and not think 'why did they do this?'. For this reason I will be sticking with CSS Grid. CSS Grid is supported in all HTML5 browsers, so that means everything except the depreciated Internet Explorer. To get my CSS Grid versions to work I will also be using CSS Variables defined in media queries to make things responsive. I don't need to have lots of fixed breakpoints as I use fonts that scale in such a way that lines don't get too long to read on really big screens. For the CSS variables I have fallbacks which are the desktop defaults. So although 'mobile first' I can get a deluxe mobile experience but code for desktop in the first instance. With pseudo classes I can add icons, usually Unicode symbols or SVG, SVG defined in CSS variables. Since I can do this with CSS Grid and only have Internet Explorer be 'of concern', I can write HTML5 with no superfluous markup. That means no div, span or even class attributes. I have got out of the mindset of using container wrappers for content and just putting neat content where it needs to go using CSS Grid. You could look at my HTML and think I had just swapped the div for article, aside and section. Or for figure. Or for main, header and footer. But that is not the case, I find that if I am using the right elements and pay attention to the structure of my content it just naturally styles itself with CSS Grid, no additional markup needed. Also not needed are clever things with calc. If I find myself doing that then it is a sign that I have got it wrong and that there is a simpler solution I have overlooked. I also rarely use pixels. It is ems or viewer units all the way, again no need to think of what a pixel actually is. I find that writing HTML and styling it without the hacks makes my code pretty alien compared to how the rest of the world is doing it. Anyone can make stuff complicated for reasons of backward compatibility, keeping it concise and simple is a different craft. For the above reasons I am disappointed by these layout modules, a lot of work has gone into it but at times we need to question what we take for granted. Everything is a div. I look at the examples and see that if, e.g., the image is put in a figure and given a figcaption then the structure is there for it to effortlessly be given layout with CSS Grid, no container elements needed. At some stage we need to stop looking at content as placeholder examples and stop using generic containers.
sergiotapia 7y ago
>https://every-layout.dev/layouts/cluster/ https://every-layout.dev/layouts/cluster/ >The Cluster layout is available in the full version of Every Layout, which is still in production. All of the currently available layouts are marked "read now" in the index page. where is production? I can't find it
- dmitriid 7y ago
  It's still in production meaning: they are not available yet, they are being written.
  - galaxyLogic 7y ago
    Another way of saying that would be that they are still in "development"
gary__ 7y ago
This is great. I would prefer that browser compatability is mentioned, for my own purposes that would be IE11. Perhaps set a baseline of what browsers are considered in the intro and then highlight deviance as it occurs.
- deleted 7y ago
  [deleted]
- andrei_says_ 7y ago
  Suzy grids 2 is an amazing tool for ie11 and everything above it. So I can use one codebase for everything. Yes, it is float based but my code is at the correct level of abstraction.
victor106 7y ago
What’s the best resource (book, videos etc.,) to learn css these days?
- runarberg 7y ago
  MDN: https://developer.mozilla.org/en-US/docs/Learn/CSS https://developer.mozilla.org/en-US/docs/Learn/CSS
- danbruc 7y ago
  It's probably not for everyone but I just read the specification [1] last week. It is probably also worth noting that I did this to get a better understanding of some details and not for initially learning CSS. But those are mostly easy to read specifications and I think one could use them to initially learn CSS. CSS level 1 is pretty short but will still teach you a big chunk of the fundamentals of current CSS even though it is more than 20 years old. After that you can focus on the changes and additions in later versions - those newer specifications are a lot more technical and precise and cover a lot more features, so they are also longer and less fun to read from cover to cover. [1] https://www.w3.org/Style/CSS/current-work https://www.w3.org/Style/CSS/current-work
  - macando 7y ago
    That was brave. I learned how the box model works from the specification.
  - rimliu 7y ago
    I commend you. I am with Kyle Simpson (of the You Don't Know JavaScript fame) here—too often people don't even try to learn about the stuff they are using and are surprised by the behaviour which is clearly stated in the specification. This is true for JavaScript, but this is especially true for CSS. I think it is one of the least respected technology, devs don't spend much time and effort in learning it and then complain about it being a mess and not making sense. So if anyone is tired at throwing stuff at the wall and seeing what sticks just go and read the specs. It's much easier now than back in the days of IE5/6, no grid and no flexbox.
- 7y ago
meerita 7y ago
To me this way to CSS development is outdated. I will never program like this anymore. I only do functional/utilitarian CSS.
- vast 7y ago
  Pardon?
- emmanueloga_ 7y ago
  NOTE: I think this refers to the approach implemented by libraries like: * https://tailwindcss.com/ https://tailwindcss.com/ * http://tachyons.io/ http://tachyons.io/
  - meerita 7y ago
    Also: * http://minid.net/2019/04/07/the-css-utilitarian-methodology/ http://minid.net/2019/04/07/the-css-utilitarian-methodology/ * https://github.com/meerita/utilcss https://github.com/meerita/utilcss
- GoToRO 7y ago
  can you elaborate? (also fotolog is not found)
  - meerita 7y ago
    Yes, fotolog.com doesn't exist anymore but I would gladly elaborate. (full explanation here: http://minid.net/2019/04/07/the-css-utilitarian-methodology/ http://minid.net/2019/04/07/the-css-utilitarian-methodology/) resume: why go with an OO architecture, when you can use inmutable classes and never again repeat the same properties in your CSS files. In the end, you end up developing faster and you can mantain code easily without having to build the entire UI arquitecture in the CSS. CSS was created to separate style from the content, but also, because back then, HTML wasn't built like we do today with frameworks. Now that we use reactive HTML we can just print inline CSS, but that is a problem, so the functional CSS comes better.
- ry_ry 7y ago
PyroLagus 7y ago
I'm not sure if the creators will read this, but on https://every-layout.dev/rudiments/axioms/ https://every-layout.dev/rudiments/axioms/ > At the time of conceiving the axiom, you make not have pictured this specific visual effect. I'm pretty sure it should be "may" instead of "make".
sktrdie 7y ago
To me an evident thing in UI development is that separating stylesheet from layout isn't really a thing anymore and the benefits of this separation aren't really that clear. Things like SwiftUI and React are showing that declarative UIs can be built by tying the style to the layout and allow for much better accessibility, tooling, overall thinking of how UIs work. So to me CSS feels a bit outdated since big companies are definitely moving away from this separation. How does HN feel about this?
- Bahamut 7y ago
  This is not quite necessarily true - I work at a tech giant and we've opted for using scss still & are quite happy with our choice.
  - sktrdie 7y ago
    Is your company actually building a platform for developers to build apps? Because that's what Apple is doing and they shifted away from using paradigms like CSS.
    - ohrus 7y ago
      CSS is not a paradigm. Whatever workflow you have for styling your pages and apps, it's all CSS in the end.
      - orf 7y ago
        CSS can certainly be described as a paradigm. It's a model you follow to style things on the web. It also doesn't matter if it's all CSS in the end. At one particular end it's all manipulating assembly instructions, but I wouldn't call styling pages writing assembly. That is to say the underlying model or paradigm (styling in this case) doesn't really matter if you build an abstraction on top of it that hides that paradigm.
        ohrus 7y ago
deanclatworthy 7y ago
Having been doing full-stack for over 15 years now, I have never seen the owl selector before. It's almost a perfect solution to a problem I regularly have. A quick google didn't reveal any browser support for it though. Anyone got a resource for that? I can see that the adjacent selector is supported on 98% of global browsers, but I would not be surprised if there were some issues combining it with * +
- tracker1 7y ago
  It's worth noting that * is incredibly inefficient, especially near the front of your selector, because of how the browsers generally handle element styling. It may be better now than in the past, but it's best to avoid it for the most part.
razvandh 7y ago
started reading some of the ideas and got put-off almost immediately. 'margin-top'? the owl-selector? Really? Why do we keep making our life more difficult than it should be? CSS is such a beautiful and interesting tool, yet we still decide to misuse it in trying to be too smart. ( margin-top: you start dealing with parents inheriting the margin - which is an old quirk of CSS - it's a side-effect you need to control, so the usage of margin-top should always be avoided and margin-bottom should be the preferred solution owl selector: performance implications - it's fairly bad from a performance POV to use it. Also, we live in a world where we have control over how the layout is generated, we should avoid using generic selectors Source: I've been doing frontend and focused on CSS for over 10 years )
- Atomskun 7y ago
  > so the usage of margin-top should always be avoided Not really if you consider sibling layouts, e.g.: https://matthewjamestaylor.com/css-margin-top-vs-bottom https://matthewjamestaylor.com/css-margin-top-vs-bottom > owl selector: performance implications - it's fairly bad from a performance POV to use it. Arguing about "CSS performance" is futile when the real cause of bloatedness is mostly JavaScript these days (also: http://alistapart.com/article/axiomatic-css-and-lobotomized-owls http://alistapart.com/article/axiomatic-css-and-lobotomized-...). The owl-selector can actually be quite elegant, but becomes a burden if you have lots of side-by-side blocks (which would always need to set their margin-top to 0).
  - ry_ry 7y ago
    I was suprised the degree to which selector performance is a negligible overhead in normal use these days. Was browsing through the docs for some Vue+CSS library or another recently, and the author had done quite a lot of research into this, was interesting. They were heavily using the square bracket html-attribute selector notation, although I'm not sure if it performs better now, or if modern processors are just that much faster.
miki123211 7y ago
This website is one of the accessiblest things (for screen readers) out there. I have never seen alt text for layout images. This is well beyond amazing.
sam0x17 7y ago
Uh huh, what about "the vertically centered div" and the ever important "span vertically centered within the parent"
sheriffderek 7y ago
"Web browsers helpfully apply default CSS styles..." Totally disagree with the idea that this is 'helpful.' Pretty site though. I think there's some good stuff here - but it's not how I'd teach it. Side-note: I love how wappalyzer says 'zero technologies detected.' That's rad. "Each layout in Every Layout is intrinsically responsive." Everything is intrinsically responsive before you force it not to be. Big respect for tackling this though. Lots of good stuff and just a bit of maybe not great stuff.

985 points by aarohmankad 7y ago

Saw this awesome project on Lobsters. I went ahead and ported these components to generalized, composable Styled Components. There's also an npm package at `every-layout`. https://github.com/aarohmankad/every-layout https://github.com/aarohmankad/every-layout

WA 7y ago
You mean "React Components" right? Nice effort, but please mention that these components are supposed to work with React. If we now use the word "Component" as a synonym for React, you make it look like there are no other frameworks than React.
- osdiab 7y ago
  No, he meant Styled Components, a popular library for styling React components.
  - WA 7y ago
    I see, didn’t know about this. Thanks for pointing it out!

codedokode 7y ago

Poor quality articles. They use flexbox and provide no fallback for older browsers. They could use at least non-responsive layout for desktop resolution for older browsers. Probably the reason why they didn't do it is lack of knowledge of CSS.

majewsky 7y ago
Flexbox has been supported by all browsers for years now, even by IE11. What on earth do you need to support if you cannot use flexbox?
- codedokode 7y ago
  Caniuse says that IE11 has a lot of bugs regarding flexbox. Firefox supports flexbox only since 2013-2014. So it would make sense to add a simple non-responsive fallback for older browsers. Also, if I remember correctly, the default browser in Windows 7 is IE9. It makes sense to support default browser in the most popular desktop OS. Some of older browsers, released in 2012-2014 support flexbox only with vendor prefixes, but the article doesn't has rules with prefix. As frontend devs tend to copy the code without much thinking, we cannot expect that they will add the prefixes or fallback code themselves. So it will be author's responsibility for web sites being less accessible in different browsers.
  - mixmastamyk 7y ago
    Win7 and IE9 are both EOL in six months. Makes sense to drop in new articles.
    - codedokode 7y ago
      HTML/CSS was designed to be forward/backward compatible and not to be written only for version of Safari installed on dev's macbook. This is against the spirit of HTML.
      - jrochkind1 7y ago
        If I understand right, you are suggesting it is "against the spirit of HTML" to write CSS that isn't backwards compatible... infinitely? You have to draw the line somewhere, right? An ancient enough browser won't support CSS at all. Using only CSS that would be supported by a, say, year 2005 browser would also be pretty limiting. You can choose to do that if you want, but I think your opinion about the "spirit" is a minority one.
      - CamperBob2 7y ago
        That ship sailed the day people first started using HTML for page layout in general. The spirit of HTML was not adequate to meet requirements, so the spirit has been upgraded. Pray all you want, it's going to be upgraded further.
chiefalchemist 7y ago
Andy Bell? Lacks CSS knowledge? That's a bit over the top.
proyb2 7y ago
You may be surprise to know who is Heydon who co-author in the article. https://inclusive-components.design/ https://inclusive-components.design/ IE11 is meant for supporting legacy sites and Microsoft doesn’t recommend consumers to use it. It make sense to work on Grid and Flexbox for new sites.
robdachshund 7y ago
You do realize that most projects do not target ie11 whatsoever right? I do mainly ecommerce and private web apps for clients. I have never needed to worry about if one of my users is on any version of internet explorer. If you are building some enterprise platform for the government or something, sure. But basic sites and apps are not trying to attract 90 year olds on xp using ie6. I'm not going to avoid using a css feature that is supported by modern browsers that makes my job much much easier.
plausibilities 7y ago
Maybe their target audience doesn't primarily consist of entry-level devs relegated to maintaining legacy eCommerce web properties and back-office portal/intranet systems?

vedantroy 7y ago

Out of curiosity, why doesn't the stack layout use flexbox? It seems like flexbox is the perfect fit for such a layout.

chiefalchemist 7y ago
Because it's a just a simple stack. The intent is concistent margins between siblings within the wrapper. What came to mind were paragraphs. Or perhaps images. Or both?
codedokode 7y ago
Display: block fits better because it has been around for more than 15 years unlike flexbox. And flexbox has no advantages in this case.
have_faith 7y ago
Margins of flex child elements won't collapse automatically like regular elements. It can be solved but it would be unnecessarily complex for the simplicity of the layout.
sureaboutthis 7y ago
Flex is great for one directional layout within a box. It is not great for two dimensions which most layout is concerned with.
- nhooyr 7y ago
  The stack is not two dimensional.
  - sureaboutthis 7y ago
    Has nothing to do with what we're talking about.
threehams 7y ago
If other browsers besides Firefox add support for the gap property, Flexbox will be perfect for this. The owl approach has some subtle issues, like not taking into account elements which show/hide based on breakpoint.

codedokode 7y ago

The code examples are overengineered. For example, the code generator for stack uses rem units and CSS variables, while it could be written without them and have better cross browser support (and the code would be easier to read and maintain in long-term perspective). The author just wants to use modern CSS features without clear rationale for this. Rem units can cause issues in long term. For example, imagine if a sidebar widget is coded using rems. When later the main font size is changed, margins within widget will change its size, although the font size in it is fixed and didn't change. There are cases when rem is useful and there are cases when it is not, but the author doesn't give a choice and doesn't explain it. He just uses his authority to push his personal preferences to frontend developers who tend to copy the code from tutorials without much thinking. I recommend using pixels for projects that are going to be maintained and developed in the long term.

Tomte 7y ago
I find your counter-argument against rem units very weak. What are cross browser concerns here? Why should he even mention the possibility that someone might "fix" an elements font-size? Sure, the author doesn't explain all of CSS and all of UX/UI in an article focussed on a single issue. That's not a mistake. Your px recommendation is... strange. The article is one of those "newer" CSS articles that care a lot about responsiveness. You seem not to care. Fine, but I guess you're in the minority there. Your insult against front-end developers (in both your comments!) is simply childish, and frankly, it seems you just have an axe to grind with the author(s).
jffry 7y ago
> There are cases when rem is useful and there are cases when it is not, but the author doesn't give a choice and doesn't explain it. and > I recommend using pixels for projects that are going to be maintained and developed in the long term. Directly after lambasting the author for failing to elaborate, perhaps you could go into more depth yourself?
- codedokode 7y ago
  A website that is maintained in a long term will be worked on by many people, and CSS will become quite large and complicated. So using the simple constructs like pixel units is better than using rems that create implicit dependence on main font size. This way there are less chances to break something in one place when editing code in other place. The same is about CSS variables. An example with one variable might look nice. But what if your code has hundreds of variables? It would take more time to understand how they are related and how do I change the size of this button without breaking something on another page.

ctidd 7y ago

I've written a series of very similar articles, and seeing as some of the ones in this site don't seem to be available yet, and otherwise as another point of view, they may be of interest to anyone looking at this: https://ctidd.com/2017/css-ui-patterns/content https://ctidd.com/2017/css-ui-patterns/content

have_faith 7y ago

The knowledge contained in the articles is very good but I got the feeling that it was written for an audience that already undertands the problems being solved. The Stack for instance is written in a language that only really makes sense if you've spent a lot of time with CSS and contains some extraneous paragraphs. I only mention this as the problems and solutions being explored are very valuable to learn but I think it could be written simpler and more succinctly so that meaning isn't lost for new-comers. I'd be happy to contribute if it was open to suggestions.

gary__ 7y ago
Bear in mind the tutorial is prefixed "Relearn..." Though I'd class myself as a "full stack developer" css for a long time was the 2nd class citizen, with most of my time spent on learning to use front end frameworks in their idiomatic way, the "it depends" peculiarities of SQL and RDBMSs and making inroads on the vast tomb that represents architectuliary sound back ends. So an article focussed on improving my "it's only css but it works" knowledge is one of the best things I've seen on HN in quite some time :)
- wolco 7y ago
  A good full stack developer should have double the salary of a frontend/backend developer. Do you find this is the case? You need to be an expert at both roles plus have a third skill connecting them together.
  - gary__ 7y ago
    I think there's often a leeway given to the full stack dev that they have strengths and limitations. I haven't got to the point where I could compete with the true / good front end dev with my skills. Even at the backend you have the application backend (c# or whatever) and then sql/rdbms. If you are that good perhaps you deserve thrice the pay by this logic ;). Jokes aside, at the last good company I worked for where I knew other people's pay, I was compensated for the entirety of my skills compared to the good front end dev. We earned the same, and I was quite happy with that. Jack of all trades...

Theodores 7y ago

There is more than way to do all of these layouts. I don't have time to learn all of them, I just want my content to look great on all devices. I also want to stick to the specifications of HTML as it applies to all the browsers that do HTML5 - so no Internet Explorer. Sticking to the specs means no hacks and the likelihood that someone can make sense of my code in ten years time and not think 'why did they do this?'. For this reason I will be sticking with CSS Grid. CSS Grid is supported in all HTML5 browsers, so that means everything except the depreciated Internet Explorer. To get my CSS Grid versions to work I will also be using CSS Variables defined in media queries to make things responsive. I don't need to have lots of fixed breakpoints as I use fonts that scale in such a way that lines don't get too long to read on really big screens. For the CSS variables I have fallbacks which are the desktop defaults. So although 'mobile first' I can get a deluxe mobile experience but code for desktop in the first instance. With pseudo classes I can add icons, usually Unicode symbols or SVG, SVG defined in CSS variables. Since I can do this with CSS Grid and only have Internet Explorer be 'of concern', I can write HTML5 with no superfluous markup. That means no div, span or even class attributes. I have got out of the mindset of using container wrappers for content and just putting neat content where it needs to go using CSS Grid. You could look at my HTML and think I had just swapped the div for article, aside and section. Or for figure. Or for main, header and footer. But that is not the case, I find that if I am using the right elements and pay attention to the structure of my content it just naturally styles itself with CSS Grid, no additional markup needed. Also not needed are clever things with calc. If I find myself doing that then it is a sign that I have got it wrong and that there is a simpler solution I have overlooked. I also rarely use pixels. It is ems or viewer units all the way, again no need to think of what a pixel actually is. I find that writing HTML and styling it without the hacks makes my code pretty alien compared to how the rest of the world is doing it. Anyone can make stuff complicated for reasons of backward compatibility, keeping it concise and simple is a different craft. For the above reasons I am disappointed by these layout modules, a lot of work has gone into it but at times we need to question what we take for granted. Everything is a div. I look at the examples and see that if, e.g., the image is put in a figure and given a figcaption then the structure is there for it to effortlessly be given layout with CSS Grid, no container elements needed. At some stage we need to stop looking at content as placeholder examples and stop using generic containers.

sergiotapia 7y ago

>https://every-layout.dev/layouts/cluster/ https://every-layout.dev/layouts/cluster/ >The Cluster layout is available in the full version of Every Layout, which is still in production. All of the currently available layouts are marked "read now" in the index page. where is production? I can't find it

dmitriid 7y ago
It's still in production meaning: they are not available yet, they are being written.
- galaxyLogic 7y ago
  Another way of saying that would be that they are still in "development"

gary__ 7y ago

This is great. I would prefer that browser compatability is mentioned, for my own purposes that would be IE11. Perhaps set a baseline of what browsers are considered in the intro and then highlight deviance as it occurs.

deleted 7y ago
[deleted]
andrei_says_ 7y ago
Suzy grids 2 is an amazing tool for ie11 and everything above it. So I can use one codebase for everything. Yes, it is float based but my code is at the correct level of abstraction.

victor106 7y ago

What’s the best resource (book, videos etc.,) to learn css these days?

runarberg 7y ago
MDN: https://developer.mozilla.org/en-US/docs/Learn/CSS https://developer.mozilla.org/en-US/docs/Learn/CSS
danbruc 7y ago
It's probably not for everyone but I just read the specification [1] last week. It is probably also worth noting that I did this to get a better understanding of some details and not for initially learning CSS. But those are mostly easy to read specifications and I think one could use them to initially learn CSS. CSS level 1 is pretty short but will still teach you a big chunk of the fundamentals of current CSS even though it is more than 20 years old. After that you can focus on the changes and additions in later versions - those newer specifications are a lot more technical and precise and cover a lot more features, so they are also longer and less fun to read from cover to cover. [1] https://www.w3.org/Style/CSS/current-work https://www.w3.org/Style/CSS/current-work
- macando 7y ago
  That was brave. I learned how the box model works from the specification.
- rimliu 7y ago
  I commend you. I am with Kyle Simpson (of the You Don't Know JavaScript fame) here—too often people don't even try to learn about the stuff they are using and are surprised by the behaviour which is clearly stated in the specification. This is true for JavaScript, but this is especially true for CSS. I think it is one of the least respected technology, devs don't spend much time and effort in learning it and then complain about it being a mess and not making sense. So if anyone is tired at throwing stuff at the wall and seeing what sticks just go and read the specs. It's much easier now than back in the days of IE5/6, no grid and no flexbox.
7y ago

meerita 7y ago

To me this way to CSS development is outdated. I will never program like this anymore. I only do functional/utilitarian CSS.

vast 7y ago
Pardon?
emmanueloga_ 7y ago
NOTE: I think this refers to the approach implemented by libraries like: * https://tailwindcss.com/ https://tailwindcss.com/ * http://tachyons.io/ http://tachyons.io/
- meerita 7y ago
  Also: * http://minid.net/2019/04/07/the-css-utilitarian-methodology/ http://minid.net/2019/04/07/the-css-utilitarian-methodology/ * https://github.com/meerita/utilcss https://github.com/meerita/utilcss
GoToRO 7y ago
can you elaborate? (also fotolog is not found)
- meerita 7y ago
  Yes, fotolog.com doesn't exist anymore but I would gladly elaborate. (full explanation here: http://minid.net/2019/04/07/the-css-utilitarian-methodology/ http://minid.net/2019/04/07/the-css-utilitarian-methodology/) resume: why go with an OO architecture, when you can use inmutable classes and never again repeat the same properties in your CSS files. In the end, you end up developing faster and you can mantain code easily without having to build the entire UI arquitecture in the CSS. CSS was created to separate style from the content, but also, because back then, HTML wasn't built like we do today with frameworks. Now that we use reactive HTML we can just print inline CSS, but that is a problem, so the functional CSS comes better.
ry_ry 7y ago

PyroLagus 7y ago

I'm not sure if the creators will read this, but on https://every-layout.dev/rudiments/axioms/ https://every-layout.dev/rudiments/axioms/ > At the time of conceiving the axiom, you make not have pictured this specific visual effect. I'm pretty sure it should be "may" instead of "make".

sktrdie 7y ago

To me an evident thing in UI development is that separating stylesheet from layout isn't really a thing anymore and the benefits of this separation aren't really that clear. Things like SwiftUI and React are showing that declarative UIs can be built by tying the style to the layout and allow for much better accessibility, tooling, overall thinking of how UIs work. So to me CSS feels a bit outdated since big companies are definitely moving away from this separation. How does HN feel about this?

Bahamut 7y ago
This is not quite necessarily true - I work at a tech giant and we've opted for using scss still & are quite happy with our choice.
- sktrdie 7y ago
  Is your company actually building a platform for developers to build apps? Because that's what Apple is doing and they shifted away from using paradigms like CSS.
  - ohrus 7y ago
    CSS is not a paradigm. Whatever workflow you have for styling your pages and apps, it's all CSS in the end.
    - orf 7y ago
      CSS can certainly be described as a paradigm. It's a model you follow to style things on the web. It also doesn't matter if it's all CSS in the end. At one particular end it's all manipulating assembly instructions, but I wouldn't call styling pages writing assembly. That is to say the underlying model or paradigm (styling in this case) doesn't really matter if you build an abstraction on top of it that hides that paradigm.
      - ohrus 7y ago

deanclatworthy 7y ago

Having been doing full-stack for over 15 years now, I have never seen the owl selector before. It's almost a perfect solution to a problem I regularly have. A quick google didn't reveal any browser support for it though. Anyone got a resource for that? I can see that the adjacent selector is supported on 98% of global browsers, but I would not be surprised if there were some issues combining it with * +

tracker1 7y ago
It's worth noting that * is incredibly inefficient, especially near the front of your selector, because of how the browsers generally handle element styling. It may be better now than in the past, but it's best to avoid it for the most part.

razvandh 7y ago

started reading some of the ideas and got put-off almost immediately. 'margin-top'? the owl-selector? Really? Why do we keep making our life more difficult than it should be? CSS is such a beautiful and interesting tool, yet we still decide to misuse it in trying to be too smart. ( margin-top: you start dealing with parents inheriting the margin - which is an old quirk of CSS - it's a side-effect you need to control, so the usage of margin-top should always be avoided and margin-bottom should be the preferred solution owl selector: performance implications - it's fairly bad from a performance POV to use it. Also, we live in a world where we have control over how the layout is generated, we should avoid using generic selectors Source: I've been doing frontend and focused on CSS for over 10 years )

Atomskun 7y ago
> so the usage of margin-top should always be avoided Not really if you consider sibling layouts, e.g.: https://matthewjamestaylor.com/css-margin-top-vs-bottom https://matthewjamestaylor.com/css-margin-top-vs-bottom > owl selector: performance implications - it's fairly bad from a performance POV to use it. Arguing about "CSS performance" is futile when the real cause of bloatedness is mostly JavaScript these days (also: http://alistapart.com/article/axiomatic-css-and-lobotomized-owls http://alistapart.com/article/axiomatic-css-and-lobotomized-...). The owl-selector can actually be quite elegant, but becomes a burden if you have lots of side-by-side blocks (which would always need to set their margin-top to 0).
- ry_ry 7y ago
  I was suprised the degree to which selector performance is a negligible overhead in normal use these days. Was browsing through the docs for some Vue+CSS library or another recently, and the author had done quite a lot of research into this, was interesting. They were heavily using the square bracket html-attribute selector notation, although I'm not sure if it performs better now, or if modern processors are just that much faster.

miki123211 7y ago

This website is one of the accessiblest things (for screen readers) out there. I have never seen alt text for layout images. This is well beyond amazing.

sam0x17 7y ago

Uh huh, what about "the vertically centered div" and the ever important "span vertically centered within the parent"

sheriffderek 7y ago

"Web browsers helpfully apply default CSS styles..." Totally disagree with the idea that this is 'helpful.' Pretty site though. I think there's some good stuff here - but it's not how I'd teach it. Side-note: I love how wappalyzer says 'zero technologies detected.' That's rad. "Each layout in Every Layout is intrinsically responsive." Everything is intrinsically responsive before you force it not to be. Big respect for tackling this though. Lots of good stuff and just a bit of maybe not great stuff.