Skip to main content

Forums

This topic contains 8 replies, has 6 voices, and was last updated by  MattDiMu 3 years, 11 months ago.

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • #162308

    martypowell
    Participant

    I am currently building a web component using sass. I am have used sass for a bit, but am really trying to make an effort to make follow best practices and write solid css code.

    I have setup a codepen for this. You can see in my sass comments that I am getting 6 levels deep, one thing Chris says not to do in his Sass Style Guide.

    An especially problematic element is when you get into the unordered list. When I use lists I almost always require 3 levels of nesting.

    I am trying to keep the css for this component very specific the so css can be included in any site without causing conflict and without any required overrides.

    I would appreciate any tips/suggestions to help me with future sassing!

    #162309

    Senff
    Participant

    I also TRY not to get more than 3 levels deep, but sometimes I can’t avoid it without being overly unspecific. Indeed it happens most with unordered lists.

    While I’m sure it’s possible to stick to the “no more than 3”-rule, in some cases I ignore it because my Sass file is so nicely structured, and to break out of that structure (just for the sake of not getting a 4-level nesting declaration) is a little too much for me.

    You’ll see many 4-level (or higher) declarations everywhere in (post-Sass) CSS files, I’d say the 3-level rule is a guideline, not a law. I mean, is this really that bad?

    footer .main a {color:#ff00ff;}
    footer .main ul li a {color:#ff0000;}  /* oh no, 5 levels! */
    

    I don’t think it’s that awful — the best I could do there is 4 levels deep anyway. All in all, trying to limit your nesting is probably just because it’s sometimes very easy/tempting to go way over the top.

    body
        .wrapper {
            footer {
                .main {
                    form.search {
                        fieldset {
                            input {
    

    That’s what I did at first because it so nicely represented my site structure. Of course, this could probably have sufficed:

    footer {
        input {
    

    Anyway. I guess, don’t nest just because it looks nice in your Sass. Or something.

    #162313

    TheDoc
    Moderator

    I definitely don’t like nesting more than three levels. Usually I reserve that 3rd level for pseudo elements and states (:before, :hover, etc).

    I prefer using better classnames so I don’t need to nest that much.

    In your Codepen example, why does .setting need to be nested? Does it require being under .easy-reader in order for its styles to apply?

    If you’re worried about a class of .setting being used elsewhere and you don’t want to share those values you could use a more specific class like .easy-reader-setting.

    #162530

    martypowell
    Participant

    @thedoc Thanks I think I either under thought this or overthought this . But I am going to take your advice with something like .easy-reader-setting. This really is a smaller component of my larger .easy-reader. Thanks for straightening me out.

    #162531

    martypowell
    Participant

    @senff Thanks comments for well. Your are right, sometimes you need to break the guidelines for something like a unordered list, but lets ill try to avoid more than 3 levels if possible!

    #205144

    Alan
    Participant

    Why exactly is it bad to nest more than 3 levels deep? I find it incredibly useful and haven’t run in to any issues so far

    #205145

    Paulie_D
    Moderator

    As I understand it, it’s because it can make your code hard to read from someone coming into it cold.

    Also, it tends to make really complicated and overly specific selectors.

    The SASS people tell you why

    http://thesassway.com/beginner/the-inception-rule

    #205146

    Alan
    Participant

    That makes sense, I’m not sure I agree with the argument on the sassway that it majorly affects rendering performance though?

    I only deep nest things from time to time and find it being overly specific really useful but equally useful is CSS’s cascading property.

    #205148

    MattDiMu
    Participant

    Long selectors won’t (significantly) affect your site’s performance in most cases, as browsers read the selectors from right to left (see: http://stackoverflow.com/questions/5797014/why-do-browsers-match-css-selectors-from-right-to-left/5813672#5813672) Only if you’d use general selectors all the time, there could be a measurable difference (e.g. div > * > * > * > * > * {…} – but who does that?)

    IMO nesting selectors is no problem at all, if
    – you’re the only one editing the styles OR
    – you have consistent naming conventions (and a different developer therefore knows from the used class-names where and how to edit/extend the targeted component) OR
    – you’re using sourcemaps (and when clicking on such an xl-sized selector, you get to the source scss/less-file)

    One disadvantage remains, however: If you change the order of your html, you’ll probably need to adjust the scss/less-file as well – but usually that’s necessary anyway.

Viewing 9 posts - 1 through 9 (of 9 total)

You must be logged in to reply to this topic.

icon-link icon-logo-star icon-search icon-star