CSS Regex Selector

[pmaxhogan]

This would resolve #1008.
It would be very nice to have the ability to do a regex selector on a tag, like this:

/**Match all h1-h6 tags**/
/^h\d$/i{
     font-family: "Roboto", sans-serif;
}
/**Match all ruby elements**/
/^r[a-z]+/i{
     font-weight: bold;
}

and so on. Better yet, allow regex to be used in classes, etc.

/**Match sections with ids of card-1, card-2, etc.**/
section#/card-\d+/i{
     padding: 10px;
     border-radius: 10px;
     background: white;
}

This would be an extremely helpful feature of CSS that would help developers write lean, beautiful code and I would love to see it added to the spec!

[patrickdark]

This feature sounds like overkill; if one needs regular expressions to match element names, then something would seem to be wrong with the design of the language being styled.

In the case of h1/h2/h3/h4/h5/h6, the elements are a historical artifact and shouldn't exist and in practice one should rarely ever need to use more than h1 and h2 given the HTML5 outline algorithm.

In the case of ruby/rt, it'd be less verbose to write a selector without a regular expression and in practice you won't want to style those elements the same anyway.

[notoriousb1t]

@patrickdark When you look at an html document from the perspective of a screenreader, heading tags are important to providing a logical structure. Even a site without a lot of content could under best practices go down to an h4. It is still useful even if not all decide to make websites accessible.

I agree that regex is unnecessary (and think it might be possible hazardous). I think that simple pattern matching the same as attribute selectors have would be more than sufficient to solve this problem and when using a framework that prefixes their custom elements.

[patrickdark]

@notoriousb1t I don't disagree that heading elements are useful, but the paradigm of...

<section>
   <h1></h1>
   <section>
       <h1></h1>
   </section>
</section>

...makes having numbered heading elements redundant for anything other than subheadings since the heading level can be inferred from the number of sections in which a heading element is nested. In those cases, h1 might as well be h; the element is only numbered for historical reasons.

In modern HTML, the only in case where numbered headings are useful are in hgroup elements where h2 et al can be used to mark subheadings. In practice, subheadings are limited to one to two levels, and styling h4/h5/h6 elements will be superfluous.

And even the latter case I think shouldn't exist. It'd be better to infer subheadings via element nesting by doing something like repurposing the hgroup element:

<hgroup>
    <h1></h1>
    <hgroup>
        <h1></h1>
    </hgroup>
<hgroup>

[notoriousb1t]

@patrickdark I respectfully disagree, but I think we should discontinue this conversation in order to keep the issue on topic.

[topaxi]

The heading case could be solved with something like https://drafts.csswg.org/css-extensions/#custom-selectors

The section case could be solved with attribute selectors:

section[id^="card-"] {
     padding: 10px;
     border-radius: 10px;
     background: white;
}

I think RegExp would only add a lot of complexity for everyone.

[nico3333fr]

For some complex real cases, it could be useful, I had a case this afternoon, let's try to explain it simply:

I want to select all elements that have class="foo-<*>-bar" (I have about 6 or 7 same behaviours with small differences), and elements may have other classes attached to them, so impossible to use class^= or class$=, neither class|=.

I had to use: [class*="foo-"][class*="-bar"] (which allowed me to save about 50 lines of CSS, and probably more when the website will become more complex)

Problems with this targeting:

• if the CSS classes are not perfectly namespaced => kaboom.
• if I want to factorize all commons properties for class="foo-<*>-bar" and surcharge after with specific cases - which is a current pattern with CSS - => the specificity of [class*="foo-"][class*="-bar"] is too big, I have to use .foo-one-bar.foo-one-bar to override specificy of the double attribute class, a regexp selector would avoid me to do so.

I agree: it is complex, not everyone will need it => but complex cases sometimes needs powerfull solutions.

[FremyCompany]

I'd recommend you to change your class system to have a foo class and a bar class in addition to your foo-xxx-bar class if that is what you need for selecting purposes. Executing regular expression on every attribute of the document would be very expensive. Microsoft Edge's layout team would be opposed to this idea.

[Crissov]

@nico3333fr's specifity problem would be solved if attribute selectors could have multiple alternate values, e.g. [class*="foo-","-bar"] instead of [class*="foo-"][class*="-bar"].

[AndreasKarz]

This feature sounds like overkill; if one needs regular expressions to match element names, then something would seem to be wrong with the design of the language being styled.

In the case of h1/h2/h3/h4/h5/h6, the elements are a historical artifact and shouldn't exist and in practice one should rarely ever need to use more than h1 and h2 given the HTML5 outline algorithm.

In the case of ruby/rt, it'd be less verbose to write a selector without a regular expression and in practice you won't want to style those elements the same anyway.

Have you ever written automated tests? Not always see the problems from your point of view.

[AndreasKarz]

The heading case could be solved with something like https://drafts.csswg.org/css-extensions/#custom-selectors

The section case could be solved with attribute selectors:

section[id^="card-"] {
     padding: 10px;
     border-radius: 10px;
     background: white;
}

I think RegExp would only add a lot of complexity for everyone.

Have you ever written automated tests? Not always see the problems from your point of view.

[SebastianZ]

@AndreasKarz If you have some specific use cases where you think regular expressions would greatly improve what we have so far, you should share them.

I, for myself, also already thought about them being useful, though I can totally understand that implementors are reluctant to the idea of adding regular expressions to selectors because this would definitely come with some performance cost.

The use cases I had so far mainly only required advanced attribute selectors similar to the ones @nico3333fr mentioned.

Sebastian