bem elements rules say.
Create an element
If a section of code can't be used separately without the parent entity (the block).
The exception is elements that must be divided into smaller parts – subelements – in order to simplify development. In the BEM methodology, you can't create elements of elements. In a case like this, instead of creating an element, you need to create a service block.
Question: can anyone tell me the meaning of service block in BEM?
Related
After carefully reading all related articles and posts on many sites, there is still one remaining question: Can i have a single, exchangeable CSS for a web app built with web components widhtout having to deal with all the weird stuff suggested by W3C?
I know about ::part( something ) and exportparts="something" to access nested components, but that does not go down the tree, so I have to add a part attribute to almost every element, which totally bloats my HTML.
Having an #import rule in each component is also not a great option, because it would be one more HTTP request per stylesheet. Also, once loaded in a template, the importet css can not be exchanged easily.
W3C really makes our lives harder by removing /deep/ and ::shadow. I know, performance concerns, blah, blah, but at least that worked like a charm.
Possible solutions I find impractical:
How to style slotted parts from the parent downwards
::slotted CSS selector for nested children in shadowDOM slot
How to access elements inner two shadow dom
Example HTML where all nested elements would be styleable with global CSS:
<body>
<o-app>
#shadowDOM
<o-header exportparts="username:o-textinput__username,action-ok:o-action__action-ok,o-action__label" part="o-header">
#shadowDOM
<o-texinput part="username">
<o-action exportparts="label:o-action__label" part="action-ok">
#shadowDOM
<div part="label">
Then I can finally style the label div by selecting it with:
::part( o-action__label ) {}
Now tell me that having to specify every single part of all descendant elements in the parent elements is not a total mess!
Playaround on Codepen: https://codepen.io/5180/pen/jOyQNYq?editors=1111
Now in 2021 I would rather use light DOM only instead of forcing the shadow DOM to behave like its counterpart, because there is currently no easy method of piercing through the artificial boundary. It was in the spec – ::shadow and /deep/ – but got removed, so deal with it. ::theme() is not ready yet, The ::part() selector is useless for deep styling as I pointed out in my example.
Just use the light DOM (innerHTML) of your custom element to avoid deep styling/theming issues.
The div element is known to be a generic container, what is exactly meant be the term generic container in HTML5?
It's a container with no special purpose.
It carries no semantics (unlike a section or a main or a fieldset etc).
of, applicable to, or referring to all the members of a genus, class, group, or kind; general.
A div has nothing that every other container does not have (but the reverse is not true).
Generic containers are just containers that serve no special purpose. Mostly a style attribute is bounded to a generic container for specifying the rendering or using a CSS rule.
The only generic containers are <div> and <span>.
Technically speaking, they could be used to organize webpages into multiple different "sections" defined with classes and attributes.
Semantic markup
"Good" HTML code is semantic.
In the current context it means, that you wrap the content of your webpage / webapp into containers which are designed to contain that specific piece of content.
For example, headers typically are semantically correctly coded into <header> tags, articles in <article>, so on and so forth.
DIV as a Jolly Joker
Whenever you don't have a generic block level container at your disposal, you encapsulate the content you want to render in a div. It's usually the "last resort" tag you use when you run out of options.
One more thing
As <div> is the jolly joker of block level elements (panels, GUI control containers, etc.) the <span> tag is the jully joker of inline elements
Id say they typically just are simple holders that kinda define whats inside of them. They just hold stuff. Like a div typically is containing elements that go together. Like if you wanted to have a navigation bar, you can put all the elements that make it into a div and give that div an id or class of 'nav'. Keeps things nice and organized.
I am trying to understand the purpose of the section and found the following article:
The section element is not a generic container element. Now I know
what it says. It says above that it represents a generic section of a
document. When people write specifications, sometimes they get vague.
It is not a generic container.
When an element is needed only for styling purposes or as a
convenience for scripting, things like JavaScript, authors are
encouraged to use the div element, which we'll talk about in just a
little bit. So a general rule is that the section element is
appropriate only if the elements contents would be listed explicitly
in the documents outline and that's where it reaches the sweet spot.
When you have content that needs to be listed in the document outline
but it doesn't meet the standard of being syndicated or pushed apart
by itself, then that's when the section element is probably
appropriate.
The questions are:
What is a generic container?
What does he mean with styling purposes
or as a convenience for scripting?
What is a generic container?
An element that can be used as a containing element for any arbitrary content, in any arbitrary context. E.g. div is the most generic container there is, because it does not carry any meaning in itself whatsoever. section does have a specific meaning, so shouldn't be used arbitrarily.
What does he mean with styling purposes or as a convenience for scripting?
When you want to style specific elements or you want to programmatically access specific elements via Javascript, you need some hook for that element. E.g., styling the eighteenth word in this sentence is pretty difficult, but becomes much easier when you <span>wrap</span> it in something. Now you can use span { color: red } or document.getElementsByTagName('span') to do something with that element.
I recently started using BEM for writing reusable CSS components. In the BEM documentation and other websites I found that global resets on tag elements are not encouraged for obvious reasons.
However when I look at source code of BEM based websites including the BEM documentation websites, I usually see p tags classless, meaning they do use resets or nested selectors to give them the proper font size or margin for instance.
Consequently, I am confused about what approach to follow now. In my reckoning, creating a paragraph class and attaching it to p tags would be the correct approach in this case. Further positioning could be resolved by implementing additional layout components to set the desired margins?
Any advice? Thanks in advance?
My understanding is that a css reset is not required because essentially every block or element has a class on with a specificity set to 010. Therefore this overrides any css including the browsers own css file that only has a specificity set to 001 on the element.
Take the following structure:
<div class='article article--yellow'>
<div class='article__headline'>...</div>
</div>
<div class='article article--blue'>
<div class='article__headline'>...</div>
</div>
If I need to make article__headline different for --yellow from --blue, should I do a CSS selector like:
.article--yellow .article__headline { ... }
Or, in the practice of minimizing selection-depth, is it valid BEM syntax to change the markup to this:
<div class='article article--yellow'>
<div class='article--yellow__headline'>...</div>
</div>
Because then I could select it using only 1 selector: article--yellow__headline.
I know that technically it would work, but I can't figure out if this is valid according to BEM methodology or not.
This is a perfect question and bem's faq actually answered it!
Can a block modifier affect elements?
If I have a block modifier, for
example xmas, and I want the elements within that block to also be
xmas themed, how would it be best to do it.
Does a --xmas suffix for every element seem necessary? Or would this
be the one use-case for nesting (e.g. block--xmas block__elem { ...
} ?
However in general BEM recommends to avoid nested selectors, this
is the case when they are reasonable.
When creating the nested selector, you declare that one entity depends
on another. As BEM introduces independent components, such an approach
is not suggested when we are speaking about 2 different blocks.
But when it comes to a block and its element, they are not of
equivalent meaning. By it definition, an element does not make any
sense outside its parent block. So, an element is a block-dependent
entity. Assuming this, it is quite normal and logical that an element
is affected by the block's current state.
So, this is quite a pattern in BEM to code
.my-block--xmas .my-block__button {
/* Jingle bells, jingle bells, jingle all the way.*/ }
So the answer should be your first approach
.article--yellow .article__headline { ... }
I don't think that two levels is too deep to assign specificity of .article--yellow .article__headline. Technically, .article__headline will never occur without an .article--yellow color modifier anyway.
Although the class names get lengthy, BEM allows you to easily-self document (assuming whoever comes after you understands these concepts too). Also, to me BEM components are not supposed to influence each other, as detailed here.