Hacker News new | ask | show | jobs
by Theodores 2563 days 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.

2 comments

> if I am using the right elements and pay attention to the structure of my content it just naturally styles itself with CSS Grid

Why is that? Does Grid treat 'article'and 'section' differently than it treats plain 'div'?

I thought that the purpose of 'article' etc. was purely semantic, saying something about the meaning and purpose of content inside them, not how they should be laid out on the page.

I think the point here is that if you use semantic elements, you don't need to use classes to differentiate.
What I have learned just from having a go is that document outlines matter too, so I just think of whatever I am writing in terms of sections, articles and asides. I don't actually ever think of adding a 'div', there is just no actual use case for them.

Typically with a 'section' the first line inside it for me is a heading. So on the outline there are no 'unnamed sections'. Save with 'nav' and other content blocks, I usually find that there does need to be a heading in there anyway.

So Grid does not care what the elements are, however, that form fieldset won't work in CSS Grid and there may be a couple of other edge cases. Now here is the important thing to know - have too many nested divs and it makes CSS Grid very difficult, almost pointless.

So, imagine a form. You can have just label followed by input, label followed by input with some submit button at the end. This can be put into CSS grid and styled beautifully with no effort. It goes responsive effortlessly as well. There is nothing to it.

But then, in real life you are working with some legacy code where there are divs around each form element and divs grouping the labels and the inputs and an outer wrapper with spans around the required field asterisks, everything with class attributes on it.

It is hard to imagine if you are used to that type of markup that you don't need any of it!

But that is the case. You can write ultra lean HTML.

Then when it comes to actual content, e.g. a blog article, you realise that the WYSIWYG paradigm is doing us no favours. It has no structure even if it looks okay.

So I use the article and section elements to just get my writing neatly organised, with headings at the top of each. This is more about just writing content neatly than presentation.

The div makes sense if you are copying stuff from old tutorials, but it never makes sense with content, but it sneaks in there. It is so baked in with things like the Wordpress Gutenberg blocks thing where some people have staked the whole company on new ways of writing out of spec bad HTML. If you check the manual you will see it is the element of last resort and just isn't needed with CSS Grid layout.

Before CSS Grid layout you did need the div to make wrappers for centering stuff. But now you don't. But people have got so used to using it that it has got stuck in the mindset, a groupthink that will look silly in a decade or so.

I also style the elements, never needing classes. But with no div wrappers these are all sensible looking to me but would horrify someone doing BEM notation. Here is an example that gives you an idea...

    body > footer > nav > ul {
      display: grid;
      grid-auto-flow: var(--footer-nav-ul-auto-flow, column);
      grid-gap: .25em;
      justify-items: var(--footer-nav-ul-justify-items, left);
      padding: 0;
    }
So that is for some responsive footer links, they go across the page on desktop and the other way on a small screen. Best practice would say that I add 'footer-links' as a class to the footer links. Best practice says the 'body > footer > nav > ul' selector is 'too complicated' as it uses four rather than three (max) selectors. But that is how I like to read my CSS these days, with no preprocessor, no compiling, just spelt out.

Now this example is not a portable component but that is the point, the document structure is relatively flat and quite predictable.

If seems like you discount portability as a concern, and if that's appropriate for your use case, that's a fair decision of course. But there are many use cases for which that's a priority.

The concern the BEM and component-based CSS approaches aim to address is the composition of arbitrary chunks of DOM without implicit side effects. By having chunks of DOM explicitly opt in via classes to being styled in a given way, they never accidentally receive styles they weren't meant to, and they're fully portable to arbitrary contexts.

In something like an web application as opposed to a document-oriented website, the ability to compose components and avoid quirks of things that randomly break or look different inside other things is beneficial. Using a component in a new place shouldn't (in the application development context) require adding new selectors for it because it's not "where" your selectors expected it to be.

When it comes to portability I find that a class for the component is all that is needed. So that is at the root element of the component and with everything inside classless. So '.component > nav > ul' might be how I would style navigation inside the component, knowing it would not inherit styles from the body defined classes for header/footer navigation.

The BEM type of examples you will normally see will have everything as a div, I just avoid div elements not out of some prejudice against them but because I am out of the mindset to think to use them.

A lot of what I am saying here does fall apart on over complicated commercial projects though where the CSS is 'add to' and you can't just strip everything out to do it stupidly simplified.

I am also not a fan of monolith stylesheets with resets and frameworks adding thousands of lines of CSS. The idea that you should need 30000 lines of CSS for a product page is just silly, but even some of the best websites are doing that sort of thing.

In one of my pet projects that I am not quite happy with yet (wording could be better), I create a lot of content from JSON data using templates done as 'template' the element. The approach of using simple selectors works well when it comes to taking a template, changing elements within it such as the title and adding rows of data to it. I have struggled with over complex toolkits that create stuff, e.g. the Wordpress Gutenberg editor, but I find vanilla javascript (no compiling) with full feature HTML5 (all the elements) and the compound selectors work great. At one level the rest of the world is way ahead of me on these mega complex build tools but then I wonder if they are really needed.

Anyway back to it!

Good points, seems using semantic tags makes a lot of sense.

Just a question, is article part of a section, or section part of an article ?

Do you have any examples as a Gist?
I think I should. My actual commercial work is still done with old fashioned HTML, my first couple of pet projects done with the new way of using HTML5 don't have perfect document outlines as I was still holding on to the old ways of doing stuff and are not my best work. Only now am I fully in my stride on doing actual lean HTML with a couple of projects I haven't fully finished.

One thing is that when you are no longer using presentational markup then you only really have content, so it is markup with context. So I think it is a finished project I need to be able to share rather than an example.

Best get to it!