Jeremy Keith's Blog, page 29

One day to dConstruct

Just one more sleep until dConstruct���squee!

Not that I anticipate getting much sleep. My sleepnessness will partly be like that of a child on the night before Christmas. But my sleepnessness will also inevitably be that of an adult neurotically worrying about trifling details.

In reality, everything is all set. Thanks to the stellar Clearleft events team, I don���t need to lose any sleep. But my stupid brain can���t help but run a conveyer belt of potential problems through my mind: what about dongles? Power? Timings? What if there���s an impromptu rail strike? A deluge? Other emergencies you can���t even imagine?

I try to ignore those pestering pointless questions and instead think about the fantastic talks we���re going to get. I���m genuinely excited about each and every speaker. I���m pretty sure that once the day begins, I���ll forget all my worries and bliss out to the mind-expanding presentations.

The day before a conference feels kind of like the build-up to a battle. All the strategic decisions have been made, everything is in place, and now there���s nothing to do but wait.

I���ve communicated (or maybe over-communicated) all the relevant details to the speakers. And one week ago I sent one final email to the attendees with details of the schedule and some suggestions for lunch.

I also included this request:

Could you do me a favour? Would you mind getting a hold of a Covid test sometime in the next week and taking a test a day or two before dConstruct? (And if you test positive, please don���t come to the event.)

If you can���t get hold of a test (I know it can be tricky), then could you please bring a mask to wear when inside the venue?

I think asking everyone to take a test is a reasonable request, and nobody has objected to it. I worry that it���s yet another form of hygiene theatre (like providing anti-bacterial handwash for an airborne virus). After all, the antigen tests are most effective when you���ve already got symptoms. Taking a test when you don���t have symptoms might well give a negative result, but it doesn���t necessarily mean you don���t have Covid. Still, it���s a little intervention that might catch an infection that otherwise would���ve spread further.

I���m assuming that everyone coming to dConstruct is vaccinated. Maybe that���s naive on my part, but I figure if you���re intelligent enough to get a dConstruct ticket, you���re intelligent enough to protect yourself and others. So we won���t be requesting proof of vaccination. I hope my naivety aligns with reality.

See, this is all one more thing for my brain to gnaw on when I should be thinking about what a fantastic day of talks I���ve got ahead of me. Roll on tomorrow!

dConstruct update

Not long now until the last ever dConstruct. It���s on Friday of next week, that���s the 9th of September. And there are still a few tickets available if you haven���t got yours yet.

I have got one update to the line-up to report. Sadly, L��onie Watson isn���t going to be able to make it after all. That���s a shame.

But that means there���s room to squeeze in one more brilliant speaker from the vaults of the dConstruct archive.

I���m very pleased to announce that Seb Lee-Delisle will be returning, ten years after his first dConstruct appearance.

Back then he was entertaining us with hardware hacking and programming for fun. That was before he discovered lasers. Now he���s gone laser mad.

Don���t worry though. He���s fully qualified to operate lasers so he���s not going to take anyone���s eye out at dConstruct. Probably.

Work ethics

If you���re travelling around Ireland, you may come across some odd pieces of 19th century architecture���walls, bridges, buildings and roads that serve no purpose. They date back to The Great Hunger of the 1840s. These ���famine follies��� were the result of a public works scheme.

The thinking went something like this: people are starving so we should feed them but we can���t just give people food for nothing so let���s make people do pointless work in exchange for feeding them (kind of like an early iteration of proof of work for cryptobollocks on blockchains ���except with a blockchain, you don���t even get a wall or a road, just ridiculous amounts of wasted energy).

This kind of thinking seems reprehensible from today���s perspective. But I still see its echo in the work ethic espoused by otherwise smart people.

Here���s the thing: there���s good work and there���s working hard. What matters is doing good work. Often, to do good work you need to work hard. And so people naturally conflate the two, thinking that what matters is working hard. But whether you work hard or not isn���t actually what���s important. What���s important is that you do good work.

If you can do good work without working hard, that���s not a bad thing. In fact, it���s great���you���ve managed to do good work and do it efficiently! But often this very efficiency is treated as laziness.

Sensible managers are rightly appalled by so-called productivity tracking because it measures exactly the wrong thing. Those instruments of workplace surveillance measure inputs, not outputs (and even measuring outputs is misguided when what really matters are outcomes).

