DEV Community: Remy Sharp

Smarter throwing

Remy Sharp — Sat, 17 Oct 2020 00:00:00 +0000

With async/await becoming standard procedure for a lot of my code, I find myself wrapping blocks of code in try/catch to ensure I'm handling errors properly.

As a result of this, I also try to make my errors a little more useful at the same that I want to show you in this mini post.

The example

I have large validation process that runs through a series of statements and checks for particular problems and rules.

Each validation rule is run and if it fails, it throws with a message, such as:

export function validateFakeExample(token, scope) {
  if (token.text !== 'PRINT') return;

  const next = scope.peekNext();
  if (next.name !== AT) {
    throw new Error('Parser error, PRINT keyword should be followed by AT');
  }
}

My main function runs each of the validation rules all encapsulated inside of a try/catch because I also want to capture additional metadata that will help my user understand what caused the error.

So in my wrapping catch I have something like this:

} catch (error) {
  const message = error.message + `, "${token.text}" at: ${token.pos + 1}`;
  throw new Error(message);
}

This way, when the error is given back to my user, they'll see:

Parser error, PRINT keyword should be followed by AT, "INK" at: 10

Actually I use this pattern a lot, to catch the source error, interpret it, and throw new Error to help me better understand what was going on.

Except it can be smarter.

Being smart

When I call new Error a brand new error object is created. At this point a few things happen, specifically the stack is captured. A stacktrace is incredibly useful for debugging to trace back to the source of the problem.

Except, because I generated a brand new error, my stacktrace will originate from within the catch, which is helpful to a certain degree, but could be a lot more useful.

I could do something with the stack. At times I've added a console.log(error.stack) in the catch which I can go searching my logs for.

What I should do is instead of throwing a new Error, I can simply modify the original error.message property (🤦 why did it take me that long).

So now my code looks like this:

} catch (error) {
  error.message += `, "${token.text}" at: ${token.pos + 1}`;
  throw error;
}

My custom error message is passed by to the user (normally me) and my full stacktrace is retained.

Originally published on Remy Sharp's b:log

A px is not a px

Remy Sharp — Wed, 29 Jul 2020 00:00:00 +0000

Recently I was trying to extract some glyphs from some various fonts and in doing so I had a fundamental assumption challenged and dispelled.

A px in terms of fonts, is not a pixel. Or certainly not in the way I was using them.

For as long as I can remember I've used px for my CSS fonts. I tried with ems and usually ran into some sizing issues (better devs than me know how to use them properly). I had a lot of success with rems (not only because clearly they're named after yours truly…not), but if you asked me yesterday how to a make a font sized at 16 pixels, I'd have said 'font-size: 16px`.

If I'm honest, it's close enough and when a font size isn't quite right, I adjust. I tweak the font size, I tweak the line height, I tweak margins and padding until it looks right.

From a fully technical and exact perspective though, I didn't know what I was talking about!

When I realised

I was trying to render tiny fonts, no larger than 8 pixels wide into a canvas, and extract the pixel data (for a ZX Spectrum project). So I unwittingly set the font size in the 2D drawing API to 8px and ran the fillText method only to be faced with text that either didn't fit in the 8x8 square or was way too small.

I thought (incorrectly) that 8px meant the font would be 8 pixels tall. So utterly wrong.

This is also compounded by the fact that when you draw on a canvas, you need to specify the X and Y coordinate of the baseline - the specification suggests X/Y is the top left corner, but this isn't the case as drawing text in a canvas draws upwards so with x:0, y:0 you get nearly completely clipped text.

So I would have hoped the way to get the text to render on the canvas would be to add the pixel height of the font: x:0, y:8 but as we already know, the height of the font isn't 8 pixels.

What makes the height of a font?

I won't pretend to fully understand it (yet) but there's an excellent breakdown post by Vincent De Oliveira that examines how to align 100px to a font height and how it breaks up. The practical example that De Oliverira gets into is if they want to place a checkbox image aligned with the text. It's not as easy as it might first sound.

Also, more practically, there is the Capsize project that allows you to upload a font or select an existing Google font, and the page will read in the metadata about the font and help you adjust values to get the height of the font to best suit your needs.

As it turns out, in a lot of cases, when I'm thinking of the height of a font, I'm actually thinking about the height of a capital letter, which is the ascender in font metrics.

Bits of a font

In my side projects I spend a lot of time looking at binary data and parsing it in JavaScript so it made sense that I should poke around in the font to see if I could find these values myself.

Thus far I've only looked at TrueType fonts. The font file is structured as so:

Header (12 bytes) - which includes the font file signature and directly after includes the 32bit table count
Array of tables - each table includes: tag name (4 characters padded), checksum, file offset and length

With these small bits of information we will have an array of all the font tables that are included in the file. The tables of interests are required in the file format (according to Apple's documentation) and I want to look inside the tables: OS/2, hhea and head.

These tables can appear in any order in the file and have variable length - both depending on the tag name but also the version of the table.

To extract the information out of the file, first the file is uploaded into the browser and using the FileReader API I'll get an ArrayBuffer of the bytes:

`
input.onchange = (event) => {
const file = event.target.files[0];
const reader = new FileReader();
reader.onload = (event) => {
// do something with the buffer
handleData(event.target.result);
};
reader.readAsArrayBuffer(file);
};

