I could, element by element, continue to add support (mostly by making CSS updates for each element to fit in with the rest of my style choices) as I came across specific needs for them, but not one to shy away from an exhaustive exploration, I decided to write this post and attempt to use every element.

A goal of the post, was to avoid delaying other future posts with CSS updates on a previously unused element, but in reality it took a year and a half to make all the updates for just this post! I am using the MDN Web Docs list of HTML elements as a reference which has more than 100 tags divided into a few categories, which I will also use in this post.

source: L

The purpose of the <keygen/> element was to allow a web browser to generate a private/public keypair upon submitting a form, in a way that allowed a web browser to be enrolled in a new client certificate.

source: L

Charts.css is a modern CSS framework. It uses CSS utility classes to style HTML elements as charts.

source: L

essentially the text of the label will be colored white if perceived-lightness<0.453 and black otherwise. However, when the perceived-lightness is very close to the threshold, we don’t trigger the min or max and actually get some sort of grey color for the label.

source: HN

We’d managed to get from ‘some quite strange things are happening to the header, beta banner and buttons’ to ‘text wraps unnecessarily within intrinsically-sized elements when using certain fonts and the inner HTML of the element contains a new line that is not preceded by a space’.

source: HN

But there is a whole bunch of lesser-used attributes that I was sure I’d forgotten about, and probably a whole bunch of attributes I didn’t even know existed. This post is the result of my research, and I hope you’ll find some of these useful to you, as you build HTML pages in the coming months.

source: HN

This research originated when I realized the default text reader on OSX, TextEdit is used to open files with TXT extension by default. On the interface of TextEdit, it looked like you can do basic customization to your text (you can turn text bold, italic, change color etc...), so I was wondering how a TXT file was storing and parsing this information. It seems it uses RTF format instead of TXT if we add customizations to the text.

source: HN

This post highlights a few powerful lines of CSS that do some serious heavy lifting and help you build robust modern layouts.

source: L

It is clear that it is still painful to develop a website or web app that works reliably across browsers.

source: HN

We were never supposed to be able to do what most publishers and tech companies do today. In fact, what if I were to tell you that the original specification for how cookies should be implemented in browsers pretty much defined what GDPR is today?

Imagine back to a time when people thought user agents would be agents for the user.

source: L

Despite the title, this isn’t so much a roundup of generic techniques but links to write ups of specific exploits. Good coverage.

As classic client-side vulnerabilities like XSS and CSRF get patched, CSP’d and SameSite’d into oblivion, niche attack techniques like DOM Clobbering are becoming ever more relevant. Michał Bentkowski recently used DOM Clobbering to exploit GMail, six years after I first introduced the technique in 2013. In this post, I’m going to quickly introduce DOM Clobbering, expand on my original research with some new techniques, and share two interactive labs so you can try the techniques out for yourself.

source: R

I wanted to form a better mental model of all the basic functionality that flexbox provides for all those common-denominator daily-purpose needs. This is a post about that I’ve been intending to write for while now. It’s hard to beat the succinctness and completeness that CSSTricks manages around this, so I won’t try. Flexbox is powerful, so trying to “simplify” it means we’d have to have assumptions

source: HN

If you find yourself wrestling with CSS layout, it’s likely you’re making decisions for browsers they should be making themselves. Through a series of simple, composable layouts, Every Layout will teach you how to better harness the built-in algorithms that power browsers and CSS.

Some free, some pay.

source: L

HTML: the good parts

source: HN

Browsers are complicated enough to have attack surface beyond memory safety issues. This talk will look into injection flaws in the user interface of Mozilla Firefox, which is implemented in JS, HTML, and an XML-dialect called XUL. With an Cross-Site Scripting (XSS) in the user interface attackers can execute arbitrary code in the context of the main browser application process. This allows for cross-platform exploits of high reliability. The talk discusses past vulnerabilities and will also suggest mitigations that benefit Single Page Applications and other platforms that may suffer from DOM-based XSS, like Electron.

source: L

In fact, shortly after I made my own personal home page, full of <marquee> tags, creative abuse of the <font> tag, and a color scheme which was hot pink and neon green, I showed it to a friend, who condescendingly said, “What, you didn’t even use frames?” He made me mad enough that I almost deleted my Geocities account.

Nice look back at how we used to do things.

In this era, we’d call stuff like this “DHTML” (the D is for “dynamic”), and we traversed the DOM as a chain of properties, doing things like document.forms[0].inputs[0] to access fields on the form.

What if we could make everyday checkboxes more beautiful and more intuitive? It’s easier than you think. We only need a small amount of CSS and JavaScript to make considerable improvements to your average checkbox UX.

If you are working on a custom control, a complex widget, or a novel interface element to integrate into a project, library, or framework, there are some core features you need to build.

These represent not just what works for users across the most contexts and preferences, but also what usability, accessibility, and internationalization practitioners (among many others) review to evaluate whether a solution can be used (purchased, integrated, discarded).

There is a class of UI performance problems that arise from the following situation: An input event is firing faster than the browser can paint frames.

In a previous post, I discussed Lodash’s debounce and throttle functions, which I find very useful for these kinds of situations. Recently however, I found a pattern I like even better, so I want to discuss that here.

Follow up: https://nolanlawson.com/2019/08/14/browsers-input-events-and-frame-throttling/

source: L