Archive for the 'NOLIDGE BOMS' Category

CSS :has(), the God Selector

Probably everybody knows this, but I didn’t and in case you don’t, here’s why the CSS :has() pseudo-class is omnipotent and so awe-inspiring I call it the God Selector.

I was working on a no-JavaScript fallback for a mobile hamburger menu, using the newly-baseline HTML Popover API. For users without JavaScript (and, yes, there are many), the code looks like this:

<header>
<a><picture> <!-- Logo homelink --> </picture></a>
<button> <!-- big fat CTA --> </button>
<search> .. </search>
<button popovertarget="narrowscreen-nav">Menu</button>
<nav id="narrowscreen-nav" popover> ... </nav>
</header>

I wanted to give the button a different style if its associated popover is shown. There is no pseudo-class for button:pressed (which is why some people like the checkbox hack, which is clever but has the wrong semantics. And, anyway, popovers can’t be triggered from inputs).

There is, however, a pseudo-class to tell you if a popover is open: :popover-open. Now, to find a way to style the button element by targetting this aspect of its associated (but not descendant) popover target element.

Sometimes people called :has a “parent selector”, but it’s not only that. I knew that it could “reach out” and look at siblings etc if there is the necessary CSS combinator. This selector worked for my code:

button:has(~nav:popover-open) {background-color: goldenrod;}

However, I wasn’t happy about it; what happens if the nav ceases to be a sibling (as it soon did, because I needed a wrapper around the stuff before the nav, to lay it out using Flexbox)? I tend to dislike handing code over to clients that has a very tight dependancy on exact markup structure.

Luckily, I had a conversation with the splendid Luke Warlow of Igalia (a free software consultancy/ hippie commune who do loads of work in all the browser engines), and he blew my mind. It turns out I was thinking about :has the wrong way round.

Behold the almighty God Selector:

:has(nav:popover-open) button[popovertarget] {background-colour:goldenrod;}

This is omnipotent because it doesn’t require any structural relationship between the thing being checked and the thing being styled. The first bit of the selector :has(nav:popover-open} doesn’t have a class, ID or element name, so is scoped to the root of the document. That’s the thing being checked: is there a nav that is an open popover anywhere in this page?

The second part of the selector is the thing to be styled, which is a descendant of the root – and, of course, everything on the page is a descendant of the html element, which is the root. Think of the selector as html:has(nav:popover-open) button[popovertarget] if that makes it easier to reason about.

Of course, you can narrow it down to hone in on the exact nav or button you’re interested in. For example,

header:has(nav:popover-open} button.letsBeSpecific[popovertarget] {background-color:goldenrod;}

And now, I’ve used the God Selector in three different places in the same stylesheet already, to achieve an effect I could not have done without handing over markup of much greater fragility. Thank you to the Mighty Luke Warlow, and I’ll have a kilo of whatever goes in the Igalia bong.

Making accessible DocuSign forms

Last week I observed a blind screen reader user attempting to complete a legal document that had been emailed to them via DocuSign. This is a service that takes a PDF document, and turns it into a web page for a user to fill in and put an electronic signature to. The user struggled to complete a form because none of the fields had data labels, so whereas I could see the form said “Name”, “Address”, “Phone number”, “I accept the terms and conditions”, the blind user just heard “input, required. checkbox, required”.

Ordinarily, I’d dismiss the product as inaccessible, but DocuSign’s accessibility statement says “DocuSign’s eSignature Signing Experience conforms to and continually tests for GovernmentSection 508 and WCAG 2.1 Level AA compliance. These products are accessible to our clients’ customers by supporting Common screen readers” and had been audited by The Paciello Group, whom I trust.

So I set about experimenting by signing up for a free trial and authoring a test document, using Google Docs and exporting as a PDF. I then imported this into DocuSign and began adding fields to it. I noticed that each input has a set of properties (required, optional etc) and one of these is ‘Data Label’. Aha! HTML fields have a <label> associated with them (or should do), so I duplicated the text and sent the form to my Work Bezzie, Stinky Taylar, to test.

DocuSign's back-end to add fields to a PDF.

No joy. The labels were not announced. (It seems that the ‘data label’ field actually becomes a column header in the management report screen.) So I set about adding text into the other fields, and through trial and error discovered how to force the front-end to have audible data labels:

  • Text fields should have the visible label duplicated in the ‘tooltip’ field.
  • Radio buttons and checkboxes: type the question (eg, what would be the <legend>) into the ‘group tooltip’ field.
  • Each individual checkbox or radio button’s label should be entered into the “checkbox/ radio button value” field.

