That did not stop ~2008 me from writing a small script to automate playback of, iirc, the HTML table elements that encoded the data & ran it via SeleniumRC against a SeleniumGrid (sometimes we'd use all the laptop's in the office as a load test!!).
I added some variable interpolation into the commands, and QA department had a field day recording activities, & using that output to writing & composing steps & tests.
I'm still extremely salty at the weird dogmatic "gui tools are for human interaction!" anti-automation perspective selenium presented then. Today, there's an HtmlUnit WebDriver project that does just this, I believe. I quickly scanned the archived seleniumhq.org website & web.archive.org but haven't found this, hope I do again some day. It remains one of my earliest & most impressionable memories of dogmatism in software, of someone very loudly declaring that this thing needs to be over here & that one needs to be over there & never ever let them touch. Long story, pardon; this project here is definitely bringing back those memories though! Heck yes GUIs that can help script.
I think selenium predates jQuery, which as one of the first frameworks used CSS selectors to address DOM nodes. You typically don’t want very specific selectors for your links and buttons to click, so you don’t have to change the test every time you update the HTML code. As I remember the selenium extension produced very specific code there.
But as you mentioned, there is more than one way to work with the generated code.
Also what benefit does the extension provide over Playwright's inspector tool?
> I understand the term when it comes to running automated tests, but I don't understand how it can claim to be "headless" when it requires a real browser window in order to execute?
seems pretty related to me