If you're an expert user of Variance you can build guides that utilize custom CSS selectors. If you don't know what this means, that's fine, but this feature probably isn't for you.

CSS Selectors

Variance supports all the standard CSS selectors. W3Schools maintains a very good reference table if you need to brush up. Beyond the normal class and ID stuff, some selectors we've found especially handy include:

  • [attribute] which lets you target HTML attributes
  • [attribute*=value] select attributes that contain a certain pattern
  • element+element selects elements that are immediately after another element
  • element1~element2 selects elements that are preceded by an element
  • :not() selects elements that are not the one you specify
  • :nth-child() selects the child element you specify

Targeting Text

Outside of the core CSS selectors, there are some special selectors available that make it easier to work with text.

  • :contains(TEXT): Elements with textContent containing the word "TEXT". Case-sensitive.
  • :exactText(TEXT): Elements with textContent that exactly match the word 'TEXT'. This is particularly helpful for words like "ID" that might appear within multiple places.

Sizzle Selectors

Beyond the standard CSS selectors, we allow you to use jQuery Sizzle selectors

  • [NAME!=VALUE]: Elements whose NAME attribute doesn't match the specified value. Equivalent to :not([NAME=VALUE]).
  • :header: Header elements (h1, h2, h3, h4, h5, h6).
  • :parent: Elements with at least one child node (either text or an element).
  • :selected: (option) elements that are currently selected

Tips & Tricks

Beyond the specific selectors, here's a few tips for writing selectors that won't break:

  • As a rule, you're trying to base your selector on things that won't change. This means thinking about probably won't change in a page or application in either the short or long term. This isn't as much about the site design changing (if that happens there's a good chance your selector could break) but more about being sure it will work even with different content on the page.
  • When you use CSS selectors for Click Triggers, the extension will always try to ensure that if any children of the chosen selector are clicked, those also cause the Trigger to fire. That means it's better to choose the parent element, as choosing a specific child (like a span that contains text) may cause you to miss the click.
  • Use descriptive classes (.nav-link ), not ones that have random letters or numbers (.sc-isBZXS ). 
  • Using the href attribute with *= is a good thing for navs. Example: [href*="inbox"] will match the Inbox link in the nav even if the site includes a slash (/inbox).
  • If the site has anything that looks like attributes written for frontend tests, utilize those. They're super helpful. For instance, Hubspot frequently uses data-selenium-test attributes like this: button[data-selenium-test="new-object-button"]. Those should hold up reasonably well.
  • :contains() is very powerful, but make sure you use it in combination with a class, element, or attribute otherwise you will just capture the whole page with your selector. 
  • Try not to only use :nth-child() as a last resort. It's hard to trust that things will always be in the same order next time or with different content.

One of the very helpful features in the Editor is the live highlighting while you type out your selectors. You can use this to ensure they will work correctly.


Did this answer your question?