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.<p>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.<p>So to me CSS feels a bit outdated since big companies are definitely moving away from this separation. How does HN feel about this?
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: <a href="https://ctidd.com/2017/css-ui-patterns/content" rel="nofollow">https://ctidd.com/2017/css-ui-patterns/content</a>
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`.<p><a href="https://github.com/aarohmankad/every-layout" rel="nofollow">https://github.com/aarohmankad/every-layout</a>
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.<p>(
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
)
This is great.<p>I would prefer that browser compatability is mentioned, for my own purposes that would be IE11.<p>Perhaps set a baseline of what browsers are considered in the intro and then highlight deviance as it occurs.
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.<p>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 * + <i>
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.<p>I'd be happy to contribute if it was open to suggestions.
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.
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?'.<p>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.<p>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.<p>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.<p>With pseudo classes I can add icons, usually Unicode symbols or SVG, SVG defined in CSS variables.<p>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.<p>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.<p>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.<p>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.<p>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.<p>At some stage we need to stop looking at content as placeholder examples and stop using generic containers.
"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.
I'm not sure if the creators will read this, but on <a href="https://every-layout.dev/rudiments/axioms/" rel="nofollow">https://every-layout.dev/rudiments/axioms/</a><p>> At the time of conceiving the axiom, you make not have pictured this specific visual effect.<p>I'm pretty sure it should be "may" instead of "make".
><a href="https://every-layout.dev/layouts/cluster/" rel="nofollow">https://every-layout.dev/layouts/cluster/</a><p>>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.<p>where is production? I can't find it
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.
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.<p>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.<p>I recommend using pixels for projects that are going to be maintained and developed in the long term.