They can attempt to measure how hard someone is working, but they don���t even attempt to measure whether someone is producing good work. If anything, they actively discourage good work; there���s plenty of evidence to show that more hours equates to less quality.

I used to think that must be some validity to the belief that hard work has intrinsic value. It was a position that was espoused so often by those around me that it seemed a truism.

But after a few decades of experience, I see no evidence for hard work as an intrinsically valuable activity, much less a useful measurement. If anything, I���ve seen the real harm that can be caused by tying your self-worth to how much you���re working. That way lies burnout.

We no longer make people build famine walls or famine roads. But I wonder how many of us are constructing little monuments in our inboxes and calendars, filling those spaces with work to be done in an attempt to chase the rewards we���ve been told will result from hard graft.

I���d rather spend my time pursuing the opposite: the least work for the most people.

The schedule for dConstruct 2022

The last ever dConstruct will happen just over three weeks from now, on Friday, September 9th.

That���s right���if you don���t have your ticket for this event, you won���t get another chance. The conference with its eye on the future will become a thing of the past.

dConstruct is going to go out with a bang, a veritable fireworks display of mind bombs. A calligrapher, a writer, a musician, and a nueroscientist will be on the line-up alongside designers and technologists.

Here���s the schedule for the day:

8:30Registration begins9:50Opening remarks10:00George Oates10:30Lauren Beukes11:00Break11:30Seb Lester12:00Daniel Burka12:30Lunch14:00Sarah Angliss14:30Matt Webb15:00Break15:30L��onie Watson16:00Anil Seth16:30Closing remarks

So the first talk starts at 10am and the last talk finishes at 4:30pm���all very civilised. Then we can all go to the pub.

There isn���t an official after-party but we can collectively nominate a nearby watering hole���the Unbarred taproom perhaps, or maybe The Hare And Hounds or The Joker���they���re all within cat-swinging distance of The Duke Of York���s.

Lunch isn’t provided but there are some excellent options nearby (and you’ll have a good hour and a half for the lunch break so there’s no rush).

The aforementioned Joker has superb hot wings from Lost Boys Chicken (I recommed the Rufio sauce if you like ‘em spicy, otherwise Thuddbutt is a good all ‘rounder).

The nearby Open Market has some excellent food options, including Casa Azul for superb Mexican food, and Kouzina for hearty Greek fare.

And the famous Bardsley’s fish’n’chips is just ‘round the corner too.

So there’ll be plenty of food for the soul to match the food for your brain that’ll be doled up at dConstruct 2022.

No code

When I wrote about democratising dev, I made brief mention of the growing ���no code��� movement:

Personally, I would love it if the process of making websites could be democratised more. I���ve often said that my nightmare scenario for the World Wide Web would be for its fate to lie in the hands of an elite priesthood of programmers with computer science degrees. So I���m all in favour of no-code tools ���in theory.

But I didn���t describe what no-code is, as I understand it.

I���m taking the term at face value to mean a mechanism for creating a website���preferably on a domain you control���without having to write anything in HTML, CSS, JavaScript, or any back-end programming language.

By that definition, something like WordPress.com (as opposed to WordPress itself) is a no-code tool:

Create any kind of website. No code, no manuals, no limits.

I���d also put Squarespace in the same category:

Start with a flexible template, then customize to fit your style and professional needs with our website builder.

And its competitor, Wix:

Discover the platform that gives you the freedom to create, design, manage and develop your web presence exactly the way you want.

Webflow provides the same kind of service, but with a heavy emphasis on marketing websites:

Your website should be a marketing asset, not an engineering challenge.

Bubble is trying to cover a broader base:

Bubble lets you create interactive, multi-user apps for desktop and mobile web browsers, including all the features you need to build a site like Facebook or Airbnb.

Wheras Carrd opts for a minimalist one-page approach:

Simple, free, fully responsive one-page sites for pretty much anything.

All of those tools emphasise that don���t need to need to know how to code in order to have a professional-looking website. But there���s a parallel universe of more niche no-code tools where the emphasis is on creativity and self-expression instead of slickness and professionalism.

neocities.org:

Create your own free website. Unlimited creativity, zero ads.

mmm.page:

Make a website in 5 minutes. Messy encouraged.

hotglue.me:

unique tool for web publishing & internet samizdat

I���m kind of fascinated by these two different approaches: professional vs. expressionist.