I think DocuSign is missing a trick here. Given the importance of input labels for screen readers, a DocuSign author should be prompted for this information, with an explanation of why it’s needed. I don’t think it would be too hard to find the text immediately preceeding the field (or immediately following it on the same line, in the case of radio/ checkboxes) and prefilling the prompt, as that’s likely to be the relevant label. Why go to all the effort to make an accessible product, then make it so easy for your customers to get it wrong?

Another niggle: on the front end, there is an invisible link that is visually revealed when tabbed to, and says “Press enter or use the screen reader to access your document”. However, the tester I observed had navigated directly to the PDF document via headings, and hadn’t tabbed to the hidden link. The ‘screenreader mode’ seemed visually identical to the default ‘hunt for help, cripples!” mode, so why not just have the accessible mode as the default?

All in all, it’s a good product, let down by poor usability and a ‘bolt-on’ approach. And, as we all know, built-in beats bolt-on. Bigly.

React accessibility resources

Ok, so you’re making a React or React Native app. Don’t! Make a Progressive Web App. Sprinkle some Trusted Web Activity goodness to put it in the Play store wrap it with Capacitor.js if it needs push notifications or to go in the App Store (until the EU Digital Markets Act is ratified so Apple is required to allow more capable browsers on iOS).

But maybe you’re on a project that is already React Native, perhaps because some psycho manager flew in, demanded it and then returned to lurk in Hades. In which case, this might help you.

Testing

I like Expo (and wrote some random Expo tips). Expo Snacks are like ‘codepens’ for React Native.

Bugs?

Open Accessibility bugs – Facebook’s official list, and accompanying blog post.

Leverage accessibility synergies and turbo-boost your remuneration potential with these three weird tricks!

Your chums at WebAIM report

The Wall Street Journal indicated that many companies are looking for personnel with accessibility skills and that they can’t find them easilyThe number of job listings with accessibility’ in the title grew 78% in the year ending in July [2021] from the previous 12 months, LinkedIn said.

Get ahead! Crush, grind, mash and maim lesser developers! Earn more cash! You can acquire better “accessibility skills” than 90% of the developers on the market by

(The first two are foundational skills for anyone whose code is allowed anywhere near a web browser. The latter is a foundational skill for ‘being a decent human being’)

Random Expo.io tips

I’m doing some accessibility testing on a React Native codebase that uses Expo during development. If you’ve done something seriously wrong in a previous life and karma has condemned you to using React Native rather than making a Progressive Web App, Expo is jolly useful. It gives you a QR code that you can scan with Android or iOS to ‘install’ the app on your device and you get live reload of any changes. It’s like sinking in a quagmire of shit but someone nice is bringing you beer and playing Abba while it happens. (Beats me why that isn’t their corporate strapline.)

Anyway, I struggled a bit to set it up so here are some random tips that I learned the hard way:

  • If your terminal yells “Error: EMFILE: too many open files, watch at FSEvent.FSWatcher._handle.onchange (internal/fs/watchers.js:178:28) error Command failed with exit code 1” when you start Expo, stop it, do brew install watchman and re-start Expo. Why? No idea. Someone from StackOverflow told me. Most npm stuff is voodoo magicjust install all the things, hope none of them were made by in Moscow by Vladimir Evilovich of KGB Enterprises, ignore all the deprecation warnings and cross your fingers.
  • If you want to open your app in an iOS simulator, you need xcode and you need to install xcode command line tools or it’ll just hang.
  • Scrolling in iOS simulator is weird. Press the trackpad with one hand and scroll with other hand. Or enable three finger drag and have one hand free for coffee, smoking or whatever other filthy habits you’ve developed while working from home.
  • If you don’t want it, you can turn off the debugging menu overlay.
  • If you like CSS, under no circumstances view source of the app running in the browser. It is, however, full of lots of ARIA nourishment thanks to React Native for Web.

Who knows? One day, Apple may decide not to hamstring PWAs on iOS and we can all use the web to run on any device and any browser, just as Sir Uncle Timbo intended.

Here at Brucecamp, business and politics don’t mix

You don’t change the world by sitting around being a good person. You change the world by shipping products and making money.

As I wrote in my seminal management book Listen to me because I’m rich, white and clever, IBM wouldn’t have made a shitload of money in wartime Europe if they’d engaged in endless navel-gazing about politics. Their leadership told the staff to Stop Running in Circles and Ship Work that Matters, and get on with compiling a list of people with funny names like “Cohen” or “Levi”.

So here at Brucecamp, we’ve decided that it’s best if our productbots (formerly: employees) do not discuss the sausage machine while we push them into the sausage machine. As I wrote in our other book It doesn’t have to be full of whimpering Woke retards at work, “if you don’t like it, well, there’s the door. Enjoy poverty!”. And that’s all we have to say on the matter. Until the next blogpost. Or book.

