Suffering a little whiplash after the rapid-fire removal and return of HTML5's element, I became curious about how the working groups at W3C actually, well, work. In particular, I noticed something about the wording of Steve Faulkner's original revert request: the editor of the HTML5 specification has made a change to the specification that is not supported for good reasons (see below, source: http://willyou.typewith.me/p/9Zl7I2dOKs) I therefore request a revert of this change http://html5.org/r/6783, so that it can be further discussed and decided within the consensus based HTML WG process. Emphasis (er, offset) added. The editor-vs.consensus theme chimed with an early, rather severe response to the original decision, calling Hickson's move 'self-contained'. Okay, everybody likes consensus, especially about standards. But the once-upon-a-time student of decision theory and commitment devices in me perks up skeptically at (even implicit) accusations of unilateralism. Lucky for me, an Invited Expert from the CSS Working Group at W3C has already posted a thorough treatment of how the CSS group works. The inside-view really gives a better feel for how people really act in the CSS group -- more than, for example, the official charter and process document of the HTML Working Group (which are very top-down, as presumably documents of this sort must be). CSS isn't HTML, of course. But CSS is now being developed in modules, rather than tangled, monolithic versions; and one of the differences between W3C and WHATWG (the 'other' HTML5 standards group) is that W3C is maintaining the kinda-versioned 'HTML5' designation, while WHATWG now treats HTML as a 'living standard' (complete with an exacting list of differences between the W3C and WHATWG specs). So versioning is a bit of a thorny point in both HTML(5) and CSS, and the issue of versioning must deeply affect any standards-regarding decision-making process. Indeed, the 'Inside View' grants modularization a whole page to itself. The full site goes into a lot of gritty details -- interesting for anyone interested in decision-making at this level, but especially for anyone involved in defining new web standards. But most of us aren't defining new web standards. So, for the rest of us, here's an outline of how the CSS Working Group does its thing, in tl;dr form: People and Roles: module editors (in charge of each module) CSS WG members (inner group of discussants) www-style contributors (all other discussants) Communication: mailing lists (technical discussions; high volume; members follow closely) telecons (1hr, once/wk; chair presides, scribe takes minutes) face-to-face meetings (3 full workdays, 3-4 times a year; half in USA, half split between Europe and Asia; one meeting takes place along with other W3C groups; addresses deepest/hardest/complexest issues) IRC (side-discussions during official telecons; unofficial chats) internal mailing list (mostly just planning meetings and other administrative tasks; any technical discussion is immediately moved to the public www-style list) www.w3.org (homepage with specs and blog) dev.w3.org (editor's draft specs, with revision history) wiki.csswg.org (lots of stuff, technical and administrative; general-purpose, like any good wiki) test.csswg.org (subdomain=giveaway) Making Decisions (usually somewhat informal; for this one read the full treatment) Modularization (first formulated during 2007 CSS-WG meeting in Beijing; page includes history and rationale) Spec Process: working draft (with numbered iterations, until Last Call Working Draft) candidate recommendation (calls for implementations; this usually means lots of implementations already exist) recommendation (=finished; arrived at only after two correct independent implementations exist) Sources of Innovation (full post discusses three different sources for CSS3 Backgrounds and Borders) Makes sense to me. The site is much more discursive than this outline summary -- and the discursiveness gives a better feel for what it's like to participate in the WG, so the read is pretty fascinating.

This recent article from Alyssa Frazee's blog provides a tutorial on how to help non-programmers get started with R. Given that R is a programming language popular outside of the development world - its focus on statistics and data visualization makes it popular among data scientists and sociologists, for example - the tutorial is a useful starting point and provides an outline of the need-to-know aspects of R. A lot of ground is covered in a series of quick and concise steps. For instance: How to download R and RStudio Working with graphics Data types Exploratory data analysis And more. An important detail here, though, is the intended audience of the tutorial: It is not for non-programmers attempting to learn R, but really for programmers attempting to teach R to non-programmers, especially in a concise, crash-course fashion. I think there would definitely be some value here for non-programmers or even programmers who are new to R (though experienced programmers interested in R might be better served elsewhere), because it provides an outline of things you need to research and learn, but I believe the intention is to be more of an informal teaching aid. Check out the full tutorial for some insight on how to help a non-programmer get started with R.

Explore this fun experiment using DuckDB to parse CockroachDB Change Data Capture output and query CockroachDB with DuckDB.

Learn how to build a chat server using gRPC, a modern remote procedure call framework, and its support for streaming data.

Several of us might be familiar with the clear () API in the Java collections framework. In this post, let’s discuss what is the purpose of this clear() API?

This PostgreSQL JSONB Cheatsheet presents a complete guide to PostgreSQL JSONB functions with examples and some demo code.

Looking for a more streamlined and intuitive way of querying databases, similar to the elegant LINQ constructs in C#? Check out the open-source library JPAStreamer.

The combination of Playwright and JavaScript allows you to create automated tests that can be run repeatedly and consistently, saving you time and effort.

In this article, the reader will learn how to perform a failover with a headless Aurora Global Database and its outcomes.

We’ll take a look at the imports field in package.json and how it can be used to configure path aliases for various use cases.

Learn out about how to query and write Apache Parquet files in the first post of our series on the popular data exchange format.

Using a common GitHub issue, the author will take the reader through the process of working through an issue on an unfamiliar codebase.

Thinking of learning Go in 2023? This book could be a good choice! The focus for Learning Go isn't just how to write programs in Go; it's how to write Go idiomatically.

In this blog, the author will take the reader through the step-by-step process of how to backup and restore a PostgreSQL database.

This blog discusses the importance of commonly used design patterns and how they provide reliable solutions to common software development problems.

In this blog post, I will demonstrate how to use OceanBase in a Python project. We will create a REST API that serves as the backend of a headless e-commerce app.

Discover how to simplify PDF generation using JSON to PDF API, leveraging LaTeX and JSON to create fully customizable documents with just a few changes in the JSON.

This article demonstrates how to create a cross-platform barcode reader application with Dynamsoft Barcode Reader, .NET MAUI, and Blazor.

This tutorial explores how to benefit from lowered latency, increased performance, and reduced infrastructure costs, as well as faster reads in more locations.

Learn about execution-type models and their functionality in Node.js with practical examples in this comprehensive article.