Guide for writting css and sass

[jersiovic]

Does Orchard 2 or Orchard 1 follows any convention for deciding the default css classes Orchard renders with html? I mean like SMACSS, BEM or a combination of both ... https://thesocietea.org/2016/06/combining-bem-and-smacss/

[DaRosenberg]

Not one that I've ever been able to discern. :)

I would be hugely in favor of adopting BEM methodology, and some BEM-based naming convention. I think the author of the article you linked to has slightly misinterpreted the main focus of BEM though, to me BEM is much more about how to mentally reason about the structure of markup in terms of blocks and elements, than the practicalities of how you should format your CSS.

I don't like SMACSS much, it is too prescriptive in details and it touts too many conventions that I find to be bad. But a sub-optimal convention applied consistently is infinitely better than no convention at all.

[stevetayloruk]

I like BEM too. But bootstrap and MDL do not use this.

[DaRosenberg]

That's a good point Steve. It would be awkward to mix BEM for everything we add, with the "let the name parts fall where they may and then put dashes between" style for everything that Bootstrap adds.

[stevetayloruk]

This may be irrelevant. I've made a start on creating a set of common tag helpers for the admin which abstracts all the markup. So, the author can just use custom tags and attributes and it just works. No need to know specific bootstrap styles and therefore you could easily switch from bootstrap to mdl for example.

These common components will make it super quick and consistent to author admin screens. For example, Click Me or Click Me

Let me know what you think, the finer details are yet to be ironed out so feedback is welcome.

Thanks

[sebastienros]

Tag Helpers baked by shapes I hope.

[jersiovic]

@stevetaylor yes use custom attributes and tags instead of ones related to technology. If we are able to agree a consistent naming we are going to save a lot of work for each new theme we want to create, because we won't need to fight vs the technology and arbitrary decisions taken in default templates creating new templates for everything. This also will make our sites more friendly for third party companies that don't know orchard but you want they develop a theme for your page cause it is more likely they can do the work only changing sass and css. Or at least will be less likely they need to change cshtml templates. For those case it would be great to have a special chapter in the docs explaining: Our tags and attributes conventions, dynamic layouts and placement.

[jersiovic]

Another point is that Orchard needs to provide infrastructure for supporting the convention. For example BEM allows to mix blocks. But for that in child block you need to know the parent block to reflect it in the child class. https://en.bem.info/forum/4/ If we consider the zones as blocks, we will need to know in blocks rendered within zones the name of the zone in which they are rendered to reflect it on their class, so for example from the template of a content type we would need access to know in which zone that content item is being rendered.

[jersiovic]

Any advance on those tag helpers abstracting the markup?

I don't think to use BEM or a refinement like ABEM is incompatible with using Bootstrap. It is only a tool you provide for ease customization of a theme as you can read here https://github.com/getbem/getbem.com/issues/152 Bootstrap classes can coexist with BEM notation.
What BEM classes provides is the ability of ease the customization of a theme using css. In our case for reusability sake we provide same theme for around 30 tenants, problem is css customization is a nightmare because of how difficult is to limit changes to one concrete component without breaking other things. To have a clear class naming convention for tags produced by Orchard would have changed things for better. Another good read about why a naming convention is sth needed for complex projects is this one: https://evilmartians.com/chronicles/bootstrap-an-intervention

Related to taghelpers I don't think it is sth that replaces the need of a default naming convetion.

[stevetayloruk]

Sorry, no I never got to finish the tag helpers but I believe that the approach still provides value through abstraction. The issue we had with Orchard 1 was that the admin UI was all over the place with module authors re-creating grids and forms or copying and pasting. This led to inconsistencies and wasted time.

BEM, is a naming convention primarily to provide a namespace to components which avoids clashes with another component. This helps when updating the CSS to ensure only that component is affected.

BEM is seen as a work around and is only used in today's world under certain circumstances. There are still valid reasons to use BEM but there are alternatives available.

Web Components (see my 2014 orchard talk) has the shadow dom which eliminates the need fo BEM. If you didn't want to use Web Components (well supported now) there are build tools such as JavaScript generated styles that provide dynamic namespaces without the "thinking overhead" that comes with BEM. Styled Components is one such example.

I agree that the use of Bootstrap etc. should not overly affect the approach, but such frameworks have gotten out of flavour as their value has diminished with the introduction of flex-box, css-grid and web components.

[jersiovic]

Sorry, no I never got to finish the tag helpers but I believe that the approach still provides value through abstraction. The issue we had with Orchard 1 was that the admin UI was all over the place with module authors re-creating grids and forms or copying and pasting. This led to inconsistencies and wasted time.

Yes for that purpose tag helpers are justified

BEM, is a naming convention primarily to provide a namespace to components which avoids clashes with another component. This helps when updating the CSS to ensure only that component is affected.

BEM is seen as a work around and is only used in today's world under certain circumstances. There are still valid reasons to use BEM but there are alternatives available.

Web Components (see my 2014 orchard talk) has the shadow dom which eliminates the need fo BEM. If you didn't want to use Web Components (well supported now) there are build tools such as JavaScript generated styles that provide dynamic namespaces without the "thinking overhead" that comes with BEM. Styled Components is one such example.

I agree that the use of Bootstrap etc. should not overly affect the approach, but such frameworks have gotten out of flavour as their value has diminished with the introduction of flex-box, css-grid and web components.

So, we agree that current themes need to be based on any of those solutions. However, at least months ago when I was more in contact with Orchard Core I didn't see movements towards any of those directions. That's why I talked of BEM. But even better would be more advanced solutions like the ones you propose. Is this sth that has changed lately? Is there any intention of changing things on that direction?

[jersiovic]

Lately I have enjoyed with this library https://github.com/OrchardCMS/OrchardCore/issues/2704 that helps to have elements following MVVM pattern using server side Viewmodel that communicates with client side of the element with SignalR in client side. Maybe it is another interesting alternative cause it allows to provide components encapsulating not only client side but also server side within the same component.

[stevetayloruk]

I think that public facing themes should be done however the author want them to be done and their approach should be their own choice and not forced on them by Orchard.

The default admin theme should be easily cloned and modified or overridden. This is where standard css/scss etc. and will help. Dynamically generated class names would make this overriding difficult.

[jersiovic]

For frontend themes same reasonament you give would have been valid to provide not nice and stylish themes with Core. However for Orchard Core themes provided are specially nice and stylish. The reason I guess you did that it is to attract people looking for a CMS to ease most common jobs as having a decent looking web by default.
Problem of offering frontend themes without solving css isolation is you don't save that work to anyone. Because anyone interested on it will need to override ALL the templates of the modules it uses. However if Orchard choose one strategy for those themes at least for those who need it will appreciate Orchard as a very straightforward solution cause save them work because all templates follow convention stablished. Morever if the Orchard conttibutors have this on mind while develop they will provide the needed infrastructure for that by frontend themes. For example when I tried to use BEM with Orchard 1 I found that I needed many changes in the core to support what I needed, cause within a shape I was not able to know within what ancestrors shapes a shape was rendered to decide a BEM class fo a tag.

I agree sth based on React (like Styled Components) or Web Components is too much intrusive for front themes because not everybody will agree with it. That's why I prefer BEM, cause by default it provides a solution by default to the problem but it is easy to ignore those classes for anyone not interested on them. The major con I see of BEM is its verbosity, that's why I prefer a variation like ABEM https://css-tricks.com/abem-useful-adaptation-bem/

So, I think it is better to provide a solution than no solution at all for default frontend themes. And it seems best solution would be the one that less force to anything to other theme devs.