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>
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 4 years ago.
Improve this question
I am using scss. I would like to know which method have best performances between addressing the child elements with their tag name or instancing new classes, and also which method is considered best practice:
.product{
&__image{}
&__header{}
}
.product{
img{}
h5{}
}
<div class="product">
<img class="product__image" src="" alt="">
<h5 class="product__header"> </h5>
</div>
It all depends on your HTML. Do you really need a class for every element?
My main rule of thumb is: if I need to style multiple items in a similar way and they are semantically or structurally related, add a class. In such a case, you would then simply use the class in your CSS to target all the elements.
.profile-pictures {max-width: 67%;}
However, if the elements are not related in any way or you are only targeting a single element, just use the tagname.
header h1, figcaption {text-align: center;}
The important part here is semantics. HTML5 is all about the linked web. Not only the relations between web pages, but also the clear structure of a single web page. In my opinion, semantically clear tags are part of that. A fellow developer should be able to read your code and get a feeling about the structure and make-up without actually seeing the result in a browser.
This also means that I am not at all a fan of classes such as product__image, because it is derived from a class and a tag. So how does it differ from .product img? Leaving specificity aside, it doesn't - but it does involve a lot of overhead HTML that you actually don't need. In my humble opinion, these kind of classes bloat your HTML into an unreadable, redundant mess.
To conclude and to summarise: stick to CSS selectors and class names where they make sense semantically. Group elements with classes where it is semantically or structurally an obvious choice. Do not bloat your HTML with classes for every element. Remember the 2005 cliché, less is more.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions concerning problems with code you've written must describe the specific problem — and include valid code to reproduce it — in the question itself. See SSCCE.org for guidance.
Closed 9 years ago.
Improve this question
I created a solution, stuck in jquery ui to do some slider bars which work and look great.
I popped an accordion onto a page and the CSS for it is awful. But I have no idea how to replace it with my own CSS, as it seems to use an absolute TON of CSS classes and overriding them all seems very messy.
Presumably picking and choosing styles and themes with JQuery UI is a common task, is there a best practice for this?
I'm thinking perhaps you can get the individual component CSS and pre-compile it or similar. But there seem to be many common CSS styles that are applied by jquery ui.
For example, an accordion has these classes automatically applied:
ui-accordion-content ui-helper-reset ui-widget-content ui-corner-bottom ui-accordion-content-active
I can see that two contain the word 'accordion' and so you can imagine 'overriding' (or should that be removing the code from the jqueryui css and putting it into my own css class?) them without issue, but the others are buried in jquery ui and overriding them globally would likely cause issues.
My goal is to completely customise the accordion control with my own CSS while not affecting any other jquery ui component.
You need to re-declare the same in your stylesheet at the end of all the other styles and set to your custom values that you want to override. After doing that, re-declare that css file at the end of the page. Hope this helps.
If you want to keep the original style as it is then wrap one div around your accordion and inherit the css as you want. Anytime you can remove that class from div to get the default jquery accordion. like:
<div class='someClass'>
<div class='ui-accordion-content ui-helper-reset ui-widget-content ui-corner-bottom ui-accordion-content-active'></div>
</div>
CSS would be like this:
.someClass .ui-accordion-content { /* your necessary styles */ }
Both above answers seem to fit your needs, in the interest of completeness though you could also over-ride the css using jQuery simply picking out the elements that you're not happy with, e.g.
$(".ui-accordion-content").css("color", "#FFF");
Might be simpler than digging it out in the jquery-ui css or re-declaring if you're only looking to change one or two items.
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.
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 9 years ago.
Improve this question
I would like to know why they created the property style for all properties instead of create a new property for each one?
Let me explain better, today we use this:
<p style="color:blue; background-color:red"></p>
I would like to know why they didn't do like that:
<p color="blue" background_color="red"></p>
Is there something in any w3c document telling it?
My theory, based on logic... Something like color="blue" is not CSS, it would inherently be part of the HTML language.
With CSS in the picture, there is no reason to expand on HTML to handle something that HTML was never designed to handle. And so they made a way for HTML to read and understand CSS. Hence the style="" property.
Why create something that is redundant when you can simply adapt to read what already exists?
That said, you used to be able to use things such as the <font> tag to recolor or resize text, such as <font color="blue">
As CSS becomes more and more powerful and expansive, there is no need to implement this type of styling, thus why the tag is now deprecated in HTML5.
Beyond all reasoning there is a clear logical point, which is for each type of code to serve its particular purpose. While they allow you to insert CSS into HTML inline by using the style="" property, it is not best practice and should be used in extreme and unique cases.
Thanks to the style attribute, the development of new CSS properties doesn’t require an update to the HTML specifications.
If we’d have a separate HTML attribute for each CSS property, all these attributes would have to be defined in the HTML spec. So whenever a new CSS property is defined, all HTML specs would have to be updated. Otherwise this new CSS couldn’t be used in older HTML versions (validly).
In the same sense HTML doesn’t define graphic formats (like PNG) or codecs for audio/video, or the content of math or svg.
So CSS and HTML developers can work separately from one another, as long as they respect the interface they agreed on: the style attribute (and the other ways to add CSS for HTML).
Another reason: It would be possible that other styling methods come up in the future, not compatible to CSS. Now when everyone would get their own attributes, that would become a total mess.
I'm unable to point to where in the spec this is detailed, but I'll include my understanding.
I believe the intent was to promote separation of style from content. The style attribute was introduce to allow for inline element styling, but the intended approach to styling was to do so using classes and external CSS. This allows for reduced document size, as well as a generic content-only approach which allows for, among other things, a simple approach to theming.
style may also have been included to address situations where referencing an external stylesheet is either impractical or impossible.
Because as much as possible, the w3c is trying to abstract presentation (CSS) from structure (HTML) .. and if there are new properties created (attributes really) it would obscure the mark-up as well as making it more confusing (and harder to debug)
Its always best practice to use an external stylesheet whenever possible.