Few questions

[dan-gamble]

Hi Ben, just finished reading the book and i enjoyed it and definitely will be implementing it in my next project i just had a few questions.

1. Would you be able to show me a couple of files that have used ECSS? Ideally one that has 150+ lines and one that is probably less than 50 lines to see how it gets structured in an actual live environment.
2. Do you still use classes like container classes or do you build these into every module and just variable up the repeating things?
3. What do you think are the downsides of using ECSS like you pointed out with OOCSS?

[benfrain]

1. Here is a 100+ liner:

.hm-TestModuleDropMenu {
    position: fixed;
    top: $size-quadruple;
    right: $size-full;
    min-width: 300px;
    background-color: $color-grey-dd;
    transform: translate3d(0, -100%, 0);
    transition: transform .15s;
    animation: delayedVisibility 0 .15s;
    .state-AccountDropActive & {
        transform: translate3d(0, 0, 0);
        animation: none;
    }
    /*If the UA doesn't support 3d transforms, we fallback to 2d transforms. Note, we have forked on svginhtml feature instead of csstransforms3d as we don't have that JS test in place and this feature also forks at the same browser points (e.g. Android < 4) */
    .no-svginhtml & {
        transform: translateY(-100%);
    }
    .no-svginhtml .state-AccountDropActive & {
        transform: translateY(0);
    }
}

.hm-TestModuleDropMenu_UserBalance {
    font-size: $text21;
    line-height: 1.2;
    color: $color-green;
    display: block;
}

.hm-TestModuleDropMenu_DepositBtn {
    display: flex;
    align-items: center;
    min-height: $size-treble;
    padding: 0 $size-full;
    color: $color-green;
    border: 1px solid $color-green;
    border-radius: $radius-small;
    .state-MakingDeposit & {
        display: none;
    }
}

.hm-TestModuleDropMenu_CancelBtn {
    display: none;
    align-items: center;
    min-height: $size-treble;
    padding: 0 $size-full;
    color: $color-grey-40;
    border: 1px solid $color-grey-88;
    border-radius: $radius-small;   
    .state-MakingDeposit & {
        display: flex;
    }
}

.hm-TestModuleDropMenu_Row {
    display: flex;
    align-items: center;
    font-size: $text15;
    color: $color-grey-54;
    min-height: $size-quadruple;
    padding: 0 $size-full;

    & + & {
        border-top: 1px solid $color-grey-cc;
    }
}

/*The header needs a little padding top and bottom too*/
.hm-TestModuleDropMenu_Header {
    padding: $size-half $size-full!important;
    border-bottom: 1px solid $color-grey-cc;
}

/*This wraps the main section of links. Get's toggled off when a user presses deposit*/
.hm-TestModuleDropMenu_ToggleAreaBalances {
    .state-MakingDeposit & {
        visibility: hidden;
    }
}

/*This row needs the two child elements spacing*/
.hm-TestModuleDropMenu_Splitter {
    justify-content: space-between;
}

.hm-TestModuleDropMenu_MessagesContainer {
    border-top: 1px solid $color-grey-88!important;
}

/*We need add the Toggle icon*/
.hm-TestModuleDropMenu_BalanceToggle {
    @mixin FontIconAfter;
    &:after {
        content: "\e610";
        font-size: $text13;
        margin-left: 5px;
    }
}

/*We need add the refresh icon*/
.hm-TestModuleDropMenu_BalanceRefresh {
    @mixin FontIconAfter;
    &:after {
        content: "\e613";
        font-size: $text13;
        margin-left: 5px;
    }
}

@keyframes delayedVisibilty {
    0% {
        visibility: visible;
    }
    100% {
        visibility: hidden;
    }
}

.hm-TestModuleDropMenu_MessagesCount {
    @mixin FontIconBefore;
    &:before {
        content: "\e611";
        font-size: $text13;
        margin-right: 5px;
    }
}

Here is a smaller file:

.hm-TestModuleNav {
    background-color: $color-grey-33;
    /*We need to accommodate the hide button*/
    padding: 0 $size-treble 0 0;
    /*We need to provide context for the absolutely positioned hide button*/
    position: absolute;
    top: -$size-treble;
    /*We need to elevate this in the stacking order so that the menu always slides behind*/
    z-index: $zi-high;
    right: 0;
    left: 0;
    @media (min-width: $XM) {
        display: none;
    }
}

