1

I just had a case where it would have been really useful if there were a CSS selector like :numeral. I could then make all the numerals superscript and change their color.

It then occurred to me that it would be even more useful to have something like :regex('...') which would allow me to use regex to select particular text (numerals preceded by a space, for example: :regex(' \\d*')).

Is there a good reason this sort of selection should not be implemented in CSS Spec?

T.J. Crowder
  • 1,031,962
  • 187
  • 1,923
  • 1,875
jcuenod
  • 55,835
  • 14
  • 65
  • 102
  • @Steeven: Re your suggested edit, "if there were" is the correct construction (it's the "subjunctive" or "speculative" tense). – T.J. Crowder Jul 05 '11 at 15:36

1 Answers1

3

Is there a good reason this sort of selection should not be implemented in CSS Spec?

Yes - performance reasons.

A common request is a "parent selector" (similar to jQuery's :has() selector), which is also rejected for similar performance reasons.

A good read on this subject is: http://snook.ca/archives/html_and_css/css-parent-selectors

The sheer length of that article is why I'm not attempting to explain this myself.

If a parent selector is too bad from a performance viewpoint, you can imagine that a "regex selector" would be unthinkable.

Especially when you consider that not all regexes are equal: it's very easy to make very slow regexes.

For example: http://www.regular-expressions.info/catastrophic.html

thirtydot
  • 224,678
  • 48
  • 389
  • 349
  • 1
    Trying to find sources citing the reason why the `:contains()` pseudo-class was dropped, but to no avail. – BoltClock Jul 05 '11 at 15:15
  • @BoltClock: 6.6.6 eh? http://stackoverflow.com/questions/4781141/why-h3nth-child1containsa-selector-doesnt-work/4781167#4781167 – thirtydot Jul 05 '11 at 15:24
  • 1
    Parent selectors and a `:regex` selector are fundamentally different, I wouldn't generalize from performance aspects of the one to comment on performance aspects of the other. – T.J. Crowder Jul 05 '11 at 17:24
  • This is true, partially. I disagree in that the scope of supported regex could be reduced to avoid "catastrophes" (although having said that, I question it to some degree). Nevertheless, the problem with parent (ancestor) selectors - with which I am familiar - is that later dom affects earlier rendering. This is not the case with regex because it has to *match* an expression. – jcuenod Jul 05 '11 at 17:26
  • @T.J. Crowder: I agree that my reasoning is faulty. I just went with what I could think of :( I am at least correct with the "performance" idea in my answer, see the red text in an [older revision of the CSS3 spec](http://www.w3.org/TR/2000/WD-css3-selectors-20001005/#content-selectors). If `:contains` has "performance issues", then `:regex` would be much, much worse. – thirtydot Jul 05 '11 at 19:22
  • @j3frea: You might want to post your question here: http://lists.w3.org/Archives/Public/www-style/. You'll get a better answer than I can provide. – thirtydot Jul 05 '11 at 19:30
  • I think the performance issues are because of matches like `Markup` on `:contains("Markup")`. Regex may well have worse possibilities though. – jcuenod Jul 05 '11 at 20:15
  • @thirtydot: Yes, if `:contains` has performance issues, `:regex` should have at least the same issues. (I doubt they'd be "much, much worse" though; regex engines in browsers are pretty quick.) Though there's the question of whether performance is the problem of the specification (this isn't directed at you, but rather at the W3C); I tend to prefer caveat user (let the user beware). There are lots of things we can do that can have performance impacts... – T.J. Crowder Jul 05 '11 at 20:31