Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have been using BEM on a project at work for keeping my CSS more modular and come across a few situations I feel a need for a bit of clarification on:
Context dependent styles. I keep coming across a need to change a style of a module/component dependent upon a class on a parent item.
Say I am style a product list. I have my .product-list component and inside that all my .product-list__item's. The .product-list__item's then might have an <h3> inside as the product title.
My questions are:
Should the .product-list__item also have a class of .item?
Should the title inside the product have the following classes:
.item__title ?
.product-list__item__title ?
Say the item also had a description box within and that contained the price:
Should the description have:
.item__description ?
.product-list__item__description ?
Should the price have:
.item__description__price ?
.description__price ?
.price ?
I do subcomponents sort of need their own component name added separatley ie: .item or .description. I'm guessing that they need them as where else do they get their styling applied?
Also, If I had the above I would have a .product-list component whcihsounds fine but if sub components have their own component name added as a class such as .item then that is not very descriptive of itself is it?
I know thei may sound complicated but I am serious about being confused here and would love to hear your opinions. I ahve read a ton of articles on BEM and not one explains this sort of thing.
Neil
According to BEM methodology there are no elements of elements so instead of product-list__item__title you should use product-list__item-title.
As for context dependent styles you can use either cascade (and place styles to parent file) or mix as in your examples. Rule is simple: as soon as you find yourself using some item somewhere without its parent block — make it separate block and use mixes but if items are absolutely useless without parent using cascade makes more sense.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
Suppose I have to create the below layout :-
I can write all the <card> specific styles in the card.component.css. But as you can see in the image, each <card> has a specific width. How and where do I set this style?
Should I do something like this in the parent.component.css ?
card{
width: 200px;
}
Are there any alternatives? Does there exists a method to style the component in the card.component.css itself? What is the recommended method to do something like this? Should I even directly style the <card> tag?
I know that this is a opinion based question, but clear and well defined conventions and mental models can help beginners like me a lot.
Should I do something like this?
Yes why not? Maybe use % values as width in order to be flexible, also you might want to use flexbox in your parent.component.css if you want to ensure adaptability to screen width.
Are there alternatives?
Yes there are alternatives you could use Imports like the other answer explained. Or Define a different style URL in the StyleURL of the card component see here Angular CSS Component Styles. And there are probably more alternatives.
What is the recommended method to do something like this? Should I even directly style the tag?
The idea behind the components is of course that a style class should style all elements with the same style. From your picture I would assume the style of the card tag is the same therefore one should use the parent.component.css to style these elements. Regarding the second part you might want to read about ngClass I would use div container and not style elements directly, since I encountered misbehaving of elements with direct styling.
You could pass a specfic width to the card component from the parent and inside the card component use ng style binding.
So, in your card component. the html will look something like this:
<div [style.width.px]="width">some texts </div>
and in the card component ts you'll have a width property with the #Input decorator:
#Input() width: number;
In the Parent component, you may pass specific width based on index. for example, in this script i pass the width for each component multiplied by the current card index.
<card *ngFor="let c of cards; let i = index" width="index * 200"></card>
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
Instead of giving a background-color, border, etc. to each element, I decided to make a list of classes like red-background, blue-text, border-1px and others ...
Is it fine to do this or not. If not how I should then?
Example
Thanks for answers, I was just unsure about if I'm doing well or not. I will try to give a better naming.
That type of approach is called utility-classes and has been greatly spread by Tailwind CSS framework. Which makes use of small descriptive classes instead of already made and opinionated component classes like the ones from Bootstrap.
This approach has the multiple pros, like simplicity, composability, and reusability.
But they will also probably make your classes be really long for each of your html tags.
There is nothing wrong with this, it's a matter of what works best for you.
Some css libraries or frameworks use approaches like that.
For instance in bootstrap you can use hidden to hide an element via the display: none; prop.
This is refered in some places as utility/helper classes.
That's a good idea and a good approach to have several classes. But from the naming perspective, that's better to use names that will describe the behavior, instead of color or border with. Declarative vs imperative. For example instead of blue-text is better to use common-text, because your blue can easily become green/black gray later.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
In any modern browser (post IE 8), is there any reason to use CSS classes at all anymore, rather than just always use an attribute selector?
I bring this up because I'm working with AngularJS code, which is very attribute-driven, and I've found myself writing styles solely based on attributes rather than using classes, but that's not the norm and I'm wondering if there's a reason why.
Is there a hidden difference between the two that causes people to still use classes instead of attributes?
Syntax: I would argue that <bar foo> and <bar class="foo"> are roughly equivalent: both declared in the markup, both accessible to modify (add/remove) by JS, both have the same name structure. Similarly, [foo]{} and .foo{} are all but equal.
Both classes and attributes have the same specificity, so CSS weights them the same.
I have not been able to find sources citing performance concerns one way or the other.
So why are classes still around, when attributes already exist? Is it just because they were there first and have stuck around?
I would consider selector speed to be a pretty concrete reason.
http://jsperf.com/attribute-vs-class-selectors
You're looking at this from a specific machine readability standpoint, but not from a human readability one.
Let's assume someone is working with a team of developers and designers on a project. Assigning a class to an element tells the human readers of the code that those elements belong to a certain group and that the group they belong to should have, relatively, the same styles. This makes referencing, maintaining and updating CSS style much simpler and faster.
[attributes] on the other hand, are almost like an inversion of a class. The element doesn't belong to the [attribute] like it belongs to a class, the [attribute] belongs to the element.
#Diodeus answer provides very concrete evidence when it comes to benchmarks, which IMO is the most important factor here, but don't forget about semantics either.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I understand the basic concept of contextual styling and why you would want to define styles based upon parents and siblings. But in some instances it seems like this simply adds additional css which I hate having to write unless necessary. Take this for example. Say I have a red button on my site that I define as:
.button.red{
background-color: #ff0000;
color: #fff;
}
Hence, I can place the following code anywhere:
<button class="button red">submit</button>
But I've heard that it is best practice remove a "red" or "green" style from your html and use contextual styling. But this would lead to a ton of additional css to write each red or green button based on it's parent. Can anybody shed some light on why you want to do this or is this not necessarily best practice.
Okay, I think there's something that needs to be cleared up first, and that's semantic styling. What you're doing here is just applying a static style to a button, which is fine, but the name you've given it is very specific. You're saying that some buttons will be red, and naming them as such.
But further down the line, what if you decide that type of button should be blue? Or green? What you should do instead is use a class name which explains why you're styling this button. Think of it in terms of, it's not that all of your red buttons are primary actions, it's that your primary action buttons are red. So to steal from Bootstrap's terminology, you wouldn't give that the classes of "button red" but rather the classes of "button primary" or "button error"--something to illustrate the meaning of what you're actually trying to accomplish.
This has later benefits as well, letting you do things such as declare that "all primary buttons within a popup container will be green"
.popup .button.primary {}
This sort of separation makes things look much nicer in your code and lets you start general and become more specific with your rules as your needs become more specific, which is helpful from both a programmatic and a stylistic standpoint.
The rationale for this guide line is that there must be some reason why you want your button to be red, or why you want your paragraph indented, or why your list should be spaced out.
The HTML simply reads so much better when the text in the class attribute say what the fragment of HTML is describing. The idea of separation of concerns, a very well accepted practice dictates that
HTML should contain structural information only
CSS should contain presentational information only
Scripts should contain interactive information only
HTML with colors violates this practice.
In practice, there is probably no reason why your CSS should blow up in size. You can always say
button.warning, p.notice, ul.stop {
color: red
}
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I've read that type of selectors used in JavaScript (jQuery as well) matters if one wants to achieve better performance in speed, loading times, etc.
Does the same apply to CSS as well? If so which selector is better to use in DOM: id, class, or maybe nested? I'm talking certain elements here (like a specific <ul> and not all <ul>s in general).
I doubt it CSS could cause great rendering troubles in loading time and speed.
In my experience I've come to the conclusion you should keep your CSS nice and simple. I've seen things like:
.element1 {...}
.element1 #element2 {...}
.element1 #element2 .element3 {...}
But I'd rather go with unique selectors wherever possible and simply describe them as:
.element1 {...}
#element2 {....}
In my opinion optimizing CSS is quite tricky and you should do it carefully.
as I have read many times IDs are faster for finding elements than classes as elements with ID are stored as a hash table and the search is faster.
Unfortunately I don't know any resource to prove or reject this, but as I have already said I have seen this kind of statements a lot.
Two HTML elements on a page can not have same id so for single element handling it is good to use ID..
Same class can be used by many elements so for group operations it is good to use class..
In performance wise both works good for me