Continuing the discussion from Base64 conversion:
Wanted to resurrect this 2020 topic for a second because it was locked without a definitive explanation, so maybe I can offer one and help some future coding prodigy keep their anxiousness in check instead of wasting 30 minutes of their life looking into random commits for an answer to what these mean red lines might want from their binary schemes as their own twisted way of procrastinating.
So, it would seem that this is a visual bug specific to Monaco, an open-source text editor from Microsoft which powers Airtable’s Scripting app.
On my end, these squiggly eyesores only appear if I write btoa instead of BtoA immediately after a DOM refresh. But if I reload the page and use BtoA first, I can btoa as much as I want all over the place.
Sd linting quirks don’t affect functionality and the inconsistent accounts from the previous thread suggest the lines might actually originate from a third-party spellchecker (or a rare example of a second-party offender, if you’re running the Microsoft Editor browser extension; either way, there aren’t that many things that can mess with browser runtime), I give this bug roughly zero to no chance of ever getting fixed.
As is tradition, this frivolous debugging escapade actually yielded one more potential bug than it definitively explained: the getElementByID spelling exhibits more or less identical behavior to btoa methodology references, even though it should not be flagged regardless of whether it’s ‘ID’ or ‘Id’ being referenced for deliverance. Except that with this one, your code potentially won’t run and you won’t have a direct clue as to why. But here, getting the getElementById spelling right does matter because this is JavaScript, where data types are made up and rules don’t matter (except for getting the element by ‘Id’, that’s not the same as asking for a getting by the way of an ‘ID’, everyone knows that).
