Jeremy Keith's Blog, page 31

Let���s get logical

I was refactoring some CSS on The Session over the weekend. I thought it would be good to switch over to using logical properties exclusively. I did this partly to make the site more easily translatable into languages with different writing modes, but mostly as an exercise to help train me in thinking with logical properties by default.

All in all, it went pretty smoothly. You can kick the tyres by opening up dev tools on The Session and adding a writing-mode declaration to the body or html element.

For the most part, the switchover was smooth. It mostly involved swapping out property names with left, right, top, and bottom for inline-start, inline-end, block-start, and block-end.

The border-radius properties tripped me up a little. You have to use shorthand like border-radius-start-end, not border-radius-block-start-inline-end (that doesn���t exist). So you have to keep the order of the properties in mind:

border-radius-{{block direction}}-{{inline-direction}}

Speaking of shorthand, I also had to kiss some shorthand declarations goodbye. Let���s say I use this shorthand for something like margin or padding:

margin: 1em 1.5em 2em 0.5em;

Those values get applied to margin-top, margin-right, margin-bottom, and margin-left, not the logical equivalents (block-start, inline-end, block-end, and inline-start). So separate declarations are needed instead:

margin-block-start: 1em;margin-inline-end: 1.5em;margin-block-end: 2em;margin-inline-start: 0.5em;

Same goes for shorthand like this:

margin: 1em 2em;

That needs to be written as two declarations:

margin-block: 1em;margin-inline: 2em;

Now I���ve said it before and I���ll say it again: it feels really weird that you can���t use logical properties in media queries. Although as I said:

Now you could rightly argue that in this instance we���re talking about the physical dimensions of the viewport. So maybe width and height make more sense than inline and block.

But along comes the new kid on the block (or inline), container queries, ready to roll with container-type values like inline-size. I hope it���s just a matter of time until we can use logical properties in all our conditional queries.

The other place where there���s still a cognitive mismatch is in transforms and animations. We���ve got a translateX() function but no translate-inline(). We���ve got translateY() but no translate-block().

On The Session I���m using some JavaScript to figure out the details of some animation effects. I���m using methods like getBoundingClientRect(). It doesn���t return logical properties. So if I ever want to adjust my animations based on writing direction, I���ll need to fork my JavaScript code.

Oh, and one other thing: the aspect-ratio property takes values in the form of width/height, not inline/block. That makes sense if you���re dealing with images, videos, or other embedded content but it makes it really tricky to use aspect-ratio on elements that contain text. I mean, it works fine as long as the text is in a language using a top-to-bottom writing mode, but not for any other languages.

That was dConstruct 2022

dConstruct 2022 happened last Friday, September 9th.

And what an event it was! All eight talks were superb. To have eight speakers and not a single dud is pretty great. To have eight speakers and each one be absolutely brilliant is more than I could���ve hoped for.

Hidde has written a summary of the talks. I loved each and every one. I got to sit there in the front row of the beautiful Duke of York���s cinema and watch these supersmart people blow my mind.

With six of the eight speakers having spoken at previous dConstructs, there was a lot of nostalgia in the air on Friday.

It was the last dConstruct.

A lot of people seemed surprised by this even though I kept saying it was a one-off event. Really, the last dConstruct happened in 2015. This year���s event was a one-time-only anniversary event.

Obviously because the day was so great, people expressed sadness and disappointment that there wouldn���t be another. But like I said, if a band like The Velvet Underground reforms to do one last gig, that���s pretty cool; but if a band like The Velvet Underground reforms to go on endless tours, that���s kind of sad. It���s time to move on. Have one last blow-out and go out in style.

And who knows? Maybe there���ll be some other kind of dConstructy gathering in a different format. Perhaps an evening salon event is more suited to this kind of interdisciplinary mish-mash. But as a one-day conference, dConstruct is now officially over.

To be honest, there was never any doubt that dConstruct 2022 would be an excellent day of talks. I knew that each of the speakers would deliver the goods. I played it somewhat safe with the line-up. Because this was a kind of ���best of��� event, I could draw upon speakers from previous years who were guaranteed to be mesmerising.

In a weird way, that also highlights the biggest problem with this year���s dConstruct. Even though every individual talk was terrific, when you pull back and look at the line-up in aggregate, you can���t help but notice its lack of diversity.

That���s on me.

I could show you the list of people I tried to get. I could talk you through the spots that fell through. But all I���d be doing is giving you excuses. I could show that my intentions were good, but intentions don���t matter as much as actions. The proof of the pudding is in the eating, and what we ate last Friday was wonderful but also sadly representative of dConstruct���s homogenous history. For that reason alone, it���s time to draw a line under dConstruct.

It was a bittersweet send-off. On the one hand, I got to enjoy a day of brilliant talks. On the other hand, I���m pretty disappointed in myself that the line-up wasn���t more diverse. I can make all the claims I want about valuing diversity, but they���re hollow without meaningful results.

So that���s enough looking to the past. I���m bidding farewell to dConstruct and setting my sights on the future, a future that features more and different voices.

If you came along to dConstruct 2022, thank you! If you enjoyed attending dConstruct just half as much as I enjoyed hosting it ���well, then I enjoyed it twice as much as you.

Sunday

I���m taking a nice long weekend break after dConstruct on Friday (I will of course have more to say on that���I���m collecting my thoughts still���but it was a wonderful day).

On Saturday I did absolutely nothing. It was just as well really, considering that I may have over-indulged in the pub on Friday evening after dConstruct was done. So a day of lounging around idly playing mandolin was just the ticket.

Yesterday, Sunday, I had one of those perfect leisurely days.

It began with a good bout of lazing about in the morning. Then, as lunchtime approached, Jessica and I went to a nearby pub for a Sunday Roast. In this case it was the Dover Castle. It turned out to be an excellent choice���top notch roasts!

While we were enjoying our lunch, Jessica spotted a poster on the wall for Bark In The Park, a local fun day of dog-centred activities. We were sure it had already happened earlier in Summer, but the poster said it was rescheduled to ���yesterday!

So after lunch we went to the park and spent the next few hours in the sunshine, petting very good dogs and enjoying the spectacle of such catgories as ���fancy dress���, ���best rescue���, and ���sausage catching.��� We left shortly before the announcement of ���best in show������my money was on Mayhem���so I could nip home, grab my mandolin, and head to The Bugle pub for the weekly 4pm Irish music session.

After two hours of jigs���n���reels, I headed home. The weather was still lovely. The forecast was for cloudy weather, but it was unexpectedly sunny. So I fired up the outdoor grill.

We grilled: one aubergine, halved and scored; one yellow courgette, halved; one green courgette, halved; half a hispe cabbage, quartered. Once they were nicely charred outside and soft within, we ate them with a drizzle of tahini sauce, accompanied by a green salad.

By that time the sun had gone down and it was time for a nice evening spent watching the latest episode of The Rings Of Power and drinking a nice cup of tea.

Like a said, a perfect leisurely day.

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.