Site Wide micro-namespaces

[jamiepittock]

Hi Ben,

I've been reading your book this weekend and found myself nodding along to a lot of the problems you're attempting to solve, and the decisions you've made. Thank you.

I had one question about something you mention in chapter 5 and the use of a sw- micro-namespace to denote it would be used Site Wide, for example .sw-Callouts, and to remove any ambiguity for future developers as to the origin point of this element.

Before reading that I was thinking that if a micro-namespace matched the module's own namespace, i.e. .co-Callouts, that would show that this is the root of the module and it has no other context. What's the benefit or purpose of denoting something as site wide? Do you have any other examples?

[benfrain]

Hi Jamie,

I've just updated Chapter 7 with a section on global CSS and structure.

If you have bought the book you should be able to grab the latest version. I've also updated ECSS.io too.

Does that answer your query? If not, feel free to let me know here and hopefully I can clarify.

On 10 Apr 2016, at 09:53, Jamie Pittock notifications@github.com wrote:

Hi Ben,

I've been reading your book this weekend and found myself nodding along to a lot of the problems you're attempting to solve, and the decisions you've made. Thank you.

I had one question about something you mention in chapter 5 and the use of a sw- micro-namespace to denote it would be used Site Wide, for example .sw-Callouts, and to remove any ambiguity for future developers as to the origin point of this element.

Before reading that I was thinking that if a micro-namespace matched the module's own namespace, i.e. .co-Callouts, that would show that this is the root of the module and it has no other context. What's the benefit or purpose of denoting something as site wide? Do you have any other examples?

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub

[jamiepittock]

Hi Ben,

Kind of.

Let me try to give an example. I have a module I call a 'Slat' which has a badge, a title and a subtitle. They look like this:

http://d.pr/i/YPwc/ICu1HGWK

These modules appear within lots of other modules - search results, featured panels, shopping cart - but they always look the same; never overridden.

So playing around at the weekend rewriting some modules as I was reading ECSS.io I was coming up stuff like this:

FeaturePanel is my module and it has a fp- micro-namespace. Slat is another module and has a micro-namespace of st-. A Slat sometimes lives within a FeaturePanel but is never actually effected by it so I figured something like this was fine...

<div class="fp-FeaturePanel">
    <h2 class="fp-FeaturePanel_Title">Some items</h2>
    <div class="st-Slat">...</div>
    <div class="st-Slat">...</div>
    <div class="st-Slat">...</div>
</div>

As long as we're strict in never allowing stuff like this into the CSS:

.fp-FeaturePanel .st-Slat {
    color: blue;
}

If we ever did need to start overriding we'd create a new component, like:

<div class="fp-FeaturePanel">
    <h2 class="fp-FeaturePanel_Title">Some items</h2>
    <div class="fp-Slat">...</div>
</div>

Or this:

<div class="fp-FeaturePanel">
    <h2 class="fp-FeaturePanel_Title">Some items</h2>
    <div class="fp-FeaturePanelSlat">...</div>
</div>

Does that sound fair? It seems unnecessary to duplicate the Slat module as a component for every module it might sit within when it's never affected by the context.

It's unlikely though that a Slat is ever used on it's own; it would always be displayed within a different module. Which kind of makes it a global style or an abstraction which goes against the idea of providing isolation. And it's a slippery slope when you start abstracting things away.

[benfrain]

Hi Jamie,

Ah, great explanation, I understand what you are getting at now. OK, this is my take.

Your first HTML example seems perfectly fine to me. The st-Slat can live wherever you put it as it is ignorant or 'context agnostic' if you like.

All the styles would typically be in your Slat.css partial (or whatever makes sense to your config). Yes, don't allow nesting unless it is to override (as described in Chapter 8) so the selectors for the styles for the slat would be:

.st-Slat {}
.st-Slat_Node {}
/*etc*/

And should you need to override that slat in the eventuality of context (e.g. it is physically nested in the fp-FeaturePanel module) then you would do this:

.st-Slat {
    .fp-FeaturePanel & {
        /* override */
    }
}

I'm not sure you would need another component (unless it was so different it warranted it) when it was nested in the FeaturePanel - guess it depends if it is just aesthetic changes or if the Slat is genuinely different in that context (and you are just extending the logic class).

[jamiepittock]

Thanks Ben, this helps a lot and makes total sense.

I think I was misinterpreting your "embrace repetition" section and particularly this bit:

With ECSS, if a component needs to be made that is similar, yet subtly different to an existing component, we would not abstract or extend from this existing component. Instead, a new one would be written.

But I see now that's referring more to using abstractions and extending other stuff rather than overriding.

Thanks again. All really useful stuff.