In other news, Apple are wankers and I bought a sauna.

“Facebruce strongly disapproves of data leaks” – Bruc’s statement

A statement from our CEO and Founder, Bruc:

At Facebruce, we strongly disapprove of the recent data leak of 50 million account details. There’s nothing more important to us than your data. Really, nothing. Have you any idea of how much we could have charged people for the information about you that is now out there, available for free, on Torrent sites and on Russian servers?

We had a deal almost signed to show messages to all people who fast during Ramadan, saying “Want some free money? Just send us your home address!”, paid for by “Patriots for the Second Amendment and Jesus”. Of course, it isn’t the money that drives us, it’s that Facebruce is facilitating community by introducing two groups. At Facebruc, we love spreading love and connection, so need to raise a little money to run the service.

So, please, trust us with your data, and click ‘Like’ to keep our engagement figures riding high as our share price!

Next on feed: LGBT+ folks! Send us your address to get a free Rainbow Pride t-shirt! (sponsored by Westboro Baptists)

At Facebruce, we strongly disapprove of genocide. Our official statement.

A statement from our CEO and Founder, Bruc.

“Look, I”m fed up at people complaining about Facebruce allegedly “facilitating” genocide. Since we began, we’ve always been about connecting peopleinitially some nerds to chicks we rated as hot, but now it’s about connecting everybody. We’d like to teach the world to sing, in perfect harmony.

Unfortunately, not everyone wants to sing in perfect harmony. Some people, we are shocked to learn, aren’t actually very nice people. How were we at Facebruce to know what would happen when our algorithms repeatedly recommended members of The Hutu Machete Enthusiasts Club also join the Death To Tutsi Cockroaches group?

We’re not in the content policing business. There’s simply too much of it. And anyway, we’re just a platform. We already have thousands of servers running 24/7 to weed out pictures of nipples (women’s nipples, to be precise) so your Auntie Martha doesn’t clutch her pearls, because offending people in high ARPU markets leads to a drop in engagement.

So there was literally no way for us to know that the Death To Tutsi Cockroaches group was not simply a pest control company. I even went so far as to attempt to verify this, by walking around the HQ trying to find an African person to ask whether cockroaches are a problem, but there was no-one matching that description in the boardroom.

Facebruce is about building communities. We are very active in the GraphQHell community and the Reactionary community. In fact, only last week, we offered free afterhours use of a meeting room in our fifty storey gold-plated HQ to host a meeting of GraphQHell Engineers Against Killing Rohingyas, and even sponsored $100 of pizza for attendees. This shows that we’re taking real action and putting real resources into counteracting Hate Speech on the Facebruce platform.

So that’s cleared up then. Be sure to press “Like!” to demonstrate engagement.”

Next on Timeline: Why Covid is a hoax – evidence from the Protocols of the Elders of Zion!

Get that dream tech gig by solving Mike Taylr’s Silicon Valley whiteboard interview question

Like every other thought-leader, I follow Mike Taylr on social media. Ever since Shingy left AOL, “Mikey” has moved to the top spot of everyone’s Twitter “Futurist Gurus” Twitter list. This morning I awoke to read Twitter abuzz with exictement over Mike’s latest Nolidge Bom:

Of course, like anyone who’s ever sat a maths exam and been told to “show your working out”, you know that the widely diverse interview panel of white 20-ish year old men is as interested in how you arrived at your answer as in the answer itself. Given Mikey’s standing in the industry and the efficiency of his personal branding consultants, this question will soon be common for those interviewing in Big Tech, as it’s an industry that prides itself on innovative disruption by blindly copying each other. So let’s analyse it.

It’s obvious that the real test is your choice of marker colour. So, how would you go about making the right decision? Obviously, that depends where you’re interviewing.

If you’re interviewing for Google or one of its wannabes, simply set up a series of focus groups to choose the correct shade of blue.

If you’re interviewing for Apple or its acolytes, sadly, white ink won’t work on a whiteboard, no matter how aesthetically satisfying that would be. So choose a boring metallic colour and confidently assert any answer you give with “I KNOW BEST”.

If you’re interviewing for Microsoft, the colour doesn’t matter; just chain the marker to the whiteboard and say “you can’t change the marker, it’s an integral part of the whiteboard”, even after it stops working.

If you’re interviewing for Facebook or one of its wannabes, trawl through previous posts by the panellists, cross reference it with those of their spouses, friends and their friends to find their favourite colours, factor in their Instagram posts, give a weighting to anything they’ve ever bought on a site they’ve signed in using Facebook, and use that colour while whispering “Earth is flat. Vaccines cause cancer. Trump is the saviour. Muslims are evil. Hire me” subliminally over and over again.

Good luck in the new job! May your stocks vest well.