/*Here is the panel that allows scrolling within*/
.hm-TestModuleNav_Scrollable {
    white-space: nowrap;
    overflow-x: auto;
    overflow-y: hidden;
    -webkit-overflow-scrolling: touch;
    &::-webkit-scrollbar {
        display: none;
    }
}

.hm-TestModuleNav_Link {
    display: inline-flex;
    align-items: center;
    min-height: $size-treble;
    font-size: $text11;
    line-height: $text12;
    margin-left: $size-double;
    color: $color-grey-dd;
    &.hm-TestModuleNav_LinkCurrent {
        color: $color-yellow;
    }
}

.hm-TestModuleNav_HideBtn {
    @mixin FontHeadline;
    font-size: 10px;
    display: flex;
    justify-content: center;
    background-color: $color-grey-33;
    align-items: center;
    flex-direction: column;
    line-height: $text12;
    position: absolute;
    top: 0;
    color: $color-grey-99;
    bottom: 0;
    right: 0;
    width: $size-quadruple;
    border-left: 1px solid $color-grey-44;
    @mixin FontIconBefore;
    &:before {
        content: "\e603";
        display: block;
    }
}

1. If I understand correctly, for the most part the root of a module IS the container. If you are making a shopping cart, .nav-ShoppingCart would be the root of the module and therefore the container. I would't then have a class alongside that like .Container that sets any defaults style wise, I would have everything needed inside .nav-ShoppingCart as everything is then self contained and more able to be moved anywhere as needed.
2. The downsides are that rule for rule, ECSS would be more verbose than OOCSS (more repeated property/values). However, as argued, in some instances, the comparatively small difference is a price worth paying for easier maintenance of the CSS codebase. My experience has been that the CSS stays smaller with ECSS as there are no 'utility' or SRP classes lying around. You mileage may vary :)

[dan-gamble]

Thanks for the files Ben, very insightful.

RE: #1 I mean a container class in the Bootstrap sense that sets a max-width with margin: 0 auto. Something that would be used in quite a few modules.

RE: #2 I fully agree that your approach makes it much more maintainable and i do like your Single Source of Truth point as well. I think the duplication you do is very much offset by the specificity that ECSS offers vs OOCSS. As much as i like the idea of SRP & Utility classes in practice they quickly become a jumbled mess that is very hard to keep track of.

Finally thanks for all your responses over the last few days. It has left a good impression on me regarding the work you do :)

[dan-gamble]

Ooh sorry another question i forgot to ask. Would you be able to share your Stylelint no nesting & naming convention plugins?

[benfrain]

Hi Dan,

I can't right now but I will enquire if it's something we can make public.

Thanks, Ben

On 4 Nov 2015, at 11:07, Dan Gamble notifications@github.com wrote:

Ooh sorry another question i forgot to ask. Would you be able to share your Stylelint no nesting & naming convention plugins?

— Reply to this email directly or view it on GitHub.

[dan-gamble]

That's no worries Ben :)

[corysimmons]

Care if I piggyback?

What are some differences between ECSS and SuitCSS? In the book you mention OOCSS and BEM as the two big architectures, but SuitCSS seems pretty popular nowadays as well.

[benfrain]

Hi @corysimmons I'll be honest, I don't really know as I have never used SuitCSS. Just had a quick look and two things pop out:

1. SuitCSS is a product of @necolas so I imagine it's very good and well considered. If you're looking for a CSS architectural approach I would recommend you try it and see how it fits what you need
2. From my cursory glance at the docs the most obvious thing for me is that ECSS does not use utility classes of any sort. It's something I used originally but now completely avoid. Whether that's appropriate for you or not only you can know.
3. SuitCSS appears to be stronger for toolkit purposes. E.g. it's using NPM so you can import style abstractions into projects so likely a good choice if you have lots of projects/products that share similar style abstractions. ECSS on the other hand is very much about 'the thing being the thing'. Every element gets what it needs and that's that.

[corysimmons]

Thanks @benfrain

I'll finish up the book and probably be back to pester you with more questions. :D

[benfrain]

Sure, just open a new issue and I’ll be happy to help as much as I can.

On 17 Feb 2016, at 22:06, Cory Simmons notifications@github.com wrote:

Thanks @benfrain https://github.com/benfrain I'll finish up the book and probably be back to pester you with more questions. :D

— Reply to this email directly or view it on GitHub https://github.com/benfrain/ecss/issues/1#issuecomment-185429000.