Bootstrap and mockup

Plone Support
1

Hi all,

Currently mockup mixes a decent amount of bootstrap css and class names into the default patterns.

Bootstrap IMO, is fine. It allows us to develop quickly. The problem is that we re-use bootstrap class names and our styles will likely conflict with other frameworks used.

So to fix, do we change all usage of bootstrap css class names in plone to be prefixed with "plone-"? Or we do namespace the styles out so that every bootstrap style is include inside the .pat-pattername container prefix?

Option one example:

.plone-btn{
  /* bootstrap styles */
}

option two example:

.pat-patternname{
  .btn{
    /* bootstrap styles */
  }
}

I like the first option but option two would be easier.

Anyone willing to take this effort up in mockup? Otherwise, I might have time to work on it eventually--I have some other things I need to do first though.

Thanks,
Nathan

2

More options:

  1. With less, we can do something like:

    .plone-btn {
    .btn;
    }

and it should get all of the .btn style definitions by less inheritance.

but to wrap all this is a cumbersome task. also, we will get into troubles with a new bootstrap version, where some classes may be added or changed somehow else.

  1. What about a sed-grunt-task in mockup, which adds to all of the bootstrap classes the .plone- prefix?
    Also bad, as we would need to include another bootstrap library for addons, which rely on stock bootstrap.

  2. Better not relying on bootstrap classes at all, but doing less inheritance of bootstrap classes to own selectors. E.g:

    .pat-patternname {
    button, input[type='button'] {
    btn;
    }
    }

Or even more generic:

button, input[type='button'] {
    btn;
}

Still cumbersome, but maybe to most flexible option?

3

Hey,

I recently formalised some of my thoughts on [not] using Bootstrap.
However, if you do I recommend creating your /own/ class structure (
http://bem.info/ seems a good structure) and @extending (I have a
preference for SASS) Bootstrap classes, as previously suggested:

/http://fourword.fourkitchens.com/article/you-dont-need-bootstrap/

  * /Antipatterns ~
    http://ruby.bvision.com/blog/please-stop-embedding-bootstrap-classes-in-your-html/
  * /Create code, rather than overriding it/
  * /Bootstrap for prototyping, interaction inspiration and perhaps
    CSS architecture; but nothing more/


/http://matthewcopeland.me/blog/2013/11/04/bootstrap-bankruptcy//

  * /"In this analogy, bankruptcy is the point at which the value
    gained from the custom interface is less than the effort
    required to refactor bootstrap and implement the new interface."/
  * /"Few buy furniture by the lot. You find one or two pieces that
    you really want and slowly update your room over time. Great UI
    tends to evolve the same way. Through feedback and analytics you
    can evolve your UI to fit the needs of the customer and the
    product."/


/http://ruby.bvision.com/blog/please-stop-embedding-bootstrap-classes-in-your-html/

  * /Antipatterns ~
    http://fourword.fourkitchens.com/article/you-dont-need-bootstrap/
  * /"The second problem is this: by hard-coding Bootstrap's class
    names into your HTML, you're marrying your code to Bootstrap.
    Bootstrap's very name should indicate that developers should
    consider it a starter library: something to get you out the gate
    faster, not your permanent design solution."/


/http://yycjs.com/not-bootstrap/#/welcome/

/https://coderwall.com/p/wixovg/

  * /"Bootstrap seems to have become less prescriptive over time,
    but I also prefer Foundation for the reasons you've gone
    through, here - better integration with Sass and encouragement
    form the devs that you use @extend to build out your own classes."/


/https://medium.com/@felippenardi/top-5-core-differences-between-bootstrap-3-and-foundation-5-8b3812c7007c/

Regards,

4

hey, great read!
that confirms our concerns about waving bootstrap too much into plone. we have to change it.

5

I totally agree with this approach. We cannot allow ourselfs to be lazy and just reuse the classes of a specific framework. This framework can in the future change those classes and left us in a state with an outdated markup.

By using our own classes also will allow the use of other frameworks and the ability to extend the original theme easily. I'm in with the first suggestion, the use of "plone-" classes and the extend the original ones. In fact, I think that Albert has been using this approach in some parts of plone.css and Barceloneta.

We need to discuss this and get into a consensus at the Plone Conf. Open Space anyone?

6

Great read @ldexterldesign ,
I also agree with that. LESS also allows the .extend() directive and it's far better than the nested one since it does not duplicate CSS. We tried to use this in Barceloneta and the @import (reference) X for not to repeat CSS everywhere. However, I think we are still importing too much Bootstrap default styling that we are actually not using. Having it there just in case people might be able to use it it's not enough reason to keep it there.

I'm ok with the use of BEM, or BEMish approach but not to stick to it as a religion, just as a reference to make things consistent.

7

Yes, frameworks are faster than us and this could be a problem in a near future.
I understand that now we have nothing to replace properly bootstrap but we can create those files on demand, or the developer itself can copy the used behaviors on a LESS file.

About BEM, I like the approach but keeping it simple with just a "-" between class parts always because then people don't know the behavior. We can make a deep search on Plone files and replace old camelCase classes for new-classes with a better naming. For example buttons context, standalone and destructive to button-primary, button-secondary, button-danger or formHelp to just form-help.
It is hard but we already do it with DL DT DD...

8

for reference, another great resource for css best practice: http://thesassway.com/
e.g. http://thesassway.com/beginner/the-inception-rule

via @ldexterldesign

(i started to use this thread as link collection for css best practice articles, so nevermind this post)

9

People interested in mockup/patterns in Plone: JC Brand started a new list. Send a mail to plone.mockup@librelist.com to sign up. The intro mail is here: http://librelist.com/browser//plone.mockup/2014/12/20/patterns-and-mockup/

10

Hey,

Thanks Johannes :slight_smile:

One useful http://thesassway.com/beginner/the-inception-rule observation
is it harmoniously takes care of BEM (
http://csswizardry.com/2013/01/mindbemding-getting-your-head-round-bem-syntax/
) scope, which – in my experience – is the hardest part of front end
architecture ~
https://twitter.com/ldexterldesign/status/519920873193869312
https://twitter.com/ldexterldesign/status/528633158821249024

Using BEM class names you have 3 parts:

  1. Block
  2. Element
  3. Modifier

The SASS Inception Rule specifies "don’t go more than four levels deep".
Guess what: I use three.

Either of these examples is acceptable (but really there's no reason to
nest these selectors). We're in total control of scope at all times:

.block {
   color: red;

   .block__element {
     color: orange;

.block__element--modifier {
       color: yellow;
     }
   }
}

.block {
   color: red;
}

.block__element {
   color: orange;
}

.block__element--modifier {
   color: yellow;
}

Here are some very influential/smart front end/CSS people from my feed/s:

Soak it up :wink:

Regards,

11

In general we use class name to evaluate bootstrap for the page.To change the css style through class name mentioned in sector.We start with renaming “our” offending classes, then we switch to those inside the plugins / modules / libraries trying to make everything work togheter without hassles. Is that a good approach? For a very small website, maybe. But if we’re talking about a decently-sized project we can say it’s definitely a no-go.Android training in chennai