For instance, to extract the capital height, I can create a view on the buffer and extract the 16bit value I need:

`
function handleData(buffer) {
const view = new DataView(buffer);
const tableCount = view.getUint16(5, true);

let capitalHeight = null;

// use a decoder to read the tag 4 character field
const decoder = new TextDecoder();

let ptr = 12; // where the header ends
for (let i = 0; i < tableCount; i++) {
// the tag is 4 characters long
const tag = decoder.decode(data.slice(ptr, ptr + 4));

// `offset` is where we find the table data in the file
const offset = view.getUint32(ptr + 8);

if (tag === 'OS/2') {
  // cap height sits 88 bytes from the start of the header
  capitalHeight = view.getInt16(offset + 88) / 1000;
}

// table headers are 16 bytes long
ptr += 16;

}
}

Now I can use the capitalHeight as I feel fit and all in the browser if I wanted to do work dynamically.

In practice, if the aim is to align text, then it makes sense to collect the font metric data ahead of time with a tool like Capsize or if that resource ever disappears I've extended the code I wrote earlier to a barebones TTF metrics extraction tool.

Originally published on Remy Sharp's b:log

Works offline

Remy Sharp — Fri, 17 Jul 2020 15:25:00 +0000

So many web sites work offline and we don't know it. It's kind of a beautiful aspect of the P in PWA: the web sites are progressively enhanced to be available even without an internet connection.

Yet browsers won't tell us so. More on that in a bit. How do we tell our visitors our sites work offline. How do we tell our visitors that they don't need an app because it's no more capable than the URL they're on right now?

I've created a Github issue (by way of creating an open forum) with a call for ideas and collaboration.

Please, if you're a designer, iconographer, tinkerer, please contribute your ideas: github#works-offline/logo/issues/1

I created the issue and the repo, but this isn't mine. In fact I immediately made issue 2 to that effect. This is an effort that requires us, the makers of the web, to take matters into our own hands.

Creating a visual cue to offline capability isn't a new thing and I'm certainly not the first. The most recent large waves came in the form of the Offline First initiative which is already over 5 years old and introduced by Hoodie. I remember A List Apart bringing support (albeit via an article) which created some great momentum.

Yet we're 5 years on and our visitors still don't realise how capable our sites are. Hell, I'd call myself pretty savvy but I didn't think for a moment that lodash's documentation would work offline until I happened upon it by accident.

I want to see some way that we can show, proudly, on our own web sites that our URLs work offline. As Jeremy reminds us:

…seeing as browsers have completely dropped the ball on any kind of ambient badging, it’s fair enough that we take matters into our own hands.

Branding matters

HTML. Web 2.0. Ajax. RSS. HTML5. PWA.

These are … "words" that meaning to a select few individuals, and yet are recognised by a broad range of every day people.

Some of these have logos attached to their ideas.

But these are all examples of technical terms making it out into the wider world and becoming brand ambassadors for technical progress and innovation.

Branding is incredibly powerful, as anyone hired to build an "HTML5 web app" knowing full well there may not actually be any "HTML5" in the resulting software. The exact definition doesn't matter. What matters is the hook.

Often we just need a word to lean on to help people grasp the idea and run.

What's also interesting is that a lot of these terms have a commonality that they don't mean just one thing. Just as "XMLHttpRequest is only part of the Ajax equation" as explained by Jessie James Garret and as PWA doesn't just mean "service worker" (though technically without service workers there is no PWA).

Likewise, "works offline" does not mean it has to satisfy a specific tick list. It's an idea, one that the makers of the web need to impress upon the world.

What does "works offline" mean?

I tried to spread the request for help via Reddit (a web site I very, very rarely visit) and one individual raised an interesting and valuable question (though it was phrased as a counter point): isn't this just saving a cached copy?

This is what we need to overcome with our software. For a site to work offline, is so much more, so much richer than the saved bones of an HTML page.

The reality, today in fact, is that with the service worker capability we can deliver the same offline experience as many appstore installed mobile apps. At a fraction of the cost.

Is working offline the same as installable?

The short answer, as you know, is no. But installable isn't better than "works offline". I've installed many applications from the app stores that I found out the hard way flat out didn't work without an internet connection (usually on my travels off of my home cellular network).

Yet if I install software from the app store I expect it to work offline.

If I visit a web site, I never expect it to work offline.

What if you could tell me, when I visited your web site, that it worked offline.

Absolutely yes, the browsers should provide badging. They could track if new entries were made to the origin's cache, and they could run a routed request for the URL I visited (stopping it from hitting the network layer preventing a double request if there wasn't middleware offline routing in place).

Yet there's no indication that will come from browsers in the short term. So how about we do it ourselves?

The same way RSS went. How did you know a web site offered a feed of their content (before RSS was baked into browsers…or even after they all removed it)? Imagery, logos, word marks.

RSS needed something obvious and clear that as a visitor I could subscribe. Dave Winer in 2005 (re?)started the conversation and Microsoft eventually picked up the ball (working with Mozilla if I read correctly) and that's how we got the RSS icon (the original post is still live, but missing the images).

Slapping a bit of "works offline" on my site would be a great first step.

We need your help

What I'd personally like to see as an outcome: some simple iconography that I can use on my own site and other projects that can offer ambient badging to reassure my visitor that the URL they're visiting will work offline.

Please, please contribute if you can. There's already been some really wonderful work and this is a stage of trying anything and everything out.

If, like me, your skills don't lie in design, then please help spread the word 🙏

Originally published on Remy Sharp's b:log

"Share the knowledge for free" [blog]

Remy Sharp — Sat, 04 Jul 2020 00:00:00 +0000

That title is in "air quotes" - just to be clear. I'm writing this so I don't have to repeat myself, because this sentiment has come up over and over and over. Not just for me, but for you, for your peers, your friends and many other anonymous creators out there.

"Share the knowledge for free" - anon.

The short reply is: no.

But, sure, let's take a moment to discuss this.

No?

Just to clear up the obvious first: we have bills to pay. I have a mortgage. I need food. I have kids and dependents.

I am able to work, therefore I do, and that work brings in money to our family and with that money we support our lives. Thank god my partner and I are able to work. I know there's others who are less fortunate and struggle at this basic need.

This isn't money grabbing nor taking advantage of entity handing over the money. Money, in this particular reality, is core to survival. You know this, we all know this.

I didn't say "work for free"

That's right, you said give away your knowledge for free. Sure, speaking is "free" (mostly). But acquiring that knowledge was not a free process for me.

It either took hours and hours and hours and actually years of learning. Along the way that involved buying books, buying software, coding and creating - all activities that no one is paying me for.

Yet still that knowledge is now in me, surely I can give that away? Well, if I can stick a Matrix-like spike in the back of my head and connect it to yours, then sure, I'd be willing to do that.

Except in reality we need to create a medium to transfer knowledge. This has costs, here's some of those costs off the top of my head for content I create:

The time spent writing content (long)
Time spent creating videos or audio (again, long)
Creating supporting websites for said content
Hosting fees for content (particularly video is yearly)

All this time is time spent not earning a living too.

So, I'm saying, for the record, "sharing your knowledge for free" is a misnomer. There is no "free" for me, nor for you.

This post is pretty much redundant, but maybe I'll be able to save myself the time (and thus cost) of replying this same sentiment every time I'm faced with this.

Free is not the default

There's many many examples of people sharing their work for free. I applaud you. I'm in this group, jsbin, nodemon, this blog and many other projects - but this is not a hard requirement of being part of the web or the world.

Free is not the default, it never was. I value your work. I believe we should be paid, and I've written about this before in You're Paying to Speak and Buy the coffee. I love paying for people's work on itch.io (I've bought an ungodly number of asset libraries for ideas that I'll probably never get around to).

I love supporting other people's work when I can. I'll continue to do so whilst I can afford to.

So get paid. Ask to be paid.

Your work is valuable and your time and experience is even more so.

Originally published on Remy Sharp's b:log

Clearing twitter

Remy Sharp — Fri, 19 Jun 2020 00:00:00 +0000

It's no surprise that twitter and similar sink holes are constantly trying to "engage" you so you can be sucked into their void. As someone who believes that the web belongs to its users and I browse the way I want I frequently change and block content on these sites so I can use them the way I would like.

So here's a quick share on how I'm doing that.

This is a simple example of how I think twitter can be improved - the picture below shows, highlighted in red, the "trending news" which really isn't news - or at least not news that I would recommend consuming. I certainly don't want to get my COVID-19 advice from the latest trending bullshit. More recently they have launched (possibly in split tests) a DM … "thing"? so I can use that to message people instead of…what, email? WhatsApp? Not sure. Anyway, it's shit that I don't need in my life, so it's getting ejected.

Step 1: get yourself uBlock Origin (the origin bit is important) available for most browsers

Step 2: use the right click - block element picker to stop content from bothering you

When you fire up the picker, you'll notice that Twitter (and other sites that don't believe in writing actual CSS classes) are using something to generate their CSS, which makes picking element using CSS selectors tricky.

Except, the trick is to look for aria roles or even data properties. As much as I dislike these big companies, they do try to support a broad range of users via good use of accessibility and we can use that to our advantage.

The uBlock Origin element picker will need a selector like ##div[aria-label="Timeline: Trending now"], I'm not sure what the double hash is about, but it works.

So now we can surf web pages the way we want.

Originally published on Remy Sharp's b:log

I fell for fraud

Remy Sharp — Sun, 10 May 2020 00:00:00 +0000

Saturday afternoon as I was mentally getting ready for the kids bedtime and drinking a Martinez (ooh, get me, though it was my first cocktail of the year,and no, I don't count G&T as a cocktail), I received a notification that O2 had failed to process my latest bill and that I should update my details.

My card had been updated recently and I'd had a slew of emails telling me that recurring payment had failed…though the last wasn't for a good few weeks.

With half and eye on my phone and partially aware of how O2 were being rubbish by asking for all my personal details that they should already have, I dutifully posted my details off a lucky fraudster.

Here's the SMS I received:

O2: Payment for your latest bill could not be processed by your bank. Please update your payment information via: https://myo2․bill231․com?o2=2

The URL then asks me to sign in, I did, and enter my address, I did, and enter my bank card and bank details, I did.

100% absent mindedly.

It's how accidents happen. My focus was on something else whilst my thumbs were on autopilot on my phone dolling out my details.

What's ironic is that my career is on the web and these kinds of hazards are part fo the territory and yet as seasoned as I think of myself I still made a simply and potentially costly mistake.

But the web we live in today is a bit of a jungle and sadly part of that is walking through long grass with snakes under foot. We conduct ourselves carefully and we navigate from one site to the next, and we protect ourselves with software, policies and knowledge, but what's important is that a bite from the snakes are not fatal.

It's how quickly you or I react to the incident that makes all the difference.Thankfully as soon as I hit send I realised my mistake.

The process was:

Consider every data point I shared with the fraudster website
For bank details (in my case), immediately contact the bank and block the card
Revoke any passwords shared (I already use 1password so I know the password is unique)
On going for the follow weeks, monitor the bank account to watch for unknown transactions - this is particularly important as the fraud web site had my account details which gives them enough to start a new direct debit (but this is also covered under direct debit protection)

The longer term changes that I'm putting in place are:

(Though I know it) never follow a link to enter banking details, always type the target web site in manually (i.e. if O2 contacts me, I visit O2 myself,not via a URL)
Adopt a new policy for receiving text messages which currently are almost exclusively 2FA codes, so it's almost worth disabling SMS messages entirely.

I've had exactly two previous fraud events in my past, both of which I learnt hard lessons from, but perhaps were unavoidable (unlike this more recent event).

The first was around 10 years ago, I received a direct message on twitter from a friend saying that some account details had been hacked and I should update my password immediately. I promptly followed the DM link inside the Twitter app,entered my password and … realised I'd been duped.

Following the link from inside Twitter's client meant that the URL bar was hidden from me, so I had no visual way of knowing what site I was on - it looked like Twitter (which was the point) so I fell for it. Since then I always disable"in browser" linking on apps I use.

The second was around 15 years ago. My laptop had been written off in an accident and it was sent to the insurance company, they paid me insurance money and the machine was to be destroyed. Except it wasn't. A few months after the incident, I was contacted via email telling me that this person had my laptop in front of them and was going to wipe the drive so that it could be resold.

Obviously this was a massive failing on the insurance company (I'm not with the many more and I forget who they were), but the individual on the other end of the email was just doing their job. He specifically got in touch to ask if he wanted me to send the contents of the drive before it was wiped.

I figured it might be a useful thing and said to go ahead. Except, he stated he couldn't get all the files off the drive, some were behind my password. I was hesitant when he asked for my password so he could send the files along, but said it made no difference to him as he was just helping me out, and "oh, I see you're a web developer, we need our web site redoing, maybe we could hire you…"and off my password went.

As soon as I hit send (yes, reoccurring theme) I felt my gut drop. It was a horrible feeling knowing that I'd just let some stranger into a personal space such as my hard drive. I emailed him back immediately, specifically requesting proof the drive had been wiped … but of course I never heard back.

Thank the stars there was nothing important on the drive, passwords or anythingsensitive and the thought haunted me for months, but nothing came of it.

Suffice to say I've never uttered a password again.

One additional policy I adopted after these events were that if a service was trying to authenticate me, particularly over the phone, it would have to be a call that I had made and not them contacting me. This is similar to the policy of entering a URL manually and not following links.

I guess we live and learn.

Originally published on Remy Sharp's b:log

Setting up Simon's TIL

Remy Sharp — Sat, 02 May 2020 00:00:00 +0000

I've followed Simon Willison's blog for long, long time and in my latest RSS catchup I saw his post about capturing his TIL.

I immediately earmarked it as something to follow and do myself (which I've now done but want to somehow pull across to my blog), and though Simon's post was excellent, it's not written as a set of instructions for doing yourself, so Today I Learned how to copy and tweak Simon's TIL repo.

Overview of how it works

Simon's post goes into the technical detail, but for a brief understanding this is what happens (assuming all the prerequisite files are in place):

All commits except on the README trigger the workflow (I wonder if this can be ignored though…)
The build_database.py file runs looking only at */*.md files (so one directory deep) and generates an sqlite database
The records in the sqlite database use the directory as the topic name (so one topic per TIL) and generates create and update times for the record based on the commit against each markdown file
Then update_readme.py runs to modify the repo readme inline, looking for  and  and inserts the table of contents (the good bit)
The README.md is committed under README-bot back into your repo
Finally the project is deployed to Now

Initial files

For this to work, you need your own github repo (since this uses github actions) and you need to specifically include the following files:

.
├── .github
│   └── workflows
│      └── build.yml
├── README.md
├── build_database.py
├── metadata.json
├── requirements.txt
├── templates
│   ├── index.html
│   ├── query-til-search.html
│   └── row.html
└── update_readme.py

I've pulled all the files into a single template repo here remy/simonw-til-template (which is a bit weird…) but it's a clean slate to work from.

Put these in your own github repo and leave the default action permissions as "Enable local and third party Actions for this repository".

Changes you need

If you look for USERNAME throughout the code, you can change this to your own github username (or your real name when used in the index page).

If you want to deploy to Vercel (formally Zeit) Now (which the action does by default), then you need to generate a new Now token and create a new token in the github repo under https://github.com/[YOUR-USERNAME]/[YOUR-REPO]/settings/secrets. The token needs to be called NOW_TOKEN.

If you don't want to deploy to Now, in the .github/workflows/build.yml remove the entire section starting at name: Deploy Datasette using Zeit Now.

Changes from Simon's original post and repo

If you used the template repo I made, you won't need these, but if you're skimming Simon's post a couple of things to be aware of:

He uses datasette publish now2 til.db but now2 (for us) should be now - it's using his datasette-publish-now project.
You'll need the templates directory (which initially I thought was a TIL), which is used by datasette to build the actual web pages you'll host on Now
If you're copying files one by one, the README.md needs to have the following template somewhere in the file: \n

Possible changes

For my own version I think I might migrate it to my own blog but follow the structure that's already there. That way I can reuse my own existing system for RSS so it's a little more similar to my links.

Originally published on Remy Sharp's b:log

We're not smarter than browsers

Remy Sharp — Wed, 29 Apr 2020 00:00:00 +0000

This morning during performing another search through npm for the package that matched my needs, I was feeling lazy and didn't want to type "npm i x" - thankfully npm provided a helpful "click to copy". And that's where it went wrong.

I recorded a video of my experience and this is part transcript, part conclusion, part repeating the obvious.

Look when you disable user-select or try to disable right-click on your web page and you're not only breaking the accessibility the page, but you're also making the rather bold statement that your code will never, ever break.

It seems too much of a risk.

This morning's npm visit was an excellent example. I wanted to copy the text, so I hover over "npm i chart.js" and it says briefly, if I catch it, "click here to copy" but mousing over the copy not doing anything, and indeed "clicking here" when I check my clipboard has not copied anything.

I'm clicking, but it's not copying.

Okay, bugs happen, clearly the copy button doesn't work. Instead let's select this text and just… copy? Nope, no, I can't select the text.

In fact, this is the one bit of text on that page that has been intentionally disabled for selecting, because we think as "web developers" we are smarter than the user and there's no way our code will ever break.

Well, I have news for us web developers: we are fallible. Our code will break.

So let's not break intentionally break accessibility features the browser works so hard to provide the user.

Stop preventing select - selecting text is useful both for copying, but also for reading text (see dyslexic users).

Stop not using buttons - buttons are clickable and we forget to add aria roles.

Stop reinventing links - they're magic and our versions are rubbish.

Stop scroll jacking - it's squarely in the the uncanny valley, and often scrolls to fast for content to be properly read.

Let's stop thinking we're smarter than the browser.

Enhance the browser, don't reinvent.

Originally published on Remy Sharp's b:log

How I'm teaching the kids coding for the web

Remy Sharp — Mon, 20 Apr 2020 09:00:00 +0000

Early this year (pre country-wide lockdown), my son, 8¼, asked that I start doing "Coding Mondays" with him and his sister (then 5½). Though the littlest wasn't so interested in programming (though she had some fun with BASIC, as story for another day), so far the boy has managed to make his own web site and start to get to grips with HTML and CSS. JavaScript is much further away, but he does also have the ability to publish all his changes entirely himself.

I thought it might be interesting to share how I'm explaining things to them, because they both seem to really understand it (or they're possibly just as bonkers as me, and random logic makes sense because decoding random is in their DNA… ¯_(ツ)_/¯ )

The tools

Initially they were both using JS Bin for HTML and CSS. This worked well because it focuses entirely on HTML at the start and they got real time feedback, along with a bit of code completion (as they were using the unreleased v5). There's the obvious added bonus that when I explained that I had written JS Bin - the code that they were typing their code into, it both blew their minds and made me rather chuffed.

The workflow would then be: download the file from JS Bin, send it from their Chromebook (a freebie from my upgrading my phone) using Snapdrop (a really great wifi file drop utility) to my machine, I would then put that in a directory and drag and drop into Netlify to release to his web site. This wasn't so bad, but was a little limited and brittle.

As the lessons continued, I decided to move up from JS Bin to Glitch - this way the boy could make new files, directories and upload images. Once he was using Glitch, I then wired Glitch up to Github and showed him how to Export to Github.

Now that he can export, I connected Netlify to the repository that he was exporting to and all of a sudden he has continuous deployment from a little export button in Glitch - and he's able to make new pages, change things, edit text and more. It's very cool (if perhaps complicated!).

The foundations of understanding

There's no point in trying to explain from the outset what HTML is, how it works over HTTP, about browsers and the DOM, let alone CSS, the cascade, specificity and more. It's a slow layering of knowledge acquisition for them.

So here's how I explained it.

I loaded up a browser and explained that "this is a web page". It's like a person in some ways. The bones are the HTML. Each bone has a name, we call them tags (or elements). Each bone does it's own special thing, like the <p> tag/bone will show some text.

I showed them a handful of web pages with all the styles removed and showed them that "this is the skeleton of the web page". All bits of text and angle brackets. The bone have names and they hold the bit of content.

But then, when we put the styles back, this is the skin over the skeleton. It's what makes each website look unique. Some can have different colours, shapes, heights and more. So the skin and the paint on the skin, this is CSS.

I explained that CSS is written differently from HTML, and keeping with tag only selectors showed how the name of the bone/tag is specified. For example: we want the foot bone to have a border. The syntax is simple enough that he's able to write the CSS selectors, property and values without prompting. He obviously does not know all the property types, but he's collecting them and writing notes in a book he keeps by his bed.

Finally, the brain and behaviour, the way the website can be interacted with is using the third layer: JavaScript. A brain is a complicated bit of machinery so we've not worked up to it yet, but they understand it with relation to themselves.

Just today the boy was trying to recreate a "spy agent ID card" with web (on my behest over doing it as a Google Doc), and he ended up with two divs that he needed to style differently, but the border he had used was (incorrectly) applied to both divs - because so far he only knows about element selectors.

So I introduce the class property to the HTML tags, and I tried to explain that the class property lets me group tags together. Immediately he pipes up with:

Like a classroom, if I want to select all the children my class, it's called Feathers, so it's the feathers class.

Wow, yes, exactly like that. Element selectors are like: children, teachers, parents, etc. Class selectors are like grouping as "year 1 teachers" or "Feathers children" class, and then I explained we could be even more specific and name the unique individual, known as an ID.

Now he has a basic understanding and grasp of CSS selectors and the first layer of specificity.

I'm genuinely not sure how or whether I can simplify JavaScript in the same way, but for now they both play around with Scratch and I think that's enough for the time being.

Originally published on Remy Sharp's b:log

Some elements hidden in full screen?

Remy Sharp — Thu, 09 Apr 2020 00:00:00 +0000

This is one of those "I spent nearly a day debugging this and I don't want to forget, so I'm writing it here for all eternity*

* Or as long as I renew the dns…

<--more-->

The problem

I had a React based project that had a main "board" view and triggered by the user, a modal would appear. This worked fine during development and though I didn't touch the code around the modal at all, the modal would not appear at all in mobile.

Why was that?

One thing I did notice, that eventually helped, was that the modal was only missing in full screen mode and when the website returned to non-full screen, the model would magically appear.

Some context

This is a snippet of the code that React boots in the browser. It's not so much that React caused me a problem, but more that with libraries like React, Vue and so on, is that they attach onto a node in the DOM that's not quite the root (I've suffered this in the past when trying to do a flex 100% wide and tall React app).

Note that the main board view the visitor sees is in <Game>.

<TableContext.Provider value={this.tableContext}>
  <Helmet>
    <title>{title(table)}</title>
  </Helmet>
  <UpdateNotice />
  <Game {...this.props} />
  <StandModal table={table} />
  <CloseWindowModal />
  <GettingStartedModal />
</TableContext.Provider>

The visitor would then load up the board and they tap "full screen", from thereon in, the modals, like <GettingStartedModal> is invisible.

It's in the DOM. In Chrome Canary I could see the modal in the DOM and I when I hovered over I could see devtools highlighting where it should be, but it wasn't there.

The modal didn't have any opacity, visibility or anything else funky going on. So, what was it 🤔🤷‍♀️

Full screen context

The full screen API and selector applies at a DOM node level. In this case, the DOM node for the <Game> component was going full screen. The component was designed to stretch across the viewport, so that's the only thing that would be seen when in full screen.

This meant the full screen context was on the DOM node that was a sibling of the modal.

The modal would need to be a child of the full screen context.

So that was it, I need to move the full screen to a higher up element. In the end I hacked about with React's useRef to make use of document.body but it certainly had me stumped for almost a day!

Originally published on Remy Sharp's b:log

Auto-growing inputs

Remy Sharp — Fri, 06 Mar 2020 10:00:00 +0000

I was tinkering with an electron app I wanted to make for screencasting and it needed some input elements that were positioned in a very tight spot. As powerful as HTML and CSS is, one weird thing about the input elements is that they don't (typically) size to their content.

Then I found a post by Ariel Flesler from 2013 and with a little tweaking, all of a sudden input elements can size themselves to their content. What's cool (to me), is that I knew Ariel from back in the jQuery hey days (/waves).

The effect

As I mentioned, I had a very small amount of space but also I wanted the text in this particualr example to visually close to the next input. The effect can be seen below:

Prior art

I've come across this problem in the past too. I posted two blog posts some 14 years ago! The first was a full JavaScript solution to create the effect, more elegantly was the so called bug in IE, and IE only, using the following CSS would allow the input elements to grow to fix their contents:

input { overflow: visible; }

How smart is that? Except it didn't work in any other browser, and it doesn't work today and thus it was quietly snuffed out.

What I really like about Ariel's solution though is that it requires no JavaScript at all and relies entirely on native features of HTML and CSS.

Ariel's auto-grow

Based on Ariel's CodePen demo which original intends to add placeholder support for contenteditable elemenent, I can adjust the code to use a span (instead of a div) and add a little CSS to improve upon his work (the CSS came from someone else via StackOverflow and comment on the CodePen demo IIRC).

The actual technique is frustrating obvious (but only once you know how), it uses contenteditable. Ariel's demo also shows how to include a placeholder and there's additional CSS that means that new lines are ignored (or more specifically: hidden).

[contenteditable="true"]:empty:before {
  content: "0";
  color: gray;
}

/* prevents the user from being able to make a (visible) newline */
[contenteditable="true"] br {
  display: none;
}

The element itself is a span, so it appears inline and now it's automatically focusable through the keyboard.

In the demo animation above, I'm binding the keypress event handler to cycle a number up or down within limits I've defined in data-* attributes, but that's out of scope.

Like I said, suprisingly obvious once you know it's done using contenteditable.

Originally published on Remy Sharp's b:log

Binary Tools

Remy Sharp — Fri, 06 Mar 2020 00:00:00 +0000

I've been tinkering on a 6502 project during the evenings spread over the last 3 months (via the excellent Ben Eater series) and in doing so I've started to build up a series of tools I use with binary.

(This post is probably only useful for future Remy)

I should add that I'm not sure how much of this will work on different systems and availability of tools, but I'll link where possible.

hexdump

hexdump - usually with hexdump -C file.bin to view hex and ascii output. Also compresses repeating patterns seen below where the line is simply *.

Really simple to use tool for viewing source hex on the command line.

hexdump -C rom.bin
00000000 a9 ff 8d 02 60 a9 55 8d 00 60 a9 aa 8d 00 60 4c |....`.U..`....`L|
00000010 05 80 ea ea ea ea ea ea ea ea ea ea ea ea ea ea |................|
00000020 ea ea ea ea ea ea ea ea ea ea ea ea ea ea ea ea |................|
*
00007ff0 ea ea ea ea ea ea ea ea ea ea ea ea 00 80 ea ea |................|
00008000