I���ve seen people grapple with this question when they decide to have their own website. Should it be a showcase of your achievements, almost like a portfolio? Or should it be a glorious mess of imagery and poetry to reflect your creativity? Could it be both? (Is that even doable? Or desirable?)

Robin Sloan recently published his ideas���and specs���for a new internet protocol called Spring ���83:

Spring ���83 is a protocol for the transmission and display of something I am calling a ���board���, which is an HTML fragment, limited to 2217 bytes, unable to execute JavaScript or load external resources, but otherwise unrestricted. Boards invite publishers to use all the richness of modern HTML and CSS. Plain text and blue links are also enthusiastically supported.

It���s not a no-code tool (you need to publish in HTML), although someone could easily provide a no-code tool to sit on top of the protocol. Conceptually though, it feels like it���s an a similar space to the chaotic good of neocities.org, mmm.page, and hotglue.me with maybe a bit of tilde.town thrown in.

It feels like something might be in the air. With Spring ���83, the Block protocol, and other experiments, people are creating some interesting small pieces that could potentially be loosely joined. No code required.

Alternative stylesheets

My website has different themes you can choose from. I don���t just mean a dark mode. These themes all look very different from one another.

I assume that 99.99% of people just see the default theme, but I keep the others around anyway. Offering different themes was originally intended as a way of showcasing the power of CSS, and specifically the separation of concerns between structure and presentation. I started doing this before the CSS Zen Garden was created. Dave really took it to the next level by showing how the same HTML document could be styled in an infinite number of ways.

Each theme has its own stylesheet. I���ve got a very simple little style switcher on every page of my site. Selecting a different theme triggers a page refresh with the new styles applied and sets a cookie to remember your preference.

I also list out the available stylesheets in the head of every page using link elements that have rel values of alternate and stylesheet together. Each link element also has a title attribute with the name of the theme. That���s the standard way to specify alternative stylesheets.

In Firefox you can switch between the specified stylesheets from the View menu by selecting Page Style (notice that there���s also a No style option���very handy for checking your document structure).

Other browsers like Chrome and Safari don���t do anything with the alternative stylesheets. But they don���t ignore them.

Every browser makes a network request for each alternative stylesheet. The request is non-blocking and seems to be low priority, which is good, but I���m somewhat perplexed by the network request being made at all.

I get why Firefox is requesting those stylesheets. It���s similar to requesting a print stylesheet. Even if the network were to drop, you still want those styles available to the user.

But I can���t think of any reason why Chrome or Safari would download the alternative stylesheets.

Democratising dev

I met up with a supersmart programmer friend of mine a little while back. He was describing some work he was doing with React. He was joining up React components. There wasn���t really any problem-solving or debugging���the individual components had already been thoroughly tested. He said it felt more like construction than programming.

My immediate thought was ���that should be automated.���

Or at the very least, there should be some way for just about anyone to join those pieces together rather than it requiring a supersmart programmer���s time. After all, isn���t that the promise of design systems and components���freeing us up to tackle the meaty problems instead of spending time on the plumbing?

I thought about that conversation when I was listening to Laurie���s excellent talk in Berlin last month.

Chatting to Laurie before the talk, he was very nervous about the conclusion that he had reached and was going to share: that the time is right for web development to be automated. He figured it would be an unpopular message. Heck, even he didn���t like it.

But I reminded him that it���s as old as the web itself. I���ve seen videos from very early World Wide Web conferences where Tim Berners-Lee was railing against the idea that anyone would write HTML by hand. The whole point of his WorldWideWeb app was that anyone could create and edit web pages as easily as word processing documents. It���s almost an accident of history that HTML happened to be just easy enough���but also just powerful enough���for many people to learn and use.

Anyway, I thoroughly enjoyed Laurie���s talk. (Except for a weird bit where he dunks on people moaning about ���the fundamentals���. I think it���s supposed to be punching up, but I���m not sure that���s how it came across. As Chris points out, fundamentals matter …at least when it comes to concepts like accessibility and performance. I think Laurie was trying to dunk on people moaning about fundamental technologies like languages and frameworks. Perhaps the message got muddled in the delivery.)

I guess Laurie was kind of talking about this whole ���no code��� thing that���s quite hot right now. Personally, I would love it if the process of making websites could be democratised more. I���ve often said that my nightmare scenario for the World Wide Web would be for its fate to lie in the hands of an elite priesthood of programmers with computer science degrees. So I���m all in favour of no-code tools …in theory.

