This question already has an answer here:
Is it possible to use CSS vars in CSS3 selectors?
(1 answer)
Closed 7 years ago.
Keep in mind that this is not a duplicated question, to probe it go and read the http://www.w3.org/TR/css-variables/ if you read it says:
This version: http://www.w3.org/TR/2015/CR-css-variables-1-20151203/ If you read the date it says that is from 2015/12/03 so it's very recent, probably there is the confussion. The question that it says that was asked first does not work in the same way and was asked two years ago, e.g.(it uses a prefix -webkit- so it means that it wont work in all browsers that support the Native CSS Variables) The kind of variables i'm talking is something new, to understand why am i saying this, you need to read the articles of the links below, also my question cover another things that aren't answered in the question that was asked two years ago.
Also the second question below is updated now.
Maybe some people already know that there is a new implementation of variables for CSS, they bring a whole new way to write CSS code, at this moment the browser support is very low, but this have a great future.
I had read some information that explains more about CSS variables, so if you need info about it:
http://philipwalton.com/articles/why-im-excited-about-native-css-variables/
https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_variables
http://www.w3.org/TR/css-variables/
There are a few things that i still don't have clear:
Is there another method to change the values of a variable, that not be the media queries? e.g. using :hover or javascript?
Can i use variables to define Selectors?
Is there another method to change the values of a variable, that not
be the media queries and selectors?
I assume you mean changing the value of a CSS variable outside of a rule set.
Yes, you can. You can assign a CSS variable through the style property and the setProperty or setPropertyValue methods.
document.body.style.setProperty('--bg', 'red');
body {
background: var(--bg);
}
Can i use variables to define Selectors?
No. It wouldn't make sense to do so: from which element should it retrieve the value of the variable? Using variable values in properties could make more sense, but you can't neither.
To retrieve the value of a CSS variable you can only use var(), which can only be used in values.
The value of a custom property can be substituted into the value of another property with the var() function.
Related
This question already has answers here:
What is the difference between id and class in CSS, and when should I use them? [duplicate]
(15 answers)
Closed 7 years ago.
So I often use a website LiveWeave.com to test HTML, CSS, and JavaScript code that I've written. It has a syntax checker, and whenever I use an ID as a selector in the CSS section, it says that it is improper to use an ID as a selector.
I have demonstrated it in this Weaver. To the right of line three in the CSS window is a yellow icon, which, when hovered over, says that it is improper to use IDs as a selector. I was under the impression that that is specifically for the purpose of being used as a selector for a single DOM element, as opposed to classes, which are designed to be applied to multiple DOM elements.
Am I wrong? IS it improper to use an ID as a selector?
The only other instance I can think of an ID being used is for JavaScript document.getElementById(), and similar functions. What is the proper use of an ID?
Note that I am NOT asking the difference between an ID and a Class, but rather whether it is proper to use an ID as a selector.
Using an ID is the most efficient way of selecting a DOM node in both CSS and Javascript. I personally like to use classes for all repeated items and ids for unique items, or unique configurations of repeated modules. There are many CSS patterns, I use a style called BEM (Block, Element, Modifier as seen here) which is a class based naming convention. Look at your favorite websites, right click or inspect. You will find that there is no one right answer to your question, only many right answers.
May I also say that both exist in the standard for a reason and serve a purpose depending on your applications needs.
Below is the order of efficiency for selectors. IDs are the most efficient and pseudo classes and pseudo elements are the least efficient.
id (#myid)
class (.myclass)
tag (div, h1, p)
adjacent sibling (h1 + p)
child (ul > li)
descendent (li a)
universal (*)
attribute (a[rel=”external”])
pseudo-class and pseudo element (a:hover, li:first)
See here...
It is not improper to use ID's as selectors, so long as the ID being used corresponds to only one element in the DOM (document object model).
If you'd like a selector that is multi-purpose, and able to be applied to multiple elements in the DOM, use a class. Although I'm sure you knew that.
The main reason ID's are frowned upon by some CSS developers, and full stack designers, is simply because they aren't as versatile and they have a higher specificity than classes, which can either help or hinder development (based on CSS knowledge).
For more information on CSS specificity, read here: https://css-tricks.com/specifics-on-css-specificity/
It's valid, it's just considered bad practice by some developers because it can make it difficult to maintain your CSS if you're not disciplined about it. I'm no expert on CSS but I'm pretty sure it's all to do with #'s having a really high specificity rating and if you have them dotted around your CSS files it makes it difficult to manage the cascade i.e. inheritance of style rules. So it's considered best by some to use IDs only for referencing elements in your JavaScript.
I've actually heard this argument before.
Some people push the idea of using solely classes for pure css stuff and keeping id for javascript and other id specific functionality.
It would seem that website follows that ideology, so they are trying to get their users to adopt it. I'm not sure if it is yet best practice to keep id out of css
You can decide for yourself whether an id is worth using, when you could just use a class instead.
If you used an ID as a selector and your using it in your Javascript too then you could make situation where if you decide to rename it then you've created a dependency that wouldn't be there if you had used a class name in your CSS.
Also, though using the ID is faster, it isn't faster if you then use #text a - since CSS reads right to left and has to check all the anchor elements first and then find the one with the ID of #text.
This also means the style isn't reusable and you can't use multiple classes either.
So I think the answer really is, based on all the pros and cons of using an ID as the selector, the best practice to keep you out of possible future problems is to not do it. Of course, this all really depends on how you code, the scope of the project and how many other people are working in the project. It's not against the rules, just not really best practice due to possible issues you might be building in that could bite you later.
On top of what has already been mentioned, even in CSS, ID's can be useful depending on what is the structural design.
For example; if every page in your website requires a header and a footer, I don't see why it would not be useful to make it an id.
What is wrong with doing:
#header {}
#footer {}
If you know for sure that your page has only one header and one footer, I don't see the point in using a class.
Mentioning the id is very specific and the page structure is undubious in this case.
Moreover, I also don't see what is wrong by doing something for example like:
.menu{}
#header .menu li{}
#footer .menu li{}
To add specific styling depending on the page segment. Seems very legit to me.
Ultimately, I even think that using ID's to indicate page sections might be more beneficial by ´knowing´ that they are unique (although they might be recurrent across different pages).
Reading an id in a CSS file should give the CSS designer the benefit of immediately knowing what page segment the following css rules are referring to.
A sheet with only classes would in that case seem less clear than using ID's imo.
This question already has answers here:
What does !default in a css property value mean?
(5 answers)
Closed 9 years ago.
Example:
$link-color: $mycolor !default;
I have a theory, but I want to validate it here.
I know that initial is used to set an attribute back to the browsers default. Using !default overrides the browser's native default value and replaces $link-color with the value of $mycolor from the example above.
Am I understanding that correctly?
Attempts at googling this question has lead me to many blog posts about the bootstrap and foundation frameworks, but I have not found a straightforward answer to what !default specifically does. I'm guessing because google ignores the bang (!) so it looks like I'm asking about some other kind of default value.
Thanks
!default is part of Sass' variables handling. The generated CSS which reaches the browser will never contain "!default".
Quoting the docs:
Variable Defaults: !default
You can assign to variables if they aren’t already assigned by adding
the !default flag to the end of the value. This means that if the
variable has already been assigned to, it won’t be re-assigned, but if
it doesn’t have a value yet, it will be given one.
$link-color is merely a variable. In framework context, !default is used to not overwrite customizations made by you or other included modules, while providing a default value for the variable if it hasn't been given a value yet.
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.
This question already has answers here:
Using custom HTML Tags
(10 answers)
Closed 9 years ago.
I've learnt HTML and the basics of CSS only recently and am enjoying the liberty of finally being web literate. One thing puzzles me, with the usefulness (literally and semantically) of elements in HTML5 such as
<footer>
etc why dont we just create and define our own elements such as
<price>
or
<icon>
instead of giving standard ones classes or defining divs all the time which seems confusing in comparison? It seems CSS has no problem styling these (in my tests anyway) like anything else providing I state whether display is inline or block etc.
Is this a totally standard thing to do I have just stupidly realised or am I missing a major downfall with this here?
Because:
Semantics only do any good if the user agent (browser, search engine, etc) understands them
If you make up your own elements and a set of semantics, then someone else (including the W3C) may introduce their own element with the same name but with different semantics and user agents would interpret your element "incorrectly".
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Cascading style sheets use “id” or “class”
When should i use an id v/s class in my css file.
I know that id is used when it is a unique element.
For all practical purposes if I assume that none of the elements are repeating what should I use?
The design decision comes from practical use. As I'm sure you're guessing: yes, it is perfectly standards-valid to use classes for everything. If you ever need to manipulate elements (take a look at jQuery), though, it is much easier to work with an id rather than a group of elements in a class.
You seem to understand: ids for unique elements, classes for multiple elements with the same design/purpose.
A good heuristic approach to think about is that the id is like the name of the element for if you want to refer to it specifically and the class is for properties of the element that some other elements around your site might have also.
Another thing to think about is specificity, which is the rules for when one css rule overrides another. Here is a good read for that: http://css-tricks.com/specifics-on-css-specificity/
ID has a higher selector specificity than a class. This means that if you have a class and id competing for properties, the id css properties will most likely overwrite the class properties. If I am correct, an ID is worth 100 points, a class selector is 10 points, tag selector is 1 point, and an in-line style is 1000 points. The higher the amount of points, the higher specificity and the higher it has a chance to overwrite the other selector properties.
Hope this helps.