Photo by Clay Banks on Unsplash

Exploring a page with Selectors

Articles Dec 21, 2021

tl;dr use document.querySelectorAll

Use document.querySelectorAll('...your selector here...') in your browser console to identify what elements it will pick up, in a real page.


I find CSS hard to interpret. I can't easily see bugs, and I get burnt when I tweak existing CSS. I've learnt my selectors, and have a fair idea of what formatting one can change, and how it can be done. I even have a CSS mentor to explain the obvious problems, and to help me understand where some thing perhaps can't be helped. Nonetheless, unexpected behaviours (changes to things I thought unrelated to my changes) rock up regularly.

Let's parse some CSS:

#fromPageContent, .front-page-section p {
      font-size: 1.25rem;
}

CSS selectors are those parts that come before the {formatting rules}. The browser will apply the format font-size: 1.25rem; to every element which matches the selector #fromPageContent. The # means this is a class selector, so the browser will format all elements which have the class fromPageContent.


An Example

Here's an example of how I explored to find out. It worked on the front page of this site (at the time of writing):

I've got a CSS selector that I want to double check. In the CSS, it reads .front-page-section p { ...some formatting ... }. I can read that as "paragraphs within elements of class front-page-selection should look like ...some formatting...".

To double-check it, I'm going to use my browser's DevTools, and I'm going to write a bit of JavaScript to tell me what, in the browser, should take ...some formatting...

There are plenty of ways to open the DevTools – generally, I right-click and choose "Inspect", which works on Chrome and Safari. Once there, I head to a console tab, and look for the > caret.

At the > caret, I type in the query I'm interested in. Here, it's document.querySelectorAll('.front-page-section p'). I hit return.

The console hands me back a bunch of stuff. In Safari (but not in Chrome), it's a list of paragraphs. 19 of them – and looking inside, I can see that the list includes things that I don't want.

So I know my selector is wrong. I re-interpret the selector query as "all paragraphs within all elements of class front-page-selection and their children should look like ...some formatting...".

I just want to affect the paras immediately within that selection. I reckon I need to use the > selector, which selects children, and not more-distant descendents. I could re-write my selector as .front-page-section**>**p.

I can try that out with document.querySelectorAll('.front-page-section>p'). It picks out what I need. Having experimented, I can change the CSS with a bit of confidence. Which is handy: I'm in a theme and changes need to be recompiled and re-uploaded, which means trial-and-error takes about 3 minutes per try.

Use as a Tester

As a tester, I use selectors to pick out specific elements from web pages (and XML, come to that) to work with in tools. HTML/CSS layout is everywhere, and if you need to deal with a UI, you'll often be pulling out parts with CSS selectors.

Trying the blasted thingsπŸ’£ out before I put them into a test helps me see when a query brings back more than one thing, or when it brings back stuff I didn't expect (often along with what I wanted).

More generally, trying things out before I make them permanent appeals to me as an experimenter and explorer. I've got a shallow understanding of broad technologies; using the console to give me feedback lets me learn directly, and (by surprising me) exposes my "how hard can it be" assumptions in a way that I can learn from.

Footnotes

(kind-of)

πŸ—£οΈ
I think I first saw this handy trick demonstrated by Alan Richardson and Viv Richards at their MoT workshop on DevTools in Summer 2019.
πŸ’‘
HTML elements (stuff inside a <tag>stuff</tag>) can have none, one or many classes – and the classes don't have to exist.
πŸ’£
CSS selectors don't fit well in my head; I've had to learn them by heart, several times.
** You can pick out the same element in different ways. It's good to have several choices, because (for testers who want their code to last) some selectors are brittle. Having brittle elements in your tests means that pretty ordinary changes to the system-under-test can be fatal to the plumbing of your test code. I've been stung by selectors which use IDs, and deep nests of selectors. I've had successes when I combine page structures and classes, especially in situations where the pages are built with HTML that makes semantic sense.

Tags

Comments

Sign in or become a Workroom Productions member to read and leave comments.

Great! You've successfully subscribed.
Great! Next, complete checkout for full access.
Welcome back! You've successfully signed in.
Success! Your account is fully activated, you now have access to all content.