The problem is that unless they work 100%, and always produce good accessible performant code, then they���re going to be another example of the law of leaky abstractions. If a no-code tool can get someone 90% of the way to what they want, that seems pretty good. But if that person than has to spend an inordinate amount of time on the remaining 10% then all the good work of the no-code tool is somewhat wasted.

Funnily enough, the person who coined that law, Joel Spolsky, spoke right after Laurie in Berlin. The two talks made for a good double bill.

(I would link to Joel���s talk but for some reason the conference is marking the YouTube videos as unlisted. If you manage to track down a URL for the video of Joel���s talk, let me know and I���ll update this post.)

In a way, Joel was making the same point as Laurie: why is it still so hard to do something on the web that feels like it should be easily repeatable?

He used the example of putting an event online. Right now, the most convenient way to do it is to use a third-party centralised silo like Facebook. It works, but now the business model of Facebook comes along for the ride. Your event is now something to be tracked and monetised by advertisers.

You could try doing it yourself, but this is where you���ll run into the frustrations shared by Joel and Laurie. It���s still too damn hard and complicated (even though we���ve had years and years of putting events online). Despite what web developers tell themselves, making stuff for the web shouldn���t be that complicated. As Trys put it:

We kid ourselves into thinking we���re building groundbreakingly complex systems that require bleeding-edge tools, but in reality, much of what we build is a way to render two things: a list, and a single item. Here are some users, here is a user. Here are your contacts, here are your messages with that contact. There ain���t much more to it than that.

And yet here we are. You can either have the convenience of putting something on a silo like Facebook, or you can have the freedom of doing it yourself, indie web style. But you can���t have both it seems.

This is a criticism often levelled at the indie web. The barrier to entry to having your own website is too high. It���s a valid criticism. To have your own website, you need to have some working knowledge of web hosting and at least some web technologies (like HTML).

Don���t get me wrong. I love having my own website. Like, I really love it. But I���m also well aware that it doesn���t scale. It���s unreasonable to expect someone to learn new skills just to make a web page about, say, an event they want to publicise.

That���s kind of the backstory to the project that Joel wanted to talk about: the block protocol. (Note: it has absolutely nothing to do with blockchain���it���s just an unfortunate naming collision.)

The idea behind the project is to create a kind of crowdsourced pattern library���user interfaces for creating common structures like events, photos, tables, and lists. These patterns already exist in today���s silos and content management systems, but everyone is reinventing the wheel independently. The goal of this project is make these patterns interoperable, and therefore portable.

At first I thought that would be a classic /927 situation, but I���m pleased to see that the focus of the project is not on formats (we���ve been there and done that with microformats, RDF, schema.org, yada yada). The patterns might end up being web components or they might not. But the focus is on the interface. I think that���s a good approach.

That approach chimes nicely with one of the principles of the indie web:

UX and design is more important than protocols, formats, data models, schema etc. We focus on UX first, and then as we figure that out we build/develop/subset the absolutely simplest, easiest, and most minimal protocols and formats sufficient to support that UX, and nothing more. AKA UX before plumbing.

That said, I don���t think this project is a cure-all. Interoperable (portable) chunks of structured content would be great, but that���s just one part of the challenge of scaling the indie web. You also need to have somewhere to put those blocks.

Convenience isn���t the only thing you get from using a silo like Facebook, Twitter, Instagram, or Medium. You also get ���free��� hosting …until you don���t (see GeoCities, MySpace, and many, many more).

Wouldn���t it be great if everyone had a place on the web that they could truly call their own? Today you need to have an uneccesary degree of technical understanding to publish something at a URL you control.

I���d love to see that challenge getting tackled.

Directory enquiries

I was talking to someone recently about a forgotten battle in the history of the early web. It was a battle between search engines and directories.

These days, when the history of the web is told, a whole bunch of services get lumped into the category of ���competitors who lost to Google search���: Altavista, Lycos, Ask Jeeves, Yahoo.

But Yahoo wasn���t a search engine, at least not in the same way that Google was. Yahoo was a directory with a search interface on top. You could find what you were looking for by typing or you could zero in on what you were looking for by drilling down through a directory structure.

Yahoo wasn���t the only directory. DMOZ was an open-source competitor. You can still experience it at DMOZlive.com:

The official DMOZ.com site was closed by AOL on February 17th 2017. DMOZ Live is committed to continuing to make the DMOZ Internet Directory available on the Internet.

