I'm not the parent poster, and I'm not sure if these are the regex selectors they had in mind, but nonetheless. An example use case: the person writing the HTM

I'm not the parent poster, and I'm not sure if these are the regex selectors they had in mind, but nonetheless. An example use case: the person writing the HTML ≠ the person writing the selectors. Browser extensions like Stylus, for example. If the HTML author did not bother to add a specific class you need, you have to resort to ugly methods. In fact, this is a scenario I deal with regularly. I have a Chrome extension for video download sites that scans the current page for metadata (title, performers, release date, etc.) and decorates the download links with `download="…"` attributes, so that I can download a file with a properly formatted filename. I manually adapt this extension to every site I need, and quite often I need things like `a[href^=/model/]` † to distinguish links to performers from other links to get their text content. It's clearly not a situation the site authors worry about, and that's fine as long as I have a way to do this myself. † This particular selector can be done without jQuery if you don't care about backcompat. In browser extensions, you usually don't. But it's still an answer to your question about when such selectors are needed. --- Since I'm talking about this, that same browser extension can demonstrate some other complications brought on by React and CSS-in-JS: 1. CSS-in-JS turns class names into unreliable gobbledygook, so extracting metadata means more regex selectors and abominable DOM hierarchy selectors (`section>div>div:first-child>div` because nobody bothers with semantic <h2> or even .title anymore). 2. React makes DOM elements vanish and reappear instead of just hiding them, so that `download="…"` attribute I want to add has to go through a MutationObserver instead of just running once on page load.