Just a text editor and a few hours

Rachel Andrew, once again, seriously hits the nail right on the head:

There is something remarkable about the fact that, with everything we have created in the past 20 years or so, I can still take a complete beginner and teach them to build a simple webpage with HTML and CSS, in a day. We don’t need to talk about tools or frameworks, learn how to make a pull request or drag vast amounts of code onto our computer via npm to make that start. We just need a text editor and a few hours. This is how we make things show up on a webpage.

I’ve been building interfaces for the web since 1996. I first picked this up when I found out that Netscape came with something called Netscape Composer. It didn’t take me long to realise that there was something beneath that WYSIWYG-like editor that interested me even more; HTML. Fast forwards a few years and I had now found out about the wonders of CSS (and the horrors of the browser wars of the early 2000s). One thing have remained constant right up until today; the web still consists of HTML and CSS. No matter the tooling, no matter the frameworks, you still end up with these things (and JavaScript, of course).

Learning the basics is not only a great entry point, as Rachel points out, it’s also a vital skill if you want to become a truly great web developer.

Mocking actions with buttons

A common scenario in my line of work is when I build UI components into complete pages, and somewhere on this page there might be a form. This form might contain a button, and when you click this button you want something to happen. Now, since pattern libraries and HTML prototypes very often are just static HTML, you are limited in what can happen. Naturally, when it comes to regular links, everything works out of the box since all you have to do is link pages together. Buttons, on the other hand, are a different story.

Let me first state, very clearly, that this should not be used in production. Ever. If you want to link to something – well, then we already have the excellent <a> element that does that job amazingly well.

With the disclaimers out of the way, let’s get down to business! We want our little prototype button to feature two things;

  • A <button> element
  • A URL that you will be taken to upon clicking the button

That’s really all we need. No need to complicate things, right?

The markup

<button type="button" data-prototype-url="link.html">Click me</button>

The type="button" attribute is optional, since the default type for a button is submit and that might be just what you want. In order to easily enter the URL in question we’ve got the data-prototype-url attribute. You can name it however you want. but it might be prudent to use a name that communicates its prototype use case as clearly as possible. Again, we do not want this type of code running on a live website.

The JavaScript

You guessed it. We can’t really do very much with this button unless we enlist the help of good ’ol JavaScript.

document.addEventListener('click', function (event) {
  if (event.target.matches('[data-prototype-url]')) {
    var button = event.target;
    var buttonURL = button.getAttribute('data-prototype-url');
    window.location.href = buttonURL;
    console.log(button.textContent + ' clicked');
  }
}, false);

Since we might have any number of buttons in a page, all that might potentially mock a scenario that takes us away from the current page, I found that the most preferrable method is to attach an event listener to the entire document and use event delegation to trigger the actions. This was something that I’ve picked up from Chris Ferdinandi. The short-short version of the script:

  1. Listen for clicks across the document
  2. Check if the click matches an element with the data-prototype-url attribute
  3. Grab the value of said attribute and send the user to that value (i.e. a URL)

That’s it! You now have a nifty solution for sending a user to another page by clicking a button, which will enable you to create mock scenarios for user testing or other purposes. If you easily want to test it out, I’ve got a version on Codepen going that you can play around with.

Just please don’t use it in production, ok?

Developing websites for Apple Watch

As of WatchOS 5, you are able to render web content on the Apple Watch. Marcus Herrmann did a write-up on the subject this summer and after stumbling over it, I couldn’t resist doing some testing on my own site. Actually, all I did was to add the following to my <head>:

<meta name="disabled-adaptations" content="watch">

Also, I did some quick and dirty experimenting with a (very ugly) media query that should target only Apple Watches. More testing is warranted.

/* Apple Watch only? How can this possibly come back to bite me in the ass? */
@media only screen and (max-width: 22em) and (max-height: 357px) {

  html {
    font-size: 6.5vmax;
  }
}

It works… ok, I guess? It might need some more work.

Update: It appears that my code blocks looks like crap at the moment. I will have to take a look at that at some point…

How we talk about CSS

Rachel Andrew has been working on new material for upcoming talks and she has been thinking about how CSS has been perceived in the web developer community in the past, and how we should perhaps modify our thinking about it in the future, given how far it has come.

CSS has been seen as this fragile language that we stumble around, trying things out and seeing what works. In particular for layout, rather than using the system as specified, we have so often exploited things about the language in order to achieve far more complex layouts than it was ever designed for. We had to, or resign ourselves to very simple looking web pages.

Back in 1998, when I started working with CSS, I found it to be mostly hacks and me trying to beat browsers into submission (I’m mostly looking at you, Internet Explorer). Now we have modern layout frameworks like Flexbox and CSS Grid, in addition to – as Rachel points out – many other technologies in CSS that might not be as well known. They are, however, very important.

No available space? That’s ok. Nothing is going to break. We often don’t know how much content we have, so CSS gives us sizing based on min and max content sizes, allowing items to grow and shrink into their containing boxes. […]

These features are part of the Box Alignment, CSS Intrinsic and Extrinsic Sizing, Writing Modes, and Logical Properties and Values specifications. These specifications tie together the individual layout methods into one system, with various methods to create the type of layout we need to see.

While there’s still much that is left to be desired, the technology has come such long way in just a few years. My day to day work has shifted significantly, from trying to make browsers jump through hoops while using CSS in ways it was probably never intended for, to actually letting me work more creatively.

One of the challenges over the years has been to communicate the importance of the frontend designer role. CSS is often seen as a “semi-language”, lacking features (interestingly such features that programmers often find useful), and would best be replaced with something else. This might be why we ended up with things like CSS-in-JS, convoluted preprocessor languages and insanities like CSS modules.

There is frequently talk about how developers whose main area of expertise is CSS feel that their skills are underrated. I do not think we help our cause by talking about CSS as this whacky, quirky language. CSS is unlike anything else, because it exists to serve an environment that is unlike anything else.

I agree wholeheartedly with this. But I also think that not appreciating how powerful CSS is, and instead turning to convoluted tooling to solve non-existing problems, is not helping either. I fear that when developers refuse to learn about the core strengths of CSS and instead utilise tools that are based on misunderstandings of how CSS is fundamentally working, that becomes a problem. The work that people like Rachel are doing is very important and I’d hate to see that be undermined. I suppose time will tell.