Search engines put their money on computation, or to use today���s parlance, algorithms (or if you���re really shameless, AI). Directories put their money on humans. Good ol��� information architecture.

It turned out that computation scaled faster than humans. Search won out over directories.

Now an entire generation has been raised in the aftermath of this battle. Monica Chin wrote about how this generation views the world of information:

Catherine Garland, an astrophysicist, started seeing the problem in 2017. She was teaching an engineering course, and her students were using simulation software to model turbines for jet engines. She���d laid out the assignment clearly, but student after student was calling her over for help. They were all getting the same error message: The program couldn���t find their files.

Garland thought it would be an easy fix. She asked each student where they���d saved their project. Could they be on the desktop? Perhaps in the shared drive? But over and over, she was met with confusion. ���What are you talking about?��� multiple students inquired. Not only did they not know where their files were saved ��� they didn���t understand the question.

Gradually, Garland came to the same realization that many of her fellow educators have reached in the past four years: the concept of file folders and directories, essential to previous generations��� understanding of computers, is gibberish to many modern students.

Dr. Saavik Ford confirms:

We are finding a persistent issue with getting (undergrad, new to research) students to understand that a file/directory structure exists, and how it works. After a debrief meeting today we realized it’s at least partly generational.

We live in a world ordered only by search:

While some are quite adept at using labels, tags, and folders to manage their emails, others will claim that there���s no need to do because you can easily search for whatever you happen to need. Save it all and search for what you want to find. This is, roughly speaking, the hot mess approach to information management. And it appears to arise both because search makes it a good-enough approach to take and because the scale of information we���re trying to manage makes it feel impossible to do otherwise. Who���s got the time or patience?

There are still hold-outs. You can prise files from Scott Jenson���s cold dead hands.

More recently, Linus Lee points out what we���ve lost by giving up on directory structures:

Humans are much better at choosing between a few options than conjuring an answer from scratch. We���re also much better at incrementally approaching the right answer by pointing towards the right direction than nailing the right search term from the beginning. When it���s possible to take a ���type in a query��� kind of interface and make it more incrementally explorable, I think it���s almost always going to produce a more intuitive and powerful interface.

Directory structures still make sense to me (because I���m old) but I don���t have a problem with search. I do have a problem with systems that try to force me to search when I want to drill down into folders.

I have no idea what Google Drive and Dropbox are doing but I don���t like it. They make me feel like the opposite of a power user. Trying to find a file using their interfaces makes me feel like I���m trying to get a printer to work. Randomly press things until something happens.

Anyway. Enough fist-shaking from me. I���m going to ponder Linus���s closing words. Maybe defaulting to a search interface is a cop-out:

Text search boxes are easy to design and easy to add to apps. But I think their ease on developers may be leading us to ignore potential interface ideas that could let us discover better ideas, faster.

The line-up for dConstruct 2022 ���revealed!

Alright, I���ve kept you in suspense for long enough. It���s time to reveal the magnificent line-up for dConstruct 2022.

I���ll now put names to the teasing list of descriptions I previously provided…

A technologist, product designer, and writer who defies categorisation. They���ve headed up a design studio, co-founded a start-up, and now consult on super-clever machine learning stuff. Their blog is brilliant.

This is Matt Webb. Matt previously spoke at dConstruct back in 2007, when he gave a talk called The Experience Stack

An award-winning author from South Africa whose work has recently been adapted for television. Some of their work is kind of sci-fi, some of it is kind of horror, some of it is kind of magical realism, and all of it is great.

This is Lauren Beukes. Lauren previously spoke at dConstruct in 2012, when she gave a talk called Imagined Futures.

An artist and designer who has created logos and illustrations for NASA, Apple, and Intel as well as custom typefaces for British Airways and Waitrose. A lover of letterforms, they are now one of the world���s highest-profile calligraphers posting their mesmerising work on Instagram.

This is Seb Lester.

A Canadian digital designer who has previously worked in the agency world, at Silicon Valley startups, and even venture capital. But now they���re doing truly meaningful work, designing for busy healthcare workers in low-income countries.

This is Daniel Burka. Daniel previously spoke at dConstruct back in 2008, when he gave a talk called Designing for Interaction.

A multi-instrumentalist musician, producer and robotic artist who composes for film, theatre and the concert stage. They play a mean theremin.

This is Sarah Angliss. Sarah previously spoke at dConstruct in 2013, when she gave a talk called Tech and the Uncanny.

