Here's a very-niche but then-very-useful #javascript trick I realized today -- you can create empty text-nodes to use as node references, for things like DOM insertion, range boundaries, or whatever.
I needed this to set the end of a range immediately before an element's closing tag, when references to existing child nodes might be invalidated by race conditions.
You don't even need to persist the references for removal, since a single call to context.normalize() cleans them all away.
@ollicle Oh you were asking about dealing with sibling text nodes? Yeah, that :-) Normalizing isn't something you tend to need very often, but it's uniquely useful when you do.
That's a good point about spotting in dev tools, I guess it would depend on what you needed. If the nodes need to be around for a while, it would be more useful to be able to inspect them. My use-case is very transient, they're added and gone again in the space of a synchronous function call.
Wonder if anyone will keep track of appearances gifted by mainstream media to Farage et al during #ge2024 campaigning, vs visibility given to the Green Party
@urlyman Fancy building a Chrome extension? The core functionality would be fairly trivial, the tricky bit would be learning how to use the extensions API lol.
(Which I'm presuming is mostly great with a side-order of intensely frustrating in some randomly specific ways.)
fyi. Sonoma 14.5 includes some changes to the QuickNav feature in VoiceOver, and after I updated, it was turned on by default.
Some hours of confusedly testing why none of my JS key handling scripts are working anymore, turned out to be that -- unmodified arrows and navigation keys aren't passed through to JavaScript when QuickNav is on.
(You have to hold Option. I don't know if that was always the case, I didn't know about QuickNav until today.)
@whitingx Even Star Trek couldn't keep it up. Roddenberry's vision of utopia is riddled with hypocrisy and holes, it side-steps privacy and diversity questions (or handles them crassly), and its economics completely fall apart if you give them more than a cursory glance.
I've been playing around with keyboard scrolling of overflow regions, and I was interested to note how Firefox's native behavior doesn't expose any additional semantics -- i.e., it doesn't apply a role or accessible name when the scrolling region becomes focusable.
And I think that's the right thing to do -- that our standard workaround of including role="region" and aria-label or aria-labelledby (along with tabindex="0") creates unnecessary verbosity.
@cwilcox808 Not that I know of, it doesn't seem to expose anything in the DOM. There's a change in the accTree (the element gains a "focusable" state) but nothing that JS can read, as far as I know.
There is blue-sky talk of providing API access to the accTree, but I'm not sure when or if that will happen, and I'm not convinced it's a good idea anyway, too much potential for good-intention breakage.