Defining styles based on context [closed] - css

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
}

Related

Angular component styling convention [closed]

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>

Css performance: better to address child elements with tag name or classes? [closed]

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.

BEM Confusions with naming elements [closed]

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.

Is it okay to use css classnames as an id for a module or widget? [closed]

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 read an interesting post on using a css classname instead of the id attribute for identifying modules or widgets. The css classname could be prefixed with a hash or underscore, to indicate that the classname is used as an id. The reason for this being, that ids can only be used once per webpage whereas a module or widget could appear multiple times.
Simple Example
Instead of using ids such as
<div id="currencyConverter1" class="foo">EUR/USD</div>
<div id="currencyConverter2" class="foo">GB/USD</div>
prefixed classnames are used
<div class="#currencyConverter foo">EUR/USD</div>
<div class="#currencyConverter foo">GB/USD</div>
In the article it suggests, that an underscore could be used instead of a hash, because hashes need to be escaped.
I quite like this idea, but I'm not sure if this is good practice or has any drawbacks. What is the general opinion on this?
It doesn't get simpler than this: does it uniquely identify an element within a document tree now and forever? Use an ID. If not, use a class name.
Remember that IDs and classes are properties pertaining to each element, not a group of elements collectively. Using "identifier" to mean "identifying a group of elements" is futile; that's why you have class names instead, to classify those elements as being related in some manner.
If you're "identifying" elements that are members of a specific widget or module, you have free reign to add a class name to each element representing that widget or module, and select it in addition to the element's class:
<div class="my-module foo">.my-module.foo</div>
<div class="my-module bar">.my-module.bar</div>
Or, if specificity is such a huge issue that you can't even afford to stack another class selector to your rules, prefix the element's class name with the name of that module and select it.
<div class="my-module-foo">.my-module-foo</div>
<div class="my-module-bar">.my-module-bar</div>
If that's the question, then yes, it's perfectly legitimate — as I've mentioned, that's the whole point of class names and selectors.
But there are no legitimate benefits to making a class selector "look like" an ID selector without functioning like one. What it does cause, on the other hand, is needless confusion, especially for other authors who may not know better. If you want to avoid ID selectors like the plague, fine, leave them alone; nobody's forcing you to use them. But if you want to uniquely identify singular elements, then you may want to remember that CSS already provides a feature for that to complement the id attribute in HTML, known as the ID selector. There's no need to hack other parts of the selector syntax to emulate some other feature that's already readily available to you and has been since the very beginning.
Incidentally, if you're running into specificity issues with your CSS rules, then it's your CSS rules that need refactoring, not your markup. Hacking your markup to accommodate your style rules only leads to further trouble, at least in my experience. (I understand the irony in saying this given that hashes are allowed in identifiers starting with HTML5.)
Its mostly driven by your own, personal taste. there are a lot of opinions and articles on this topic, even complete books were written.
I suggest the following:
SMACSS
OOCSS
MVCSS
All of them are mentioning a more-or-less similiar naming convention for CSS, while also saying that these are just rules of thumb, not dogmas.
personally, i follow that approach:
.modName // module
.modName__sub // an object or sub-module
.modName__sub--modifier // a modifier
A similiar structure is used for example by InuitCSS
If you want to use classnames as unique identifiers, than just do it, there is nothing wrong about that. Further, it is future proof in case that you wish to use it as a "standard" class. However, i would shirk that hash for obvious reasons.
Not sure what your modules or widgets are for (wordpress?) but the methodology I choose to use when coding is this:
1: If it is DOM element that has a specific function that I know will only appear once on the page, then I use an ID (things like #main_navigation, #global_header).
2: The DOM element is used for styling purposes (CSS) then I use class names. I keep class names as descriptive of what the DOM element is doing as I can. I don't use vauge names like .blue_text (explained below).
3: I need to attach some sort of information to the DOM element that is kind of awkward and doesn't fit this scheme, then I use custom HTML data attributes. For example, if I create a backend for a site and a user can pick a background color for a div, instead of putting .user_selected_background_color_class as a class in the div I will instead write data="user_selected_color". This is a kind of lame example, but I just built something where a user can select a bunch of images to be in gallery mode or slideshow mode and I used data attributes to determine how the container div should be styled.

Why w3c created the property 'style' to determine all properties? [closed]

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.

Resources