Chainable BEM modifiers
And I want to apply this idea to my next project but when I get the check on getbem.com, It says is bad when use modifier alone
Good
<div class="block block--mod">...</div>
<div class="block block--size-big
block--shadow-yes">...</div>
Bad
<div class="block--mod">...</div>
meanwhile, in BEVM idea, we can use modifier alone in an element.
Does anyone have a suggestion?
BEM is against modifiers without block class itself. They are to modify something existing.
There can be quite a lot of different modifiers on a block at the same time (we need to avoid repetition of basic things in each modifier) and they can be added or removed in runtime. So there should always be the entity (block or element) to witch modifiers can be added or from which they can be removed.
For more info please refer to https://en.bem.info/methodology/faq/#how-to-make-global-modifiers-for-blocks
Related
I just wanted to know whether the following code follows BEM methodology best practices? Creating an element for the block modifier i.e. in this case "block--mod" is a modifier for the "block" block. Is it allowed to create a nested element with this pattern: "block--mod__elm".
<div class="block block--mod">
<div class="block__elm block--mod__elm">
</div>
In situations like theming or similar I would use nested selectors. This saves some classes in your HTML and as #Jonathan Nicol said those sub-elements can be hard to follow. Also it will be easier to remove the "branding" later, just remove block class instead of all it's elements.
For example Xmas branding of your header.
.header--xmas .header__logo {
/* Jingle bells, jingle bells, jingle all the way.*/
}
Source: http://getbem.com/faq/#can-a-block-modifier-affect-elements-
I could not find an example of a the .block--mod__elem pattern in Yandex's BEM documentation (Yandex devised the BEM methodology), but an early article about BEM on CSS Wizardry does show an example of a modifier with a sub-element, .person--female__hand:
.person {}
.person__hand {}
.person--female {}
.person--female__hand {}
.person__hand--left {}
Source: MindBEMding – getting your head ’round BEM syntax
Modifiers with sub-elements can be a little hard to follow, but I do not shy away using from them if it seems like the logical approach.
Edit: #NikolayMihaylov's answer gives an alternative approach that I wholeheartedly support. It is more readable and more maintainable.
Why would you use "div class" instead of "div id"
Usually when I name a div I use "id" to give a name to an element and with set parameters. I really only use "class" to give it special characteristics. For my example .
However, I have a professor who will "class" to identify all his divs. For example prof example .
Can someone explain the benefit of something like "div class" instead of "div id".
<div class="some_class">
<p>This can be used any number of times on one HTML page</p>
</div>
<div id="some_id">
<p>This CAN be used multiple times with the same ID,
but it is invalid code, as a specific ID should
only be used ONCE per html page</p>
</div>
Here's an older yet still good explanation.
ID are unique for the page, so it's better for identification.
Class aren't unique and are supposed to be to group similar style things together.
Said otherwise, if you need to apply something to THAT SPECIFIC div, you should call it by the id, because it will take priority over other CSS styles that may affect it.
Classes will allow you to set some common ground in your style so you can use similar fonts or sizes in different kind of elements.
If you are using Javascript there is a big advantage of using classnames to identify elements instead of id's.
Giving an id to an element also creates a global javascript variable with the same name. See Do DOM tree elements with ids become global variables? for more about that behaviour.
Having such implicitly created variables is at best confusing, and at worst leading to hard to find errors.
When using element directives I have seen Angular element directives used in two ways:
1. As block level components
The element is styled as display:block, is the component and its children are the component's children, so the element itself is the component.
Use of directive:
<example class="Example"></example>
The directive's html:
<header class="Example-header"></header>
<img class="Example-image">
<footer class="Example-footer"></footer>
2. As an inline wrapper of the component
The element is left as display:inline and effectively acts as an invisible wrapper for the component itself:
Use of directive:
<example></example>
The directive's html:
<div class="Example">
<header class="Example-header"></header>
<img class="Example-image">
<footer class="Example-footer"></footer>
</div>
Obviously each have advantages and disadvantages for example extra markup, loss of layout context due to inline element etc, but is one the correct way? or is this another of Angular's vagaries?
I'm surprised no one responded, but the idea behind creating custom directives is the ability to create reusable pieces of code that fulfill a specific bit of functionality on your site.
This functionality, however, doesn't care about the styles that you are going to use. You can of course conditionally change classes and styles from within Angular, but the core component when dealing with the framework is the data.
With that being said, there is no "correct way" as you bolded in your question. Develop the directive to fit your needs and style of your site.
First this is probably opinion based but i'd really like to share my point of view about this.
If you really follow angular way of doing directives none of theses are a correct way.
Directives are intended to add a behavior to an HTML element.
The less the directive add HTML the best it is as it allow you to have a better control on this element.
Lets take an exemple.
We have a data grid (let say ui-grid, it doesn't really matter)
<ui-grid ...>
...
</ui-grid>
I had a the idea to add some button to add or remove element in the grid.
I first came up with this
<ui-grid ...>
...
</ui-grid>
<button ng-click="addItem()">Add</button>
<button ng-click="removeItem()">Remove</button>
I'm really happy with this and that's ok, but finally i need to use theses buttons in some other views. I'll have to duplicate the HTML, duplicate the JS and adapt it to the collection.
The common mistake
That's obviously not a good idea.
Instead i will do a directive. Lets say "button-list" : it produce the same html and behavior.
<ui-grid ...>
...
</ui-grid>
<button-list></button-list>
That's pretty cool.
Now i have some need. On one view i need the add button to be blue, on an other one i don't need to have a remove button, and on a last one i want the button text to be "X" and "+" (That's was some request by a client in a true story).
I could make a big object with a list of option and etc... but this is really painful and you need to touch the directive each time you need to add a custom different little behavior.
The good way to go
Now lets just think again about what i wanted to do.
I want the button to interact with the grid... and that's pretty much all. This is how we should go building a custom directive.
We could then produce this directive this way :
<div grid-button-container collection="mycollection">
<ui-grid ...>
...
</ui-grid>
<button grid-add-item>Add</button>
<button grid-remove-item>Remove</button>
</div>
So what do we have here ? We have three different directives.
grid-button-container : Its responsibility is to hold the list for the sub-directives.
grid-add-item : It add a function on click that add an element to the collection of grid-button-container.
grid-remove-item : It add a function on click that remove an element to the collection of grid-button-container.
Both grid-add-item and grid-remove-item will be requiring the grid-button-container to be used.
I cannot describe all the implementation of this (it would take too long) but i think this is how directives should be used. Such as almost no angular build-in directives (ng-*) add HTML and just add a behavior i think all the directives should be build in this way.
Pro :
You have a full control about your HTML
Directives are tiny and trivial
This is really re-usable
Cons :
Can be harder and longer to implement.
To make a final point, the two way you're asking about are just different. No one is better than the other it will just depend on your own HTML organisation and it will depend on the directive use.
Hope it helped.
Usually when i create some HTML template, i tend to prefix and class (or id) everything, This is my way of keeping the markup more readable, and also it makes styling a lot easier.
For example if create a template called MyTemplate, then i prefix all elements like this
<form id="mt-form-blue" class="mt-form">
<input class="mt-input-large" type="text" />
<input class="mt-input-small" type="text" />
</form>`
I've seen lots of HTML templates, where the creators make very little use of classes and ids.
My question is why? Does using many classes and ids, have an impact on the browser performance? Does it have any dangerous side effects?
CSS selector do impact performance, but how much it impact will depend on its complexity and what operators were used. Usually you won't notice such tnings, but there are plenty of researches for this matter on the web.
Regarding the use of selectors, listing only the basic three, the use of them depends on what is your intention, for example:
tag name selector - When you want apply style to every element of this type
class selector - when you want to reuse your style in more than one element
ID selector - when you want to apply your style to only one element per document
Of course, their use is not limited for the list above but I believe it contains the most common use cases.
This should be simple, but I'm having trouble finding the search terms for it.
Let's say I have this:
<div class="a c">Foo</div>
<div class="b c">Bar</div>
In CSS, how can I create a selector that matches something that matches "(.a or .b) and .c"?
I know I could do this:
.a.c,.b.c {
/* CSS stuff */
}
But, assuming I'm going to have to do this sort of logic a lot, with a variety of logical combinations, is there a better syntax?
is there a better syntax?
No. CSS' or operator (,) does not permit groupings. It's essentially the lowest-precedence logical operator in selectors, so you must use .a.c,.b.c.
Not yet, but there is the experimental :is() (formerly :matches()) pseudo-class selector that does just that:
:is(.a .b) .c {
/* style properties go here */
}
You can find more info on it here and here. Currently, most browsers support its initial version :any(), which works the same way, but will be replaced by :is(). We just have to wait a little more before using this everywhere (I surely will).
For those reading this >= 2021:
I found success using the :is() selector:
*:is(.a, .b).c{...}
If you have this:
<div class="a x">Foo</div>
<div class="b x">Bar</div>
<div class="c x">Baz</div>
And you only want to select the elements which have .x and (.a or .b), you could write:
.x:not(.c) { ... }
but that's convenient only when you have three "sub-classes" and you want to select two of them.
Selecting only one sub-class (for instance .a): .a.x
Selecting two sub-classes (for instance .a and .b): .x:not(.c)
Selecting all three sub-classes: .x
No. Standard CSS does not provide the kind of thing you're looking for.
However, you might want to look into LESS and SASS.
These are two projects which aim to extend default CSS syntax by introducing additional features, including variables, nested rules, and other enhancements.
They allow you to write much more structured CSS code, and either of them will almost certainly solve your particular use case.
Of course, none of the browsers support their extended syntax (especially since the two projects each have different syntax and features), but what they do is provide a "compiler" which converts your LESS or SASS code into standard CSS, which you can then deploy on your site.