xxd

xxd can dump hex from binary, but also convert hex to binary.

This is used for dumping the entire hex content out. It also has a revert feature that lets me generate binary files from strings of hex. I've been doing a bit of work around unpacking old file formats, and generating snippet of binary data is useful.

Below you can see my generating a binary snippet for a ZX Spectrum+ .bas file header. The first column needs to be the offset (0 in this case).

echo "0 504c 5553 3344 4f53 1a01 00e7 0000 00" | xxd -r | hexdump -C
00000000 50 4c 55 53 33 44 4f 53 1a 01 00 e7 00 00 00 |PLUS3DOS.......|
0000000f

I could capture this output using … | xxd -r > out.bin and then process the binary elsewhere.

diffing binary / diffing hex

Using xxd above, I can combine diff tools to identify changes between binary (typically where I've got a typo and generated a slightly different file).

$ diff -u <(xxd -c 32 a.bin) <(xxd -c 32 b.bin) | diff-so-fancy

I'm adding diff-so-fancy into the mix to clearly highlight the changes in the file (the diff -u flag is needed to make this work properly).

In the diff above I can clearly see that the first block starts to match, but the does not.

Honourable mentions

od - very similar to hexdump and the tool I used to use to debug text files for rogue characters
strings - a great little goto when I'm looking for text inside binary files

Originally published on Remy Sharp's b:log