Two words that are often confused: conformance and compliance. What do they mean?

Listening to this Muse song while reading is optional.

Conform to a standard

When something conforms to a standard, it “meets” or “satisfies” specific requirements in a standard.

For instance, in the case of WCAG, those requirements include that:

• the requirements in a specific Level are met (eg Level A or Level AA).
• the claim is about full pages only, not parts of them (eg not components).
• technologies are only used in accessibility-supported ways, or there must be alternatives with technologies that are (in that case, those technologies may not interfere by having unstoppable audio (1.4.2), keyboard traps (2.1.2), unstoppable moving content (2.2.2), or flashes (2.3.1).

Additionally, to claim conformance on a page that is part of a process, every other page in that process must also be conformant.

Examples:

• “this website conforms with WCAG”.
• “this website meets the 55 WCAG success criteria of WCAG 2”.

Examples of what wouldn't make sense:

• “this component conforms with WCAG” (it cannot, as it is not a full page; you could say something like “this component is built with accessibility in mind” instead; see Can components conform to WCAG?).
• “this website complies with WCAG” (see compliance below).

How conformance in WCAG works is likely to change in WCAG 3, which is still many years from being released. It's one of the things we're currently discussing on in the Working Group.

Comply with a regulation

Then compliance. Organisations can comply with regulation, for instance the laws and regulations that EU Member States adopted following Directive (EU) 2019/882, the European Accessibility Act.

Sometimes they show that they do, by showing that they conform to a standard. The European Commission sometimes commissions standards for this very purpose, via “standardisation requests”. For instance, the next update to EN 301 549, currently in the works, was mandated under M/587. It is likely to become what provides “presumption of conformity with the essential requirements” for the requirements of the European Accessibility Act, once published in the Official Journal of the European Union.

Other languages

In Dutch, we speak of “conformeren aan een standaard” (conform to a standard) and “naleven van een wet” (comply with a law).

In German, conformance and compliance are both called “Konformität”. One could distinguish between “Standardkonformität” (with a standard) and “Gesetzeskonformität“ (with a law).

That's it, I hope this post helps folks. More translations welcomed!

---

Originally posted as Conformance vs compliance, accessibility standards edition on Hidde's blog.

Reply via email

With the fate of Goo.gl in the balance and many URL shortening/redirection services being either expensive or spammy, I wondered if I could find a free/cheap way of achieving the same. So I got myself a short domain (CLXI.org) and looked at using a GitHub repo with pages to redirect URLs. Turns out, this is […]

Mel Conway's seminal paper "How Do Committees Invent?" (PDF) is commonly paraphrased as Conway's Law:

Organizations which design systems are (broadly) constrained to produce designs which are copies of the communication structures of these organizations.

This is deep organisational insight that engineering leaders ignore at their peril, and everyone who delivers code for a living benefits from a (re)read of "The Mythical Man-Month", available at fine retailers everywhere.

Conway's Law is generally invoked to describe organisations working to solve well-defined problems, in which everyone is working towards a solution. But what if there are defectors? And what if they can prevent forward progress without paying any price? This problem is rarely analysed for the simple reason that such an organisation would be deranged.

But what if that happened regularly?

I was reminded of the possibility while chatting with a colleague joining a new (to them) Working Group at the W3C. The most cursed expressions of Conway's Law regularly occur in Standards Development Organisations (SDOs); specifically, when delegates refuse to communicate their true intentions, either through spurious objection or tactical silence.

This special case is the fifth column problem.

Expressed in Conwayist terms, the fifth column problem describes the way organisations mirror the miscommunication patterns of their participants when they fail to deliver designs of any sort. This pathology presents when the goal of the majority is antithetical to a small minority with a veto.

Reticence of certain SDO participants to consider important problems is endemic, in part, due to open membership. Unlike corporate environments where alignment is at least partially top-down, the ability of any firm to join an SDO practically invites subterfuge. This plays out calamitously when representatives of pivotal firms obfuscate their willingness to implement, or endlessly delay consideration of important designs.

Open membership alone would not lead to crisis, except that certain working groups adopt rules or norms that create an explosion of veto players.

These veto-happy environments combine with bad information to transmute opaque communication into arterial blockage. SDO torpidity, in turn, colours the perception of web developers against standards. And who's to say they're wrong? Bemoaning phlegmatic working groups is only so cathartic.

Eventually, code must ship, and if important features are missing from standards-based platforms, it becomes inevitable that developers will decamp to proprietary solutions.

Instances of the fifth column problem are frequently raised to me by engineers working in these groups. "How," they ask, "can large gatherings of engineers meet regularly, accomplish next-to-nothing, yet continue pat themselves on the back?"

The sad answer is "quite easily."

This dynamic has recurred with surprising regularity over the web's history,¹ and preventing it from clogging the works is critical to the good order of the entire system.

How Does This Happen?

The primary mechanism that produces consequential fifth column episodes is internal competition within tech giants.

Because the web is a platform, and because platforms are competitions, it's natural that companies that make both browsers and proprietary platforms favour their owned-and-operated offerings.

The rent extraction opportunities from controlling OS APIs are much more lucrative than an open ecosystem's direct competition. Decisions about closed platforms also do not have to consider other players as potential collaborators. Strategically speaking, managing a proprietary platform is playing on easy mode. When that isn't possible, the web can provide a powerful bridge to the temporarily embarrassed monopolist, but that is never their preference.

This competition is often hard to see because the decisive battles between proprietary systems and open platforms are fought behind the tallest, most heavily guarded walls of tech giants: budget planning.

Because budgets are secret, news of the web losing status is also a secret. It's a firing offence to leak budget details, or even share internally to those without a need to know, so line engineers may never be explicitly told that their mission has fundamentally changed. They can experience transitions away from the web as "Plan A" to "Plan Z" without their day-to-day changing much. The team just stops growing, and different types of features get priority.

OS vendors that walk away from the web after it has served their businesses can simply freeze browser teams, trimming ambitions around the edges without even telling the team that their status has been lowered. Capping and diverting funding away from new capabilities is easily explained; iteration on existing, non-threatening features is important, after all, and there are always benchmarks to optimise for.

Most fifth columnists are, therefore, unwitting and unknowing accomplices to corporate machinations well above their own pay grades. They cannot acknowledge that a vibrant web is not valuable to their firm because they will have never been told as much, and should they enquire, will hear only that the important work they are doing continues to be valued.

Mayfly Half-Lives

Until recently, the impact of fifth column tactics was obscured in a haze of legacy engines. Web developers take universality seriously, so improvements in capabilities have historically been experienced as the rate at which legacy UAs fall below a nominal relevance threshold.² Thanks to pervasive auto-updates, the historical problem of dead-code-walking has largely been resolved. Major versions of important browsers may have entire cradle-to-grave lifecycles on the order of two or three months, rather than IE 6's half-decade half-life.

This has clarified the impact of (dis)investments by certain vendors and makes fifth columnists easier to spot. Web developers now benefit from, or are held back by, recent decisions by the companies (under)funding browser development. If sites remain unable to use features launched in leading-edge engines, it's only because of deficiencies in recent versions of competing engines. This is a much easier gap to close — in theory, anyway.

The Web Platform's Power Structure

Web standards are voluntary, and the legal structures that create SDO safe-harbours (PDF) create the space in, and rules under, which SDOs must operate. SDOs may find their designs written into legislation after the fact, or as implementation guides, but there is a strong aversion to being told what to design by governments within the web community, particularly among implementers. Some new participants in standards arrive with the expectation that the de jure nature of a formal standard creates a requirement for implementation, but nothing could be further from fact. This sometimes leads to great frustration. Enshrining a design in a ratified standard does not obligate anyone to do anything, and many volumes of pure specifiction have been issued to little effect.

The voluntary nature of web standards is based on the autonomy of browsers, servers, and web developers to implement whatever they please under own brand.

Until Apple's flagrantly anticompetitive iOS policies, this right was inviolable because, when compromised, erosions of feature sovereignty undermine the premise of SDOs.

When products lose the ability to differentiate on features, quality, performance, safety, and standards conformance, the market logic underpinning voluntary standards becomes a dead letter. There's no reason to propose an improvement to the collective body of the web when another party can prevent you from winning share by supporting that feature.

The harms of implementation compellence are proportional to market influence. iOS's monopoly on the pockets of the wealthy (read: influential) has decisively undermined the logic of the open internet and the browser market. Not coincidentally, this has also desolated the prospect of a thriving mobile web.

The Mobile Web: MIA

It's no exaggeration to say that it is anti-web to constrain which standards vendors can implement within their browsers, and implementation coercion is antithetical to the good functioning of SDOs and the broader web ecosystem.³

In a perverse way, Apple's policy predations, strategic under-investment, and abusive incompetence clarify the basic terms of the web's power structure: SDOs are downstream of browser competition, and browser competition depends on open operating systems.

But Why?

Why do vendors spend time and money to work in standards, only to give away their IP in the form of patent licences covering ratified documents?

When vendors enjoy product autonomy, they develop standards to increase interoperability at the behest of customers who dislike lock-in. Standards also lower vendor's legal risk through joint licensing, and increase marketability of their products. Behind this nondescript summary often lies a furious battle for market share between bitter competitors, and standards development is famous for playing a subtle role. Shapiro and Varian's classic paper "The Art of Standards Wars" (PDF) is a quarter-century old now, but its description of these sorts of battles is no less relevant today that it was in '99.

Like this classic, most discussions of standards battles highlight parties with differing visions but similar goals — should margin-sizing or border-sizing be the default? — rather than situations where one vendor has a proprietary agenda and wishes to grow or maintain a capability gap versus standards-based alternatives. Denying features to open ecosystems makes high-tax proprietary platforms more attractive, and gridlock in standards is an effective strategy for accomplishing it. These cases are under-discussed, in part, because they're hard to perceive over short time periods or by observing a single working group.

Parties that maintain a footprint in standards, but are unhappy to see standards-based platforms compete with their proprietary offerings, only need a few pages from the Simple Sabotage manual (PDF).

Often, they will send delegates to important groups and take visible leadership positions. Combined with juuuuuust enough constructive technical engagement, obstreperous parties scarcely have to say anything about their intent. Others will raise their own hopes, and cite (tepid) participation as evidence of good faith. The fifth columnist doesn't need to raise a finger, which is handy, as doing nothing is the goal.⁴

Problem Misstatements

Working group composition also favours delays at the hands of fifth columnists. Encouraged by defectors, they regularly divert focus from important problems, instead spending huge amounts of time on trivialities because few customers (web developers) have the time, money, and energy to represent their own needs in committee. Without those voices, it's hard to keep things on track.

Worse, web developers generally lack an understanding of browser implementation details and don't intone the linguistic airs and shorthands of committeespeak, which vary from venue to venue. This hampers their ability to be taken seriously if they do attend. At the limit, dismissing pressing problems on technicalities can become something of a committee pastime.⁵

There's also a great deal of opportunity for fifth columnists to misrepresent the clearly stated needs of web developers, launching projects to solve adjacent (but unimportant) sub-issues, while failing to address the issues of the day. This is particularly problematic in big, old rooms.

A competent fifth columnist only needs to signal in-group membership to amplify the impact of their own disinterest in topics they would prefer to avoid. Ambiguous "concerns" and scary sounding caveats are raised, and oven-ready designs which do arrive are reframed as naive proposals by outsiders. Process-level critique, in lieu of discussing substance, is the final line of defence.

Deflecting important work is shockingly easy to pull off because organisations that wish to defeat progress can send delegates that can appeal to rooms full of C++/Rust engineers as peers. The tripwires in web API design are not obvious to the uninitiated, so it's easy to move entire areas of design off the agenda through critique of small, incongruent details.

The most depressing thing about this pattern is that these tactics work because other vendors allow it.

Closed For Business

One problem facing new areas in standards is that chartered Working Groups are just that: chartered. They have to define what they will deliver years in advance, and anything not on the agenda is, by definition, not in scope. The window in many SDO processes for putting something new into the hopper is both short and biased towards small revisions of the existing features. Spinning up new Working Groups is a huge effort that requires political clout.

Technically, this is a feature of SDOs; they jointly licence the IP of members to reduce risks to implementers and customers of adopting standards-based products. Patent trolls have to consider the mutual defences of the whole group's membership and cannot easily pick off smaller prey. Most developers never give a second thought to patent portfolios and do not live in fear of being personally sued for infringement.

This is a sign web standards are a smashing success, but also makes it unlikely that working developers understand that standards processes are designed with bounded IP commitments in mind. Internet SDOs have been so successful at caging the beast that generations of developers have never considered the threat or how it intersects with their interests.

This creates a tension: over the long term, SDOs and the ecosystems can only succeed if they take on new problems that are adjacent to the current set, but the Working Groups they create are primed by their composition and history to avoid taking on substantial expansions of their scope. After all, a good v2 of a spec is one that fixes all the problems of v1 and introduces relatively few new ones.

To work around this restriction, functional SDOs create incubation venues. These take different guises, but the core features are the same. Unlike chartered Working Groups, incubation groups are simple to create; no charter votes or large, up-front IP commitments. They also feature low bars to participation, can be easily shut down, and do not produce documents for formal standardization, although they can produce "Notes" or other specification documents that Working Groups can take up.

Instead, they tend to have substantial contributor-only grants of IP, ad-hoc meeting and internal debate mechanisms, and attract only those interested in working on solutions in a new problem space. In functioning SDOs, such "fail-fast" groups naturally become feeders for chartered Working Groups, iterating on problems and solutions at a rate which is not possible under the plodding bureaucracy of a chartered Working Groups's minuted and agenda-driven meeting cadence.

And that's why these sorts of groups are a first priority for sabotage by fifth columnists. The usual tactics deployed to subvert incubation include:

• Aspersions of bad faith by those working in incubation venues, either on the grounds that the groups are "amateur", "not standards-track",⁶ or "do not have the right people."
• Avoidance of engagement in incubation groups, robbing them of timely feedback while creating a self-fulfilling "lack of expertise" critique.
• Citing a high fraction failed designs within these groups as an indicator that they are not useful, obscuring the reality that the entire point of incubation is to fail fast and iterate furiously.⁷
• Accuse those who implement incubated proposals of "not following the process", "ignoring standards", or "shipping whatever they want"; twisting the goals of those doing design in the open, in good faith, under the SDO's IP umbrella.
• Demanding formalities akin to chartered Working Groups to slow the pace of design progress in incubation venues that are too successful to ignore.

The fifth columnist also works behind the scenes to reduce the standing and reputation of incubation groups among the SDO's grandees, claiming that they represent a threat to the stability of the overall organisation. Because that constituency is largely divorced from the sausage-making, this sort of treachery works more often than it should, causing those who want to solve problems to burn time defending the existence of venues where real progress is being made.

Survivorship Bias and The Problem of Big, Old Rooms

The picture presented this far is of Working Groups meeting in The Upside Down. After all, it's only web developers who can provide a real test of a design, or even the legitimacy of a problem.

This problem becomes endemic in many groups, and entire SDOs can become captured by the internal dramas and preferences of implementers, effectively locking customers out. Without more dynamic, fail-fast forums that enable coalitions of the willing to design and ship around obstructionists, working groups can lay exclusive claim to important technologies and retreat into irrelevance without paying a reputational cost.

The alternative — hard forking specifications — is a nuclear option. The fallout can easily blow back into the camp of those launching a fork, and the effort involved is stupendous. Given the limited near-term upside and unclear results, few are brave or foolish enough to consider forking to route around a single intransigent party.

This feeds the eclipse of an SDO's relevance because legitimacy deficits become toxic to the host only slowly. Risk of obsolescence can creep unnoticed until it's too late. As long as the ancient forms and traditions are followed, a decade or more can pass before the fecklessness of an important group rises to the notice of anyone with the power to provoke change. All the while, external observers will wonder why they must resort to increasingly tall piles of workarounds and transpilers. Some may even come to view deadening stasis, incompatibility, and waste as the natural state of affairs, declining to invest any further hope for change in the work of SDOs. At this point, the fifth columnist has won.

One of the self-renewing arrows in the fifth column's arsenal is the tendency of large and old working groups to indulge in survivorship bias.

Logically, there's no reason why folks whose designs won a lottery in the last round of market jousting⁸ should be gatekeepers regarding the next tranche of features. Having proposed winning designs in the past is not, in itself, a reliable credential. And yet, many of these folks become embedded within working groups, sometimes for decades, holding sway by dint of years of service and interpersonal capital. Experience can be helpful, but only when it is directed to constructive engagement, and too many group chairs allow bad behavior, verging on incivility, at the hands of la vieille garde. This, of course, actively discourages new and important work, and instead clears the ground for yet more navel-gazing.

This sort of in-group/out-group formation is natural in some sense, and even folks who have loathed each other from across a succession of identically drab conference rooms for years can find a sort of camaraderie in it. But the social lives of habitual TPAC and TC39 attendees are no reason to accept unproductive monopolies on progress; particularly when the folks in those rooms become unwitting dupes of fifth columnists, defending the honour of the group against those assailing it for not doing enough.

The dysfunctions of this dynamic mirrors those of lightly moderated email lists: small rooms of people all trying to solve the same problem can be incredibly productive, no matter how open. Large rooms with high alignment of aims can make progress if leadership is evident (e.g., strong moderation). What is reliably toxic are large, open rooms with a mix of "old timers" who are never moderated and "newbies" who have no social standing. Without either a clear destination or any effective means of making decisions, these sorts of venues become vitriolic over even the slightest things. As applied to working groups, without incredibly strong chairing, interpersonal dynamics of long-standing groups can make a mockery of the responsibilities resting on the shoulders of charter. But it's unusual for anyone on the outside to get any the wiser. Who has time to decipher meeting minutes or decode in-group shorthands?

And so it is precisely because fifth columnists can hire old timers⁹ that they are able to pivot groups away from addressing pressing concerns to the majority of the ecosystem, particularly in the absence of functional incubation venues challenging sclerotic groups to move faster.

Marketing Gridlock As Thoughtfulness

One useful lens for discussing the fifth column problem is the now-common Political Science analysis of systems through "veto points" or "veto players" (Tsebelis, '95; PDF):

Policy stability is different from both government stability and regime stability. In fact ... they are inversely related: policy stability causes government or regime instability. This analysis is based on the concept of the veto player in different institutional settings.

If we substitute "capability stability" for "policy stability" and "platform relevance" for "government/regime stability," the situation becomes clear:

Capability stability is different from platform relevance. In fact ... they are inversely related: capability stability causes platform irrelevance.

Any platform that cannot grow to incorporate new capabilities, or change to address pressing problems, eventually suffers irrelevance, then collapse. And the availability of veto points to players entirely hostile to the success of the platform is, therefore, an existential risk¹⁰ — both to the platform and to the SDOs that standardise it, not to mention the careers of developers invested in the platform.

This isn't hard to understand, so how does the enterprising fifth columnist cover their tracks? By claiming that they are not opposed to proposals, but that they "need work," without either offering to do that work, develop counter-proposals, or make any commitment to ship any version of proposals in their own products. This works too often because a pattern of practice must develop before participants can see that blockage is not a one-off rant by a passionate engineer.

Participants are given wide berths, both because of the presumption of voluntarity implementations,¹¹ and the social attitudes of standards-inclined developers. Most SDO participants are community-minded and collaboration-oriented. It's troubling to imagine that someone would show up to such a gathering without an intent to work to solve problems, as that would amount to bad faith. But it has recurred frequently enough that we must accept it does happen. Having accepted its possibility, we must learn to spot the signs, remain on guard, and call it out as evidence accumulates.

The meta-goal is to ensure no action for developers, with delay to the point of irrelevance as a fallback position, so it is essential to the veto wielder that this delay be viewed as desirable in some other dimension. If this sounds similar to "but neighbourhood character!" arguments by NIMBYs offer, that's no accident. Without a valid argument to forestall efforts to solve pressing problems, the fifth column must appeal to latent, second-order values that are generally accepted by the assembled to pre-empt the first-order concern. This works a shocking fraction of the time.

It works all the better in committees with a strong internal identity. It's much easier to claim that external developers demanding solutions "just don't get it" when the group already views their role as self-styled bulwarks against bad ideas.

When Is A "Consensus" Not Consensus?

The final, most pernicious, building block of Working Group decay is the introduction of easy vetoes via consensus decision-making. When vetoes are available to anyone in a large group at many points, the set of proposals that can be offered without a presumption of failure shrinks to a tiny set, in line with the findings of Tsebelis.

This is not a new problem in standards development, but the language gets muddy. I perceive two distinct versions:

• Strong Consensus refers to working modes in which the assent of every participant is affirmatively required to move proposals forward.
• Weak Consensus are modes in which preferences are polled, but "the sense of the room" can carry a proposal forward over even strenuous objections by small minorities.

Every long-term functional SDO operates by some version of Weak Consensus. The IETF bandies this about so often that the phrase "rough consensus and running code" is synonymous with the organisation.

But not every group within these SDOs are chaired by folks willing to overrule objectors. In these situations, groups can revert to de facto strong consensus, which greatly multiplies the number of veto holders. Variations on this theme can be even less disciplined, with only an old guard having effective veto power, whilst newer participants may be more easily overturned.

Strong consensus is the camel's nose for long-term gridlock. Like unmoderated mailing lists, things can spiral without anyone quite knowing where the error was made. Small groups can start under strong consensus out of a sense of mutual respect, only to find it is nearly impossible to revoke a veto power once handed out. A sense of fair play may cause this right to be extended to each new participant, and as groups grow, affiliations change, and interests naturally diverge, it may belatedly dawn on those interested in progress that the very rooms where they once had so much luck driving things forward have become utterly dysfunctional. And under identical rules!

Having found the group no longer functions, delegates who have invested large portions of their careers to these spaces have a choice: they can acknowledge that it is not working and demand change, becoming incredibly unpopular amongst their closest peers in the process. Or they can keep their heads down and hope for the best, defending the honour of the group against attacks by "outsiders". Don't they know whose these people are?

Once it sets in, strong consensus modes are devilish to unpick, often requiring a changing of the guard, both among group chairs and influential veto-wielders. Groups can lose internal cohesion and technical expertise in the process, heaping disincentive to rock even the most unproductive boats.

Defences Against Fifth Columns

The ways that web ecosystem SDOs and their participants can guard against embrittlement and fracture from the leeching effects of fifth columns are straightforward, if difficult to pull off socially:

• Seek out and remove strong consensus processes.

  The timeless wisdom of weak consensus is generally prescribed by process documents governing SDOs, so the usual challenge is enforcement. The difficulty in shaking strong consensus practices is frequently compounded by the status of influential individuals from important working groups who prefer it. Regardless, the consequences of allowing strong consensus to fester in rooms big enough to justify chairing is dire, and it must be eliminated root and branch.

• Aggressively encourage "counterproposal or GTFO" culture.

  Fifth columnists thrive in creating ambiguity for the prospects of meaningful proposals while paying no cost for "just asking questions." This should be actively discouraged, particularly among implementers, within the social compact of web SDOs. The price for imposing delay must be higher than having vague "concerns".

• Require Working Groups to list incubators they accept proposals from. Require they prove it.

  Many groups that fifth columnists exploit demonstrate a relative imperviousness to new ideas through a combination of social norms and studious ignorance. To break this pattern, SDOs should require all re-charters include clear evidence of proposals coming from outside the group itself. Without such collateral, charters should be at risk.

• Defend incubators from process attacks.

  Far from being sideshows, incubation venues are the lifeblood of vibrant SDOs. They must be encouraged, nurtured, and highlighted to the membership as essential to the success of the ecosystem and the organisation.

  In the same vein, process shenanigans to destabilise successful incubators must be fended off; including but not limited to making them harder to join or create, efforts to deny their work products a seat in working group chartering, or tactics that make their internal operations more veto-centric.

It takes a long time, but like the gravitational effects of a wandering planet out in the OORT cloud, the informational content of the fifth columnist's agenda eventually becomes legible by side effect. Because an anti-web agenda is easy to pass off under other cover, it requires a great number of observations to understand that this part of the committee does not want the platform to evolve. From that point forward, it becomes easier to understand the information being communicated as noise, rather than signal.

Once demonstrated, we must route around the damage, raising the cost of efforts to undermine the single most successful standards-based ecosystem of our lifetimes; one that I believe is worth defending from insider threats as well as external attack.

FOOTNOTES

1. The most substantial periods of institutional decrepitude in web standards are highly correlated with veto players (vendors with more than ~10% total share) walking away from efforts to push the web forward.

   The most famous period of SDO decay is probably the W3C's troubled period after Microsoft disbanded the Internet Explorer team after IE 6.0's triumphant release in 2001. Even if folks from Microsoft continued to go to meetings, there was nobody left to implement new or different designs and no product to launch them in.

   Standards debate went from pitched battles over essential features of systems being actively developed to creative writing contests about futures it might be nice to have. Without the disciplining function of vendors shipping, working groups just become expensive and drab pantomimes.

   With Microsoft circa 2002 casting the IE team to the wind and pivoting hard to XAML and proprietary, Windows-centric technologies, along with the collapse of Netscape, the W3C was left rudderless, allowing it to drift into failed XHTML escapades that inspired revulsion among the remaining staffed engine projects.

   This all came to a head over proposed future directions at 2004's Web Applications and Compound Document Workshop. WHATWG was founded in the explosion's crater, and the rest is (contested) history.

   The seeds of the next failure epoch were planted at the launch of the iOS App Store in 2008, where it first became clear that other "browsers" would be allowed on Cupertino's best-selling devices, but not if they included their own engines. Unlike the big-bang of Microsoft walking away from browsers for 3+ years, Apple's undermining of the W3C, IETF, and ECMA become visible only gradually as the total global market share of mobile devices accelerated. Apple also "lost" its early lead in the smartphone market share as Android ate up the low end's explosive growth. The result was a two-track mobile universe, where Apple retained nearly all influence and profits, whilst most new smartphone users encountered the predations of Samsung, HTC, LG, Xiaomi, and a hundred other cut-price brands.

   Apple's internal debates about which platform for iOS was going to "win" may have been unsettled at the launch of the App Store¹³, but shortly thereafter the fate of Safari and the web on iOS was sealed when Push Notifications appeared for native apps but not web apps.

   Cupertino leveraged its monopoly on influence to destroy the web's chances, while Mozilla, Google, and others who should have spoken up remained silent. Whether that cowardice was borne of fear, hope, or ignorance hardly matters now. The price of silence is now plain, and the web so weakened that it may succumb entirely to the next threat; after all, it has no champions among the megacorps that have built their businesses on its back.

   First among equals, Apple remains at the vanguard of efforts to suppress the web, spending vast sums to mislead web developers, regulators, legislators, and civil society. That last group uncomfortably includes SDOs, and it's horrifying to see the gaslighting plan work while, in parallel, Cupertino sues for delay and offers easily disproven nonsense in rooms where knowing misrepresentation should carry sanction.

   All this to preclude a competent version of the web on iPhones, either from Apple or (horrors!) from anyone else. Query why. ⇐

2. The market share at which any browser obtains "blocking share" is not well theorized, but is demonstrably below 5% for previously dominant players, and perhaps higher for browsers or brands that never achieved market plurality status.

   Browsers and engines which never gain share above about 10% are not considered "relevant" by most developers and can be born, live, and die entirely out of view of the mainstream. For other players, particularly across form-factors, the salience of any specific engine is more contextual. Contractual terms, tooling support, and even the personal experience of influential developers all play a role. This situation is not helped by major sites and CDNs — with the partial exception of Cloudflare — declining to share statistics on the mix of browsers their services see.

   Regardless, web-wide market share below 2% for any specific version of any engine is generally accepted as irrelevance; the point at which developers no longer put in even minimal effort to continue to support a browser except with "fallback" experiences. ⇐

3. It's not an exaggeration to suggest that the W3C, IETF, and ECMA have been fundamentally undermined by Apple's coercion regarding browser engines on iOS, turning the entire organisation into a sort of Potempkin village with semi-independent burgs taking shape on the outskirts through Community Groups like the WICG, which Apple regularly tries to tear down through procedural attacks it hopes the wider community will not trace back to the source.

   When competitors cannot ship their best ideas, the venues where voluntary standards are codified lose both their role as patent-pooling accelerators for adoption, as well as their techno-social role as mediators and neutral ground.

   The corporeal form continues long after the ghost leaves the body, but once the vivvifying force of feature autonomy is removed, an SDO's roof only serves to collect skeletons, eventually compromising the origanisation itself. On these grounds, self-aware versions of the W3C, IETF, and ECMA would have long ago ejected Apple from membership, but self-awareness is not their strong suit. And as long as the meetings continue and new drafts are published, it hardly deserves mention that the SDO's role in facilitating truly disruptive change will never again be roused. After all, the membership documents companies sign do not require them to refrain from shivving their competition; only that everyone keep their voices down and the tone civil.

   What's truly sad is how few convening services or reading the liturgy from the pews seem disturbed that their prayers can never again be heard. ⇐

4. This is about the point where folks will come crawling out of the walls to tell stories about IBM or Rambus or Oracle or any of the codec sharks that have played the heel in standards at one point or another. Don't bother; I've got a pretty full file of those stories, and I can't repeat them here anyway. But if you do manage to blog one of them in an entertaining way without getting sued, please drop a line. ⇐

5. You know, in case you're wondering what CSS WG was doing from '04-'21. I wonder what changed? ⇐

6. It's particularly disingenuous for fifth columnists to claim proposals they don't like are "not standards track" as they know full-well that the reason they aren't being advanced within chartered working groups is their own opposition.

   The circularity is gobsmacking, but often works. This reduces pressure fifth columnists from credulous web developers. Excusemaking is only possible because other vendors fail to call bullshit. Apple, e.g., would not be getting away with snuffing out the mobile web's chances were it not for a cosy set of fellow travellers at Mozilla and Google. ⇐

7. Internet APIs and protocols do not spring fully-formed from the head of Zeus.

   Getting to good, or even good-enough, requires furious iteration, and that means testing and prodding at proposals. The only way to get miles under a proposal is to try things, and that's what incubation venues specialise in. It is not a sign of failure that many proposals change shape in response to feedback, or that certain evolutionary branches are abandoned altogether. Much the opposite, in fact.

   It is only by trying, testing, iterating, and yes, abandoning many designs that we arrive at productive progress in web specs. Anyone who tells you differently is carrying water for fifth columnists and should be put on notice. They may not personally intend to undermine the web's future, but that's what treating iteration in design as failure does by proxy. ⇐

8. Most Web API design processes cannot claim any kinship to the scientific method, although we have tried mightily to open a larger space for testing of alternative hypotheses within the Chromium project over the past decade.

   Even so, much of the design work of APIs on the web platform is shaped by the specific and peculiar preferences of powerful individuals, many of whom are not and have never been working web developers. ⇐

9. Hiring "known quantities" to do the wrangling within a Working Group you want to scupper is generally cheaper than doing constructive design work, so putting in-group old-timers on the payroll is a reliable way for fifth columnists to appear aligned with the goals of the majority while working against them in practice. ⇐

10. One rhetorical mode for those working to constrain the web platform's capabilities is to attempt to conflate any additions with instability, and specifically, the threat that sites that work today will stop working tomorrow. This is misdirection, as stability for the ecosystem is not a function of standards debates, but rather the self-interested actions of each vendor in the market.

    When true browser competition is allowed, the largest disciplining force on vendor behaviour is incompatibility. Browsers that fail to load important web pages lose share to those that have better web compatibility. This is as close as you can get to an iron law of browser engineering, and every vendor knows that their own engine teams have spent gargantuan amounts of time and money to increase compatibility over the years.

    Put more succinctly, backwards compatibility on the web is not seriously at risk from capability expansions. Proposals that would imperil back compat¹² are viewed as non-starters in all web standards venues, and major schisms have formed over proposed, incompatible divergence, with the compatibility-minded winning nearly every skirmish.

    No SDO representatitive from these teams is ignorant of these facts, and so attempts to argue against solving important problems by invoking the spectre of "too much change, too fast" or "breaking the web" are sleights of hand.

    They know that most web developers value stability and don't understand these background facts, creating space for a shell game in which the threat of too much change serves to obsure their own attempts at sabatoge through inaction. Because web standards are voluntary and market share matters tremendously to every vendor, nothing that actually breaks the web will be allowed to ship. So armed, you can now call out this bait-and-switch wherever it appears. Doing so is important, as the power to muddy these waters stems from the relative ignorance of web developers. Educating them to the real power dynamics at work is our best bullwark against the fifth column. ⇐

11. There's no surer sign of the blindness many SDO participants exhibit toward the breakage of the voluntary implementation regime than that they extend deference on that basis to Apple.

    Cupertino's SDO delegates do not bear a heightened presumption that they will implement as soon as other ship. To the contrary, Apple have so thoroughly lowered expectations that nobody expects timely feedback on proposals, let alone implmementation commitments. Even when Apple is the last holdout. Cupertino sullies the brands they force to use WebKit's worst-of-the-worst implementation. It has been going on so long that it is now simply accepted as the status quo.

    This is entirely backwards, and Apple's representatitives should, instead, be expected to provide implementation timlines for features shipped by other vendors. God knows they can afford it.

    Until such time as Apple allows engine competition worldwide, it's only fair to expect (and demand) parity. Every Apple employee should feel the heat of shame every as they mutter "Apple does not comment on future product releases" while indefensibly harming the web. ⇐

12. The browser and web infrastructure community have implemented large transitions away from some regretted technologies, but the care and discipline needed to do this without breaking the web is the stuff of legend. Big ones that others should write long histories of are the sunsetting of AppCache and the move away from unencrypted network connections.

    Both played out on the order of half a decade or more, took dozens of stakeholders to pull off, and were games of inches adding up to miles. New tools like The Reporting API, Deprecation Reports, and Reverse Origin Trials had to be invented to augment the "usual" tool bag of anonymised analytics trawls, developer outreach, new limits on unwanted behaviour, and nudging UI.

    In both cases (among many more small deprecations we have done over the years), the care taken ensured that only a small fraction of the ecosystem was impacted at any moment, lowering the temperature and allowing for an orderly transition to better technology. ⇐

13. Your correspondent has heard different stories from folks who had reason to know about the period from '08-'10 when Apple pulled its foot off the gas with Safari.

    Given the extreme compartmentalisation of Apple's teams, the strategic import of any decision, and the usual opacity of tech firms around funding levels ("headcount") to even relatively senior managers, this is both frustrating and expected.

    The earliest dating puts the death of the web as "Plan A" before Steve Jobs's announcement of the iPhone at Macworld in June 2007. The evidence offered for this view was that a bake off for system apps and the home screen launcher had already been lost by WebKit. Others suggest it wasn't until the success of the App Store in '09 and '10 that Apple began to pull away from the web as a top-tier platform. Either way, it was all over by early 2011 at the very latest.

    WebKit would never again be asked to compete as a primary mobile app platform, and skeletal funding for Safari ensured it would never be allowed to break out of the OS's strategic straightjacket the way IE 4-6 had. ⇐

A few thoughts on the philosophical perspective, which I'd rebrand here as a useful perspective.

When I studied AI and then philosophy in university, pretty much every course prepared me to be annoyingly critical of AI. Sometimes I wish I wasn't aware of any of it.

Ethics, philosophy of language, epistemology and philosophy of science, aesthetics, history of philosophy, medieval philosophy, logic, philosophy of mind, metaphysics… that's roughly the list of areas my degree covered, plus some machine learning, neuroscience, functional programming and maths (those were not my strengths). For all of these research areas, it's trivial to draw lines to what we make computers do today. In many cases, the subject matter has been studied for for decades, sometimes for millenia.

I'm not really an expert in any of them. Just over four years in a university let me merely scratch the surface. I know where to find more information, roughly who the influential thinkers were and, in some cases, what they believed and how it contrasted with others. I learned not to accept things at face value, to consider perspectives and look for middle grounds.

But it's made me into someone who values the philosophical perspective. Mostly that of others, as, again, I barely scratched the surface. I value the philosophical perspective on the world, specificially on the role of technology in it. It is one that asks questions, carefully considers what's the right course of action, takes into account what actually constitutes knowledge and isn't afraid to go all meta on things.

The philosophical perspective seems daunting to some, but really, it's mostly an attitude. It's like a, method or series of methods, to make sense of things. Reasonably, carefully and evenly.

I find the lense of money much more daunting. I've never ran a multi billion dollar company, so maybe it is lack of familiarity and magnificent naivety… but it seems daunting to me to always try and fit everything into the scope of shareholder value.

The money lense forces one to value things that may not have value. With little room to question that. It's a lense that values hype and pretense over substance, that labels careful consideration as ‘hate’ or ‘blocking innovation’. A lense that brings prosperity, but also makes it really hard to make the downsides go away. Or even talk about them. The money lense avoids inconvenient meta questions.

Philosophers, in pretty much all areas of philosophy, are worth your attention. In general, people from the humanities bring much needed and more wide perspectives. They may not have ready made answers, but they can help ask the interesting questions, and call out inconsistencies.

Personally, I don't know if I'm always able, as it takes some mental toll to be the person in the room pointing out the concerns when others are excited about opportunities. I don't want to be the “hater” or the one “stiffling innovation”. Optimism is better for business, and the sceptical perspective is a needle I, and many others, want to carefully thread. I only scratched the surface, but I wish as technologists, we'd listen to the philosophers more.

---

Originally posted as We should listen to the philosophers more on Hidde's blog.

Reply via email

My first personal website was built 20 years ago. And no, you cannot find it archived anywhere! But currently, my home on the web is my blog at OhHelloAna.blog.

I participate in the IndieWeb community. And in case you're wondering about my qualifications: having a personal website already grants me enough qualifications to call myself someone who lives in the IndieWeb spirit. That’s right! By having your own personal website, you are as IndieWeb as it gets, whether or not you actively participate in the community. Having a personal website is all you have to do.

It's really great to be speaking alongside Calum about the IndieWeb. Calum and I met because Calum used to run the London chapter of the Homebrew Website Club. The Homebrew Website Club is a regular meetup for people passionate about creating, improving, or designing their own websites. Sometime in either 2017 or 2018, I attended one of those meetups, and I'm so glad I did because I wouldn't be here today if I hadn’t.

Calum and I have since retired from organising, but I noticed that Mark and James, the current organisers, are here on this call. It’s great that we’re all here together.

Before that, I first learned about the IndieWeb community from a talk by Jeremy Keith called The Building Blocks of the IndieWeb in 2017, at View Source Mozilla. It spoke to me on a deep level because I had always been someone keen on learning and sharing in public especially about code during my teenage years. But I had stopped once I started working professionally as a developer.

Somehow, the following year, I found myself on the same stage, sharing my frustration about how I wished our tech community would blog more. I also shared my fears that made me blog and share less.

What does it mean to have an online presence today?

For most people, being online means having an account on a website owned by a corporation or by someone with too much money. That means no transparency, no ownership, and no privacy. There are limitations:

• Platforms restrict what you can share (e.g., “link in bio”).
• You are exposed to potential harassment with little control over settings.
• You have no say in how these platforms operate.

And now more than ever, people are being more vocal about these limitations and consequences of them. For the past few years, you may have seen people, especially those in tech, sharing their nostalgia for the early 2000s internet which is all lovely and fun.

I recently came across a project called salvaged.nu, which recovers, repairs, and re-uploads Photoshop resources from lost personal blogs from the mid-2000s. They describe their mission as saving resources from the “commercial capitalist hellscape” that the web has become, hoping to inspire creativity again.

With the web becoming more of a commercial, capitalist hellscape everyday, we wanted to save what resources we could in order to encourage this creativity to blossom again. We aim to inspire people to experiment making digital collage again, whether it be for their own artistic creations or their personal blog, and pay homage to the creative teenagers that made these resources over 15 years ago.

I'm sharing this project in particular because it spoke to me on a deep level. I was one of those teenagers more than 15 years ago. I would spend all my time after school in forums learning how to code, copying snippets people shared, downloading brushes, creating brushes, scanning paper or leaves I found to create textures for Photoshop.

I would even install every random software I could find (dangerous, I know) to create whatever I wanted. I was obsessed with creating and sharing, and seeing people use what I made was like a dopamine rush driving me forward.

I spent the rest of my time writing tutorials, learning, and sharing openly on my little personal blogs and forums I was a moderator in. And it truly felt like we were all in this together. We would download phpBB forums, sign up to run fan sites, and take ownership of those fan sites. We would change MySQL databases to become admins of those websites. It was a bit wild, but it was so satisfying and rewarding.

I took this photo from a slide by Lu Wilson, who runs todepond, which captures this sentiment. The slide mentions several communities you may be familiar with: the small web, the humane web, Gemini, Gopher, the sustainable web, the personal web, the indie web, the cozy web, and others.

In the end of the day, there's one theme in common with these. All these communities share the same goal: creating little spaces that capture the joy of having your own web presence, free from capitalism, surveillance, pressure to perform, advertising, gatekeeping, and tech complexity. Instead, it’s about a human touch.

A case for the IndieWeb

I’m going to share with you how the IndieWeb community in particular has helped me, despite being a tech-y person myself.

The IndieWeb is a people-focused alternative to the “corporate web”. We are a community of independent and personal websites based on the principles of: owning your domain and using it as your primary online identity, publishing on your own site first (optionally elsewhere), and owning your content.

In other words, quoting myself (very lame I know):

To help create an alternative to the corporate web, members of the IndieWeb community have built tools that anyone can use on their personal website that helps create the interaction and community building between personal websites.

What does “people-focused” alternative to the “corporate web” mean?

The IndieWeb community believes that you should own your content and an option for that is to have your content and interactions first posted on your personal website and then shared on other platforms. Things like your articles, statuses, images, likes, comments etc would forever be in your ownership, with a permanent link and you can keep a record of it forever in case any platform/social media is deleted or you’re banned.

Banned! Yes! It can happen. Many times we find ourselves thinking "oh what if this thing gets deleted" or what if it's ownership changes and they suddenly create their own rules and you're suddenly banned? All your content is lost forever. If you care about that, then this is a great way to frame it: put it on your own website first.

It can look something like this:

What a lot of people in the IndieWeb community are quite keen of is the idea of publishing on your own blog. As depicted in the diagram, you would have "my new article" on your blog which you can share on some social media. Then, people can reply to the social media post which then backfeeds a copy of that reply back to your own website. People can also reply to your post using webmentions on their personal website. A reply that they would own. This is possible via protocols and apis that are documented in the IndieWeb wiki. This is what the community tries to advocate for: publish, owning it, share it and use whatever you want. But allow yourself to always be in control what interactions and content you own.

The IndieWeb community is about creating or improving your personal website while also helping others to build theirs, either by documenting or creating tools.

Emphasis on the helping others.

That's my main drive and my main passion about this community. Again, lame I know, but the quote above is from me because it is my experience. But it does seem quite fitting for everyone who cares about open tech.

Community members have put a lot of effort to share their experiences on the IndieWeb wiki. And we know it isn’t perfect!

This is my profile in the IndieWeb wiki, which is quite a shy one. My contributions pale in comparison to other members but that’s okay. You do what you can.

There's no pressure. You do what you can. We know that it is overwhelming for anyone who isn’t familiar with tech jargon to start - but the community tries in their free time to bridge that gap by suggesting services like Wordpress or Micro.blog that supports the IndieWeb features I mentioned before.

People in the community share how they built something on their own website all the time. They go through the wiki and they try to create happy paths for people to land and get the information they need. We really do try to constantly improve the wiki and we have a lot of discussions in our chats to make our community as tech jargon free as possible.

And you don't have to be a coder or developer to do this. People contribute to articles without necessarily writing code and that's really important. I wonder all the time whether people are very stuck into the idea that they can only contribute if they create an open source project or something very technical. That's not true. The majority of us likes to document decisions we make on our websites simply for fun. There will be wiki pages where people share why they choose to have a privacy policy page on their personal website. Then people in the community voluntarily share their own examples on their personal blogs which serves as an inspiration for everybody. They may share technical details of how they've done to it, if they want to, but the goal is for everybody is able to contribute.

A quick example is the guestbook page wiki entry. It has a general description and anybody can edit, contribute, and add themselves as an example. The wiki isn't behind a login or a paywall. It's free for everybody.

We like to document in the open, share examples and help out others.

Marty puts it into better words: “Talk with us - That’s why the IndieWeb chat exists. It’s a place where real actual people, who are working to use the web in ways that suit them, are ready to help in whatever ways we can. We love to share what is (and is not) working for us, what we’re trying, and so on. More importantly, we want to help you find ways of using the web that work for you.”

Take it easy

When I first started to participate in the community and attend their meet-ups and camps, I created this unnecessary pressure on myself to do and use all the protocols and apis suggested in order to create a full “social” experience from my website to corporate silos.

I need to underline that it really is unnecessary pressure. It was all in my head. The more I try to do those things, the more I failed and no progress at all was made. It can be limitations on time or my own tech abilities but in the end I had such tunnel vision that I would end up feeling overwhelmed, sad and behind. Because I created this fake deadline in my head in those IndieWeb camps, I wasn't progressing with anything I truly enjoyed doing on my personal website. Things like fun designs, experiments with textures, experiments with css or just writing.

You don’t have to over-engineer

I’ve been saying since 2018 that “my goal is to create my own micropub endpoint” and I end up only focusing on that and doing nothing else - to little success to this date. And I believe this is what stops a few people from fully embracing the fact that they too are keen on the community. Like myself in the past, there’s a lot of people who may fear that you’re only a real IndieWeb person if you build it all. As lame as it is, I’m going to once again quote myself:

I am not less than the other people in the IndieWeb community for not having a fancy, automated, cool setup on my personal website. Nobody has ever made me feel that way. It doesn’t matter if all you have is a simple page with your name and email.

If there is one place where you can do whatever you want and how you want is your personal website. I’m lucky to have found a community that supports this.

And it is true: a while back I wrote about the IndieWeb for Smashing Magazine and went a bit into more detail on a few tech bits but the reality is I don’t even implement the stuff I mentioned! I’m still as Indie Web as it gets!

There is no right or wrong way truly just what works for you.

Just get a personal website

If you find yourself thinking “I have no content to put on a personal website” hear me out: That’s not true and it shouldn’t be the point. The goal of a personal website is to be reachable. Your content might just be your name and your contact information. And that’s fine. You don’t have to be a content creator to have a website.

But if you want to share and learn in the open, it does open doors.

Being invited to be here today, being invited to write about the IndieWeb community, having my blog posts shared far and wide is all due to me embracing sharing my experiences on my blog. You can also create your own digital blog, bookmarks rounds up, week notes, tutorials. Content that is findable and make you reachable without paywalls or sign-up accounts.

Recently, Paul Robert Lloyd shared a presentation that is a beginner’s guide to the IndieWeb and made it all available on his website - truly living the IndieWeb spirit! And I really recommend it as it goes a bit into more technical detail and shares some ideas in detail.

And as for my current blog - it is a constant work in progress with ambition and lot of bugs.

We would love to see any of you pop by our chat and say hi - but it’s okay if you don’t feel like it. I know I am biased. Join whatever community or safe place that feels better for you - all we can wish for is that you find some time to embrace creating your personal website.