Snippets

Many have tried over the years to bring us web annotations. The lack of standards has been one of the key things holding these efforts back– a need we highlighted in the first of our 12 original principles back in 2013 and have been working towards ever since.

Yesterday, on February 23, things took a giant leap forward when the W3C, the standards body for the Web, standardized annotation.

Twenty four years after Marc Andreessen first built collaborative annotation into Mosaic and tested it on a few “guinea pigs” before turning it off, annotations have finally become first-class citizens of the web.

From the W3C Web Annotation co-chairs, Rob Sanderson and Tim Cole:

“Many websites already allow comments, but current […] systems rely on unique, usually proprietary technologies chosen and provided by publishers. Notes cannot be shared easily across the Web and comments about a Web page can only be saved and viewed via a single website. Readers cannot select their own tools, choose their own service providers or bring their own communities.”

 

So what exactly does this mean for you?

Comment widgets may soon become a thing of the past.

The W3C standards (called Recommendations) are a key milestone towards a future in which all pages could support rich layers of conversation without requiring any action by their publishers—because that capability can be built into the browser itself and be available as a native feature, just like web search. The shared vision is that conversations will be able happen anywhere on the Web, or even on documents in native apps, and inline instead of below-the fold, in a federated, standards-based way.

I got frustrated of not being able to tell the tabs apart as I was working on stuff. So this is my so-dumb-it’s-smart solution.

Copying text to the clipboard shouldn’t be hard. It shouldn’t require dozens of steps to configure or hundreds of KBs to load. But most of all, it shouldn’t depend on Flash or any bloated framework.

That’s why clipboard.js exists.

The box alignment specification details how items are aligned in the various layout methods. As different layout methods pose different constraints in terms of alignment, some of the behaviour of Box Alignment is layout method dependent. This cheatsheet compares alignment in CSS Grid Layout and Flexbox.

This example of using background sync looks like it’s specific to Twilio, but the breakdown of steps is broad enough to apply to many situations:

On the page we need to:

1. Register a Service Worker
2. Intercept the “submit” event for our message form
3. Place the message details into IndexedDB, an in browser database
4. Register the Service Worker to receive a “sync” event

Then, in the Service Worker we need to:

1. Listen for sync events
2. When a sync event is received, retrieve the messages from IndexedDB
3. For each message, send a request to our server to send the message
4. If the message is sent successfully, then remove the message from IndexedDB

And that’s it.

When a browser receives the HTML response for a page from the server, there are a lot of steps to be taken before pixels are drawn on the screen. This sequence the browsers needs to run through for the initial paint of the page is called the “Critical Rendering Path”.

Knowledge of the CRP is incredibly useful for understanding how a site’s performance can be improved. There are 6 stages to the CRP -

1. Constructing the DOM Tree
2. Constructing the CSSOM Tree
3. Running JavaScript
4. Creating the Render Tree
5. Generating the Layout
6. Painting