An Australian designer and entrepreneur. They work in the cultural heritage sector and they���re an expert on digital archives. Their latest challenge is working out how to make an online photography archive last for 100 years.

This is George Oates. George previously spoke at dConstruct back in 2007, where she and Denise Wilton had a conversation called Human Traffic.

A tireless defender of web standards and co-author of the Inclusive Design Principles. They���re a member of the W3C Advisory Board and of the BIMA Inclusive Design Council. Expect some thoughtful takes on the intersection of accessibility and emerging technologies.

This is L��onie Watson.

A professor of neuroscience who is also a bestselling author. They conduct experiments on people���s brains and then talk about it afterwards. Their talks have been known to be mind-altering.

This is Anil Seth.

That���s quite a line-up, isn���t it?

Deducing the full line-up just from those descriptions wasn���t easy, but Hidde de Vries managed it. So Hidde gets a free ticket to dConstruct 2022 ���or, at least, he would if it weren���t for the fact that he already has a ticket (because Hidde is smart; be like Hidde). So a friend of Hidde���s is getting a free ticket instead (because Hidde is generous; be like Hidde).

If you���ve been putting off getting a ticket for dConstruct 2022 until you knew what the line-up would be, well, put off no longer.

You���ll want to be at the Duke of York���s in Brighton on Friday, September 9th. With this line-up of eight supersmart speakers, you know it���s going to be a fantastic day!

Control

In two of my recent talks���In And Out Of Style and Design Principles For The Web���I finish by looking at three different components:

a button,a dropdown, anda datepicker.

In each case you could use native HTML elements:

button,select, andinput type="date".

Or you could use divs with a whole bunch of JavaScript and ARIA.

In the case of a datepicker, I totally understand why you���d go for writing your own JavaScript and ARIA. The native HTML element is quite restricted, especially when it comes to styling.

In the case of a dropdown, it���s less clear-cut. Personally, I���d use a select element. While it���s currently impossible to style the open state of a select element, you can style the closed state with relative ease. That���s good enough for me.

Still, I can understand why that wouldn���t be good enough for some cases. If pixel-perfect consistency across platforms is a priority, then you���re going to have to break out the JavaScript and ARIA.

Personally, I think chasing pixel-perfect consistency across platforms isn���t even desirable, but I get it. I too would like to have more control over styling select elements. That���s one of the reasons why the work being done by the Open UI group is so important.

But there���s one more component: a button.

Again, you could use the native button element, or you could use a div or a span and add your own JavaScript and ARIA.

Now, in this case, I must admit that I just don���t get it. Why wouldn���t you just use the native button element? It has no styling issues and the browser gives you all the interactivity and accessibility out of the box.

I���ve been trying to understand the mindset of a developer who wouldn���t use a native button element. The easy answer would be that they���re just bad people, and dismiss them. But that would probably be lazy and inaccurate. Nobody sets out to make a website with poor performance or poor accessibility. And yet, by choosing not to use the native HTML element, that���s what���s likely to happen.

I think I might have finally figured out what might be going on in the mind of such a developer. I think the issue is one of control.

When I hear that there���s a native HTML element���like button or select���that comes with built-in behaviours around interaction and accessibility, I think ���Great! That���s less work for me. I can just let the browser deal with it.��� In other words, I relinquish control to the browser (though not entirely���I still want the styling to be under my control as much as possible).

But I now understand that someone else might hear that there���s a native HTML element���like button or select���that comes with built-in behaviours around interaction and accessibility, and think ���Uh-oh! What if there unexpected side-effects of these built-in behaviours that might bite me on the ass?��� In other words, they don���t trust the browsers enough to relinquish control.

I get it. I don���t agree. But I get it.

If your background is in computer science, then the ability to precisely predict how a programme will behave is a virtue. Any potential side-effects that aren���t within your control are undesirable. The only way to ensure that an interface will behave exactly as you want is to write it entirely from scratch, even if that means using more JavaScript and ARIA than is necessary.

But I don���t think it���s a great mindset for the web. The web is filled with uncertainties���browsers, devices, networks. You can���t possibly account for all of the possible variations. On the web, you have to relinquish some control.

Still, I���m glad that I now have a bit more insight into why someone would choose to attempt to retain control by using div, JavaScript and ARIA. It���s not what I would do, but I think I understand the motivation a bit better now.