Exploring a page with Selectors
tl;dr use document.querySelectorAll
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)
<tag>stuff</tag>
) can have none, one or many classes β and the classes don't have to exist.
Comments
Sign in or become a Workroom Productions member to read and leave comments.