[CSS-SELECTORS-4]#defines - like in programming language

[Nadya678]

I propose add to CSS specification "defines" known from pascal or C++.

I propose:

for selectors:

@define selector textish 
{
   input[type="text"], input[type="mail"], input[type="url"]
}

usage in code:
body>$textish will be equivalent of:
body>input[type="text"], body>input[type="mail"], body>input[type="url"]

$textish.mainform will be equivalent of:
input[type="text"].mainform, input[type="mail"].mainform, input[type="url"].mainform

for properties:

@define block framed
{
   border: 2rem solid #000;
   border-radius:10rem; 
}

usage:

body>ul
{
   block: framed;
   background: white;
}

will be equivalent:

body>ul
{
   border: 2rem solid #000;
   border-radius:10rem; 
   background: white;
}

What do you think about this proposal? Is it possible to add this or similar solution to selectors level 4?

It is my proposal for innovation in CSS (for people that use SCSS an SASS) and for needs of developers to write less code like here #2296

I think that creation more specific pseudoclasses is no innovation and it make the solution less flexible.

[Loirooriol]

This is more or less like https://drafts.csswg.org/css-extensions/#custom-selectors and http://tabatkins.github.io/specs/css-apply-rule/#defining

[AmeliaBR]

For selectors, the proposal is actually much simpler than @tabatkins's CSS Extensions custom selector proposal, since it would only be a shorthand for existing selectors, instead of allowing script-based tests.

For properties, @Nadya678's proposal does look a lot like @apply, and I'd suggest looking at the discussion in #1047 & elsewhere for syntax that has already been considered & the problems that were encountered.

---

So, focusing only on the selector side:

Selectors 4 already has the :matches(selector-list) selector, which allows a list of alternative selectors to be treated as one. With CSS preprocessors, you may be able to use a preprocessor variable to avoid repeating the selector-list many times, but it would definitely be nice if CSS had a native way to avoid that repetition.

A rough proposal for how to do so without changing CSS parsing rules too much:

• A new at-rule, @selector-set that allows you to define a name for the selector set and the list of selectors it is equivalent to.
• A single new pseudoclass :matches-set(), which is like :matches(), but it takes the name of a previously defined selector set as its parameter.

/* selector definitions */
@selector-set text-ish {
  input:not([type]),
  input[type='text],
  input[type='number'],
  /* ... */
}
@selector-set text-plus {
  :matches-set(text-ish), /* extend one set by including it in the list for another */
  input[type='color'],
  select,
  textarea
}

/* later ... */

:matches-set(text-plus) {
  border: solid #aaa;
  padding: 0.5rem;
}

Of course, any restrictions on selectors inside matches() would also extend to matches-set() and therefore to the selector set. As currently defined, that means that both compound and complex selectors are allowed, but pseudo-elements are not.

[AmeliaBR]

It has been brought to my attention that I read Tab's proposal way too fast. I thought the script-based bit was an essential part of it.

Functionally, my proposal is the same as the first part of https://tabatkins.github.io/specs/css-aliases/#custom-selectors

Repeated here, that proposal is:

A custom selector is defined with the @custom-selector rule:

@custom-selector = @custom-selector <extension-name> <selector> ;

This defines a custom selector which is written as a pseudo-class with the given <extension-name>, and represents a :matches() selector using the provided <selector> as its argument.

For example, if an author wanted to easily refer to all heading elements in their HTML document, they could create an alias:

  @custom-selector :--heading h1, h2, h3, h4, h5, h6;

  :--heading { /* styles for all headings */ }
  :--heading + p { /* more styles */ }
  /* etc */

So, I'm totally supportive of that syntax, too. Even if :--x is kind of kooky looking. To make the two proposal consistent from a CSS parsing perspective, you'd need to say that any pseudoselector starting with :-- is valid for parsing, although it wouldn't match anything unless a corresponding @custom-selector is also defined.

[Nadya678]

But innovative will be not using preprocessor (SASS, LESS) but native suport of it. I made simplier solution for selectors to make it friendly to read by programmer/developer.

Much websites about SASS/SCSS say: there is no innovative things in CSS for 10 years...