Can you please share more of the code surrounding your use case? Because it seems like the only thing you add to the parent is width: 100%, and the rest you are nesting in a h1 selector anyways.
A trick I use for CMS generated HTML (i.e. everything without classes) is to use a :not([class]) selector. Then anything else, e.g. an unordered list or hyperlinks in a nav menu, just need any class added (or manually override the styles).
Here is an example (similar markup from a demo shop, with h2 headings. The top-level cms-section.cms-section-default only differ by their pos-n position classes which have no benefit compared to nth-child.
Any other distinction, even the content id's, can only be made on a descendent level.
The structure is as follows:
<divclass="cms-sections"><divclass="cms-section pos-0 cms-section-default"><divclass="cms-block-container"style="/* some inline style */"><divclass="cms-block-container-row row cms-row"><divclass="col-12"data-cms-element-id="somecrypticidstring"><divclass="cms-element-text"><h2>Headline (not every CMS content type has a headline</h2><p>Lorem ipsum...</p></div></div></div></div></div></div>
Thanks, but sorry I still don't see the value here.
Your CSS only applied width: 100% in the :has selector, which a div would have by default as a block level element.
Otherwise, if targeting the h2 or p, you could do that with descendent selectors or the :not([class]) as I suggested in my previous comment.
Perhaps a better example could be for forms or something, where you could combine with the :invalid pseudo-class or similar to change the parent div styles:
Still don't see how you would have done it with not when all the div elements are undistinguishable by their class names. Of course, a div should be a block level element by default. You are lucky you didn't have to deal with the existing CSS. Using descendant selectors was what I did in the end, still didn't find it elegant or robust, probably it will break after the next framework update.
Better way would be if the customers content editors would choose different types of block templates which could then be given distinct class names.
Complex code should always arise suspicion that something might be conceptually wrong by design and could be solved at the problem's root cause. That's what I meant by "hotfixing a hotfix" in CSS (oh, and don't even start to count the number of !important in the existing style sheets).
Sorry, I didn't make that clear. The :not([class]) would be for targeting the paragraphs or headings that come from the CMS or whatever, where you don't have the ability to add or target classes.
<main><pclass="lead">Lorem ipsum...</p><!-- other content not generated by the CMS --><divclass="cms-sections"><divclass="cms-section pos-0 cms-section-default"><divclass="cms-block-container"style="/* some inline style */"><divclass="cms-block-container-row row cms-row"><divclass="col-12"data-cms-element-id="somecrypticidstring"><divclass="cms-element-text"><h2>Headline</h2><p>CMS Content. Lorem ipsum...</p></div></div></div></div></div></div>
The lead paragraph would be black, inheriting the color from the body.
So the not selector makes them act like global element styles that you opt out of by simply adding a class to the HTML element (even a blank string).
The assumption is that anything you want custom styling for that isn't regular body copy content (from a CMS or similar), you probably have control over the HTML and would normally be adding classes to style them anyways.
But anyways, this is obviously a whole other conversation! 🙂
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Can you please share more of the code surrounding your use case? Because it seems like the only thing you add to the parent is
width: 100%
, and the rest you are nesting in ah1
selector anyways.A trick I use for CMS generated HTML (i.e. everything without classes) is to use a
:not([class])
selector. Then anything else, e.g. an unordered list or hyperlinks in a nav menu, just need any class added (or manually override the styles).Here is an example (similar markup from a demo shop, with h2 headings. The top-level
cms-section.cms-section-default
only differ by theirpos-n
position classes which have no benefit compared tonth-child
.Any other distinction, even the content id's, can only be made on a descendent level.
The structure is as follows:
Here is a screenshot as well
Thanks, but sorry I still don't see the value here.
Your CSS only applied
width: 100%
in the:has
selector, which adiv
would have by default as a block level element.Otherwise, if targeting the
h2
orp
, you could do that with descendent selectors or the:not([class])
as I suggested in my previous comment.Perhaps a better example could be for forms or something, where you could combine with the
:invalid
pseudo-class or similar to change the parentdiv
styles:Thanks for the form example!
Still don't see how you would have done it with
not
when all thediv
elements are undistinguishable by their class names. Of course, a div should be a block level element by default. You are lucky you didn't have to deal with the existing CSS. Using descendant selectors was what I did in the end, still didn't find it elegant or robust, probably it will break after the next framework update.Better way would be if the customers content editors would choose different types of block templates which could then be given distinct class names.
Complex code should always arise suspicion that something might be conceptually wrong by design and could be solved at the problem's root cause. That's what I meant by "hotfixing a hotfix" in CSS (oh, and don't even start to count the number of
!important
in the existing style sheets).Sorry, I didn't make that clear. The
:not([class])
would be for targeting the paragraphs or headings that come from the CMS or whatever, where you don't have the ability to add or target classes.e.g.
The lead paragraph would be black, inheriting the color from the body.
So the not selector makes them act like global element styles that you opt out of by simply adding a class to the HTML element (even a blank string).
The assumption is that anything you want custom styling for that isn't regular body copy content (from a CMS or similar), you probably have control over the HTML and would normally be adding classes to style them anyways.
But anyways, this is obviously a whole other conversation! 🙂