Differencebetween :Where() and :Is()

What is the difference between :where() and :is()?

As mentioned, the difference is specificity. This is mentioned on MDN, though not prominently for some reason. The spec, on the other hand, is much more explicit about it:

4.4. The Specificity-adjustment Pseudo-class: :where()

The Specificity-adjustment pseudo-class, :where(), is a functional pseudo-class with the same syntax and functionality as :is(). Unlike :is(), neither the :where pseudo-class, nor any of its arguments contribute to the specificity of the selector—its specificity is always zero.

What are the use cases? Well, in the example you've given, it's not terribly useful. You don't have any competing selectors for which you need to match or otherwise not override specificity. You have a basic span rule, and a :hover rule that overrides it naturally (i.e. just by how specificity works and what specificity was originally designed for). If there aren't any special or exceptional styles you need to take into account, it doesn't really matter whether you use :is() or :where().

:where() becomes useful when you have more general rules that have unnecessarily specific selectors, and these need to be overridden by more specialized rules that have less specific selectors. Both MDN and the spec contain an example of a (very) common use case — I don't want to simply regurgitate what's on MDN, so here's the one from the spec:

Below is a common example where the specificity heuristic fails to match author expectations:

a:not(:hover) {
  text-decoration: none;
}

nav a {
  /* Has no effect */
  text-decoration: underline;
}

However, by using :where() the author can explicitly declare their intent:

a:where(:not(:hover)) {
  text-decoration: none;
}

nav a {
  /* Works now! */
  text-decoration: underline;
}

Unlike MDN, the spec doesn't really explain this use case in English, so I will. The "author expectations" here are that the nav a CSS rule (what I call a specialized rule) would override the a:not(:hover) rule (what I call a general rule). Ostensibly, this does not happen.

Because the :hover pseudo-class is more specific than type selectors, any rules that have only type selectors won't be able to override the general a:not(:hover) rule that applies to any a that isn't hovered. Traditionally you'd have needed to match the specificity of a:not(:hover), most naïvely by duplicating the offending bit:

a:not(:hover) {
  text-decoration: none;
}

nav a, nav a:not(:hover) {
  /* Works, but not ideal, to say the least */
  text-decoration: underline;
}

Alternatively, by adding selectors that increase specificity without affecting matching:

a:not(:hover) {
  text-decoration: none;
}

nav a:nth-child(n) {
  /* Works, but not ideal either */
  text-decoration: underline;
}

^{(or a:any-link, in the case of links)}

What :where() does is allow you to remove the specificity added by :hover altogether, thereby making it much easier to override this rule for certain a elements, for example by ensuring that a elements in a nav are always underlined whether or not the cursor is over them (since nav a is more specific than just a).

Unusually, because it decreases a selector's specificity, you'd generally use :where() with selectors that need to be overridden, rather than the overriding selectors. On the other hand, you use :is() simply to reduce selector duplication in your CSS rules, e.g. by changing

.span1-1:hover, .span1-2:hover

to

:is(.span1-1, .span1-2):hover

while preserving specificity (though do note that :is() does work differently once you're grouping selectors with different specificity amounts).

This means that while :where() has a similar syntax to :is(), in practice they're two different pseudo-classes with different use cases. Their use cases do partially overlap nevertheless. For example, you may need to reduce selector duplication in a general rule, which implies using :is(), but you'd prefer :where() instead to also reduce specificity. Since it's useful to apply a single :where() to multiple selectors, allowing it to accept a selector-list makes it so you don't have to write :where(:is(selector-list)). This principle applies to many other new pseudo-classes such as :host(), :host-context() and :has(), as well as the level 4 :not().

Flutter/Dart - Difference between () {} and () = {}

The fat arrow syntax is simply a short hand for returning an expression and is similar to (){ return expression; }.

According to the docs.

Note: Only an expression—not a statement—can appear between the arrow (=>) and the semicolon (;). For example, you can’t put an if statement there, but you can use a conditional expression

void main(){
    final cls = TestClass();
    cls.displayAnInt((){
       //you can create statements here and then return a value
       int num1 = 55;
       int num2 = 1;
       int sum = num1 + num2;
       return sum;
    });
   cls.displayAnInt(() => 55 + 1); // simply return an int expression
}
class TestClass{

    displayAnInt(makeIntFunc){

       int intValue = makeIntFunc();
       print('The int value is $intValue');
    }
}

From the code above, You can see that multiline statement can be made when the callback function is used and then a value is returned, while the fat arrow simply has an expression with no return keyword.

Considering your answer about fat arrows not supporting multiline statements in dart. This is quite understandable since doing () => {somtheing} would imply you are returning a map and it would expect to see something like () => {'name':'John', 'age':25} and not () => { _myTxt = "Text Changed";_myTxt = "Never Mind"; } .

Difference between () and $()

The sub expression ($(...)) contains a StatementBlockAst. It can take any number of statements, meaning keywords (if, foreach, etc), pipelines, commands, etc. Parsing is similar to the inside of a named block like begin/process/end.

The paren expression ((...)) can contain a single ExpressionAst which is a limited subset of the AST. The most notable difference between a statement and an expression is that keywords are not parsed.

$(if ($true) { 'It worked!' })
# It worked!

(if ($true) { 'It worked!' })
# if : The term 'if' is not recognized as the name of a cmdlet, function, 
# script file, or operable program. Check the spelling of the name, or
# if a path was included, verify that the path is correct and try again.
# At line:1 char:2
# + (if ($true) { 'It worked' })
# +  ~~
#     + CategoryInfo          : ObjectNotFound: (if:String) [], CommandNotFoundException
#     + FullyQualifiedErrorId : CommandNotFoundException

Also as others have noted, the sub expression will expand in double quoted strings.

What's the difference between () and {} in javascript functions?

These are fundamentally different. The former arrow function syntax, () => {}, allows you to have multiple statements inside the arrow function's body, i.e.:

() => {
  console.log('Hello!');
  return 'World!';
}
// When called, this logs Hello! and returns World!

But the latter, () => (), is an arrow function that implicitly returns an expression that is wrapped in parentheses (called the grouping operator). It does not explicitly allow for multiple statements:

() => (
  'World' // only one expression that is implicitly returned
  // Would work fine without parentheses (unless you want to return an object!)
)
// When called, this function returns 'World'

Of course, you could also create an unreadable arrow function that performs multiple operations using the comma operator:

() => (console.log('Hello!'), 'World!')

React

I assume you see this with React stateless components:

const Comp = () => (
  <div>Hello World!</div>
);

This function (components are just functions) returns the <div> element implicitly. But, using {}, you can do some intermediary calculations instead of just returning right away:

const Comp = () => {
  const msg = 'Hello World!';
  return ( // Need to explicitly return here
    <div>{msg}</div>
  );
}

What is the difference between :: and . in Rust?

. is used when you have a value on the left-hand-side. :: is used when you have a type or module.

Or: . is for value member access, :: is for namespace member access.

Difference between the :where() and :is() pseudo-classes?

The difference between :where() and :is() is that :where() always has
0 specificity, whereas :is() takes on the specificity of the most
specific selector in its arguments.

The pseudo-class :is() doesn't have any weight itself (unlike most pseudo-classes, which are the equivalent of classes in calculating specificity), but the values inside it's parentheses are used to calculate specificity instead. (By the way, it's the same case with another pseudo-class, :not().)

Example:
div:where(.outer) p has a specificity score (ordered from highest to least specificity value: inline styling/style attribute, id, class/pseudo-class/attribute, element) of 0,0,0,2, while div:is(.outer) p is scored 0,0,1,2.

Here's a mnemonic: :is() is influential, :where() is worthless.

_{Source: MDN}

Python 3.5 - Difference between '//' and 'int()'

Your understanding of the math seems fine, but what you're missing is that / produces a floating-point result, and floating-point numbers have limited precision:

>>> x = 2**64-1
>>> x
18446744073709551615
>>> int(x / 1)
18446744073709551616

Even dividing by 1 can lose precision. In contrast, dividing two ints with // works entirely in integer arithmetic, without a floating-point intermediate result and without losing precision.

Dart: What is the difference between floor() and toInt()

As explained by the documentation:

floor:

Rounds fractional values towards negative infinity.

toInt:

Equivalent to truncate.

truncate:

Rounds fractional values towards zero.

So floor rounds toward negative infinity, but toInt/truncate round toward zero. For positive values, this doesn't matter, but for negative fractional values, floor will return a number less than the original, whereas toInt/truncate will return a greater number.

---

Related Topics