> 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.
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.
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.