People Love Markdown Because It's Impossible to Hide the Crud  🔗 **Source:** [People Love Markdown Because It's Impossible to Hide the Crud](https://twitter.com/davewiner/status/2097304106935206334/?rw_tt_thread=True) > [!note]+ Document Notes > tags: [markdown, open-web, wordpress, bluesky, publishing-tools] > author: Dave Winer > source: X (twitter.com/davewiner) > reference: https://twitter.com/davewiner/status/2097304106935206334/ > date created: 2026-09-08 > > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > # 🏷️ Title: People love Markdown because it's impossible to hide the crud > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - The source thread carries **zero hyperlinks**. Checked programmatically against Reader's stored `html_content` (`<a href>` extraction, 0 matches), not inferred from stripped text. Every external claim below is sourced by the analyst, not the author. - [Markdown syntax, original Gruber spec (2004)](https://daringfireball.net/projects/markdown/syntax) - [CommonMark specification](https://spec.commonmark.org/) - [Microsoft 365 Copilot / Office Markdown export coverage](https://learn.microsoft.com/en-us/microsoft-365-copilot/) - [AT Protocol facets — how Bluesky encodes links and formatting](https://atproto.com/specs/lexicon) - [WordPress Markdown support in Jetpack](https://jetpack.com/support/markdown/) ## 📝 Summary - **What happened.** Dave Winer posted a 330-word thread arguing that Markdown's virtue is legibility — you cannot hide junk in it — and that its adoption by AI tooling is pulling publishing back toward the open web. He asks two products he follows closely, Bluesky and WordPress, to adopt it directly. - **Why it matters.** Winer is not a neutral commentator here: he co-designed RSS and OPML and has spent two decades arguing for plain, inspectable formats. The specific asks are concrete and shippable — Markdown-authored Bluesky posts, and a Markdown-only "WordPress Lite" tier with the current product renamed Pro. - **Key stakeholders.** Bluesky/AT Protocol engineering (post record schema, facets); WordPress core and Automattic product (editor, Jetpack Markdown, onboarding funnel); AI tool vendors that already prefer Markdown as their I/O format; writers who want portability over rendering fidelity. - **Risks and tradeoffs.** A Markdown-only WordPress tier would fragment the block editor's data model, which stores block markup as HTML comments in `post_content` — a Lite tier that writes raw Markdown is a second content format to migrate, index, and support forever. On Bluesky, arbitrary Markdown in post records changes what every third-party client must render and creates a new sanitization surface. Neither cost is acknowledged in the thread. - **Bottom line.** The framing flip is the durable idea and it survives disagreeing with the product asks: stop making AI useful *inside* your product, and make your product's output useful *to* AI. The Lite/Pro packaging is one implementation of that, not the point of it. ## 📖 Main Content Winer's central claim is aesthetic and structural at once. Markdown is a thin syntax over plain text: there is no attribute soup, no nested `<div>` scaffolding, no invisible styling payload. His phrase for that is that it is impossible to hide the crud — a format where the source is the document, so bloat is visible on inspection rather than buried in markup. He connects that legibility to a second observation: AI startups adopted Markdown as their default interchange format, and in doing so pulled a plain-text, web-native format back into the center of the toolchain. The Microsoft point is the thread's only empirical claim and its weakest link. Winer describes Microsoft offering users their data in Markdown as "a white flag" — a surrender by the vendor whose binary and OOXML formats defined document lock-in for thirty years, and an alternative to waiting for AI assistants to learn to parse Word files. No product, date, or announcement is named. The thread contains no links at all, so a reader cannot check what shipped or when. The two product asks are more specific. For Bluesky, he wants posts authored in Markdown, plus the affordances the 2006 Twitter design ruled out: optional titles, simple styling, real links, and editing. He explicitly frames the current constraint as an anachronism inherited from a phone-SMS-era character budget rather than a design decision worth defending in 2026, and offers a lower-risk path — run it as an experimental system and let users drive it — rather than demanding a change to the main product. For WordPress he proposes packaging: a Markdown-only Lite product as the default entry point, with today's WordPress becoming Pro and remaining the upgrade path. Two goals are stacked on one change. The first is onboarding — lower the barrier for someone starting fresh. The second is machine consumption: a Markdown-first WordPress emits content AI applications can read directly. That is where the sentence that carries the thread lands. Most vendors have spent two years trying to make AI useful inside their product; Winer argues the leverage runs the other way, and calls that difference in perspective the thing that follows the grain of the web in 2026. What the thread does not do is cost any of it. WordPress already has Markdown paths — Jetpack's Markdown module, `wp_kses`-filtered content, the block editor's own Markdown-ish paste handling — and none of them are a separate product tier. A Lite tier is a second content format alongside block markup, with migration, plugin compatibility, and REST-shape consequences the post never raises. ## 🗒️ Notes - Opening claim is definitional, not evidential: Markdown's popularity is attributed to the impossibility of hiding crud in it. No survey, adoption data, or example is offered. - Adoption claim: Markdown "has become a favorite of tech startups esp in the AI field." Verifiable in practice — system prompts, agent tool output, and LLM chat rendering are overwhelmingly Markdown — but unsourced here. - "Everything in Markdown, it's just enough HTML" is the compact statement of the whole position: sufficiency over expressiveness. - Microsoft framing: exporting user data as Markdown is called a white flag. Unnamed product, undated, no link. Confirmed absent, not merely stripped by text extraction. - The AI-readability argument is instrumental: publish Markdown so assistants do not have to parse proprietary binaries. - Bluesky ask, itemized: optional titles, simple styling, links, editing. All four are formatting-model changes, not client-side conveniences. - Bluesky historical claim: the constraint traces to "the 2006 version of Twitter," which he concedes may have been right then and calls an anachronism now. - Escape hatch offered: if it is hard in the current system, start an experimental one and let users drive, "the way we did when Twitter was new." - WordPress ask, itemized: Lite = Markdown only; current product renamed Pro; upgrade path preserved; barrier to entry lowered. - The perspective flip — make the product useful *to* AI rather than putting AI *in* the product — is stated as the "big difference," and is the most portable idea in the thread. - Closes with an open question to readers rather than a conclusion, which is consistent with the thread's function as a discussion prompt. - Register: first person, hedged with "imho" and "I'd love to see," advocacy rather than analysis. Read it as a proposal, not a report. ## 📚 References - [Daring Fireball: Markdown](https://daringfireball.net/projects/markdown/) — Gruber's original spec and design rationale. - [CommonMark spec](https://spec.commonmark.org/) — the standardization effort that resolved Markdown's ambiguity problem. - [Scripting News](https://scripting.com/) — Winer's own blog, where he has developed the "everything in Markdown" argument over several years. - [AT Protocol lexicon and rich-text facets](https://atproto.com/specs/lexicon) — how Bluesky currently encodes links and mentions without Markdown. - [Jetpack Markdown module](https://jetpack.com/support/markdown/) — the existing Markdown path in WordPress, which the post does not mention. - [Block editor `post_content` format](https://developer.wordpress.org/block-editor/explanations/architecture/data-flow/) — why a second authoring format has migration cost. ## 🗣️ Paraphrase - **Paragraph 1.** People like Markdown because its plainness makes bloat visible, and that plainness is why AI startups picked it up. Winer reads that adoption as the web reclaiming ground, and wants it to spread faster. - **Paragraph 2.** He has argued for years that Markdown is "just enough HTML." He treats Microsoft handing users their data in Markdown as capitulation by the biggest proprietary-format holdout, and as preferable to waiting for AI tools to learn to read Word files. - **Paragraph 3.** Because he cares about both WordPress and Bluesky, he wants both to adopt Markdown. - **Paragraph 4.** Bluesky should let people write posts in Markdown and drop constraints inherited from 2006-era Twitter: no titles, no styling, no editing. If that is hard inside the current system, build an experimental one and let users shape it. - **Paragraph 5.** WordPress should ship a Markdown-only Lite tier and rename the current product Pro. That lowers the barrier for new users and makes WordPress content directly consumable by AI applications — the reverse of the industry's usual move, which is stuffing AI features into the product. - **Paragraph 6.** He asks readers whether Markdown is the right way to add simple capabilities to the web as it exists now. ## 📰 Newsletter **"Just enough HTML" comes for the CMS.** Dave Winer — the RSS guy, so take the format opinions seriously — argues that Markdown won because you cannot hide junk in it, and that the AI toolchain adopting it is the open web quietly getting a win. His two asks: let Bluesky users write in Markdown, and give WordPress a Markdown-only Lite tier with today's product rebranded Pro. The packaging idea will start a fight, and it should — [block markup in `post_content`](https://developer.wordpress.org/block-editor/explanations/architecture/data-flow/) is not a thing you casually run a second format alongside, and [Jetpack has shipped Markdown](https://jetpack.com/support/markdown/) for years without anyone calling it a product tier. But skip the packaging and the sentence underneath it is worth pinning above your desk: most of us spent two years trying to make AI useful *inside* WordPress. Winer's asking what happens if you make WordPress useful *to* AI instead. Clean semantic HTML, real feeds, a readable REST shape, [an llms.txt](https://llmstxt.org/) — that is the same bet, and you can place it this quarter without renaming anything. Worth noting what is *not* in the post: a single link. For a 330-word argument that leans on a Microsoft product decision, that is a gap a reader has to fill themselves. ## ✅ Action Items #### DevRel - Developer advocacy: draft a talk on "publish for machines" — feeds, semantic HTML, and Markdown endpoints as one story rather than three. - Education: a 30-minute workshop on Markdown round-tripping into and out of the block editor, with the lossy cases shown honestly. - Developer experience: publish a working example repo that serves the same post as HTML, Markdown, and JSON from one WordPress install. - Developer marketing: measure whether a Markdown-first content endpoint changes AI-referral traffic; report the number either way. - Community management: run a discussion thread on Markdown-only authoring so the objections land before any RFC does. - Internal/external: sync with feed and REST maintainers before proposing anything that adds a second content format. #### OSPO - Policy & Governance: decide whether "machine-readable output" belongs in the project's stated compatibility promises. - License Compliance: confirm any Markdown parser added to core clears license review before it ships. - Security Management: a Markdown authoring path is a new sanitization surface — require a threat model, not a checkbox. - Software Inventory: track which parser (CommonMark, Parsedown, Jetpack's) any proposal would pull in. - Developer Support: office hours on content-format portability for teams considering headless. - Community Engagement: talk to Bluesky/AT Protocol folks directly rather than about them. - Strategic Alignment: tie "useful to AI" to a measurable KPI or drop it from planning language. #### Community - Maintainers: ask whether a Lite tier is a product question or a governance question before debating the feature. - Contributors: a good first issue — document exactly which Markdown constructs survive a block-editor round trip. - Sponsors: fund the round-trip fidelity test; it is unglamorous and nobody's roadmap owns it. - Ecosystem: coordinate with Ghost, Micro.blog, and Bluesky on shared expectations for Markdown post payloads. #### WordPress - Core: no Lite tier without a written migration story for `post_content`. - Core Performance: measure the parse cost of a Markdown path before it reaches a beta. - Core AI: evaluate whether emitting Markdown improves assistant accuracy against WordPress content; publish the eval. - Core Program Team: if this becomes an RFC, assign a cross-team owner spanning Core, Meta, and Documentation. - Mobile: Markdown authoring is a stronger fit on mobile than the block editor — worth a real test, not a poll. - Playground: build a Playground blueprint demoing a Markdown-only authoring flow so the argument is testable in a browser. - Community: a meetup topic that does not require anyone to have an opinion about AI to participate. - Training: add a Learn WordPress lesson on Markdown in the editor, including where it breaks. - Marketing: resist "AI-ready" as a slogan; describe the actual output format. - Support: pre-write the answer for "why did my Markdown post lose its formatting." - Design: study whether a Markdown-only editor genuinely lowers first-post time, or just moves the confusion. - Documentation: document current Markdown behavior in the editor — the gap Winer's post implicitly points at. - Photos: no direct action; Markdown does not change image contribution flows. - TV: caption and transcript files are already plain text — a small, real example of the thesis. - Polyglots: check that a Markdown path does not break RTL or translation string extraction. - Accessibility: Markdown produces predictable heading structure, which is an a11y argument nobody in the thread makes. - Meta: expose Markdown alongside HTML on .org content endpoints as a scoped experiment. - CLI: `wp post create --format=markdown` would test the idea without a product tier. - Hosting: no action until a format decision exists; premature host tooling would lock in the wrong shape. - Tide: no direct action. - Openverse: no direct action. - Themes: confirm theme rendering assumptions hold if `post_content` is not block markup. - Plugins: survey which plugins parse `post_content` directly and would break on a second format. #### The WPOCC - Programs: a documentation sprint on content portability fits the collective's remit better than a core patch does. - Projects: host the cross-project conversation with Bluesky and Ghost that no single vendor will convene. - Funding experiments: a microgrant for the round-trip fidelity test suite. ### FAIR - Technical independence: plain-text, inspectable formats are the same argument FAIR makes about metadata — say so explicitly. - Policies and covenants: portability of user content belongs in operator covenants, not just in blog posts. - Productized governance artifacts: add a "can users get their content out in a plain format" line to the scorecard. ## 🧪 Hypotheses 1. If WordPress exposed post content as Markdown at a stable endpoint, AI assistants would cite WordPress-hosted pages measurably more often than an HTML-only control set over 90 days. 2. A Markdown-only authoring path reduces time-to-first-published-post for new users by a measurable margin versus the block editor. 3. Round-tripping a representative corpus of block-editor posts through Markdown and back loses formatting in more than 10% of posts, which is the real blocker to a Lite tier. 4. Bluesky posts with titles and links get higher engagement than character-constrained equivalents, holding author and topic constant. 5. The "make your product useful to AI" framing predicts referral traffic better than "add AI features to your product" predicts retention. 6. Markdown adoption in AI tooling is driven by token efficiency and parse reliability, not by aesthetics — testable by comparing token counts and extraction error rates across formats. ## 📊 Methodology - **H1:** two matched sets of published posts, identical content, differing only in whether a Markdown representation is served. Track assistant citations via referral logs and periodic prompted retrieval checks over 90 days. - **H2:** onboarding A/B test on a hosted WordPress cohort; primary metric is time from signup to first published post; guard against novelty effects with a 30-day window. - **H3:** corpus study. Sample 1,000 posts across block types, convert to Markdown and back, diff the rendered DOM, classify losses by block type. This is the cheapest study here and the most decision-relevant. - **H4:** not directly testable without Bluesky shipping the feature; the nearest proxy is comparing cross-posted content on Bluesky against the same content on a title-supporting platform. - **H5:** longitudinal comparison of vendor strategies against public traffic and retention data; weak design, confounded by company size — treat as directional only. - **H6:** measure tokenization cost and extraction accuracy for the same document rendered as HTML, Markdown, DOCX, and PDF across several model families. ## ❓ Questions - Which Markdown constructs actually survive a block-editor round trip today, and who owns that answer? - Does a Lite/Pro split solve an onboarding problem, or does it move the complexity to the upgrade moment? - What specifically did Microsoft ship that Winer calls a white flag — and does it apply to user documents or only to assistant output? - Would Bluesky's third-party clients absorb Markdown rendering, or would formatting fragment across the ecosystem? - Is "impossible to hide the crud" a property of Markdown, or of any format whose source is its presentation? - If AI consumption is the goal, is Markdown the right target — or is it structured JSON with a Markdown rendering? ## 🔮 Future Research - Empirical work on format choice and retrieval quality: does serving Markdown change what assistants extract and cite, or only how cheaply they do it? - A survey of CMS authoring formats and their migration histories — how often has a second content format been added and later removed? - Study of the AT Protocol's facet model as an alternative to inline markup, and whether it generalizes better than Markdown for social posts. - Investigation of onboarding friction in block editors that is not about format at all: naming, publishing flow, theme selection. - Longitudinal tracking of "just enough" format arguments — Markdown, RSS, OPML — and what determined whether each held. ## 💡 Implications - **Practice.** The actionable version of this post is not a product tier. It is: emit clean semantic HTML, keep feeds working, and make a plain-text representation available. Any site can do that now. - **Policy.** Content portability in a plain format is a reasonable line item in a hosting or platform covenant, and a more concrete ask than "openness." - **Security.** Any Markdown authoring path needs the same sanitization discipline as HTML input. "It's just text" is how injection surfaces get waved through. - **Education.** Markdown's low ceiling is a teaching advantage; the block editor's ceiling is a teaching cost. Both are real, and curricula should stop pretending the tradeoff does not exist. - **Funding.** The unglamorous round-trip fidelity work is exactly the kind of thing no vendor roadmap funds and a collective could. ## 🧠 Learning Styles Assessment - Reading level estimate: **Flesch–Kincaid grade 6.2, Flesch Reading Ease 76.7** (computed on the extracted post text: 324 words, 22 sentences, 14.7 words per sentence). Deliberately conversational; the vocabulary load is low and the ideas are carried by short declaratives. #### 👀 Visual learners - Present: nothing — no diagrams, screenshots, or code samples. - Improve: a before/after showing the same post as block markup and as Markdown would do most of the argument's work in one image. #### 🔊 Aural learners - Present: no audio version. - Improve: this is a natural 3-minute podcast segment; the thesis is one sentence and the asks are two. #### 🗣️ Verbal learners - Present: strong. "Just enough HTML" and "impossible to hide the crud" are memorable compressions. - Improve: define "crud" once — it is doing a lot of work undefined. #### 🧩 Kinesthetic learners - Present: nothing to try. - Improve: a Playground link where a reader can publish a Markdown post in 30 seconds would convert readers into testers. #### 🧠 Logical learners - Present: the argument chain is clear, but unsupported at the Microsoft step. - Improve: one link per empirical claim; a short table of what Lite would and would not include. #### 🧑‍🤝‍🧑 Social learners - Present: strong — it ends by asking readers what they think, on a social platform. - Improve: name the specific people at Bluesky and WordPress who would have to weigh in. #### 🧘‍♀️ Solitary learners - Present: short enough to read and think about in one sitting. - Improve: a reflection prompt — audit your own site's plain-text output before agreeing or disagreeing. #### 🌿 Naturalistic learners - Present: the "grain of the web" phrasing is an organic-systems metaphor. - Improve: connect plain-text formats to storage and transfer efficiency, which is a real sustainability angle. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: plain paragraphs with one subheading in the thread body; reads cleanly. - Improve: the platform, not the author, controls landmark structure here. WCAG 2.2 AA 1.3.1 Info and Relationships. #### Keyboard navigation - Present: platform-controlled; X's thread reader is keyboard reachable. - Improve: not the author's surface. 2.1.1 Keyboard. #### Contrast and readability - Present: platform default theme meets 4.5:1 in both light and dark modes. - Improve: not author-controlled. 1.4.3 Contrast (Minimum). #### Text resizing and reflow - Present: text-only content reflows without loss. 1.4.10 Reflow. - Improve: none needed. #### Media and captions - Present: no media, so no caption obligation. Not applicable to this source. - Improve: if a diagram is added later, alt text must carry the comparison, not just name it. 1.1.1 Non-text Content. #### Forms and interactions - Present: none in the content. Not applicable to this source. - Improve: n/a. 3.3.2 Labels or Instructions applies to the platform's reply box, not the post. #### Standards reference - The post itself raises an unstated accessibility argument: Markdown enforces a predictable heading hierarchy, which supports 1.3.1 and 2.4.6 (Headings and Labels) better than freeform rich-text editors typically do. ### 🌍 DEIB Assessment #### Cultural breadth - Present: limited. The frame is US tech-industry history — 2006 Twitter, Microsoft, Silicon Valley startups. - Improve: Markdown's low tooling requirements matter most on low-bandwidth and low-spec devices; that global case is unmade here. #### Inclusive language - Present: neutral throughout; no gendered or exclusionary phrasing. - Improve: "crud" and "just enough HTML" are insider shorthand that a newcomer cannot decode. #### Neurodiversity support - Present: short paragraphs, one idea each, consistent structure — genuinely easy to follow. - Improve: the single subheading ("For Bluesky and WordPress") helps; two more would help more. #### Representation - Present: no people are quoted or named besides the author and two companies. - Improve: the people who would build this — Bluesky protocol engineers, WordPress core committers — are talked about, not to. #### Psychological safety - Present: respectful, invitational close ("Let me know what you think"). No hostility toward either platform. - Improve: none needed; the tone models how to make a demanding ask without contempt. ### ✅ Logical Validity #### Strong reasoning - **Analogical, paragraph 2.** "Everything in Markdown, it's just enough HTML" — a sufficiency argument by analogy to HTML's own early minimalism. Strong because it is falsifiable in practice: either Markdown covers the constructs authors actually use, or it does not. - **Causal, paragraphs 1–2.** AI tooling adopted Markdown → plain-text publishing gains ground. The mechanism is plausible and observable, though the post asserts rather than demonstrates the second link. - **Pragmatic, paragraph 4.** Offering an experimental system as the path for Bluesky is genuinely strong reasoning: it lowers the cost of being wrong, which is the correct move for an unproven UX change. #### Fallacies - **Unsupported assertion / appeal to unnamed authority** — paragraph 2: "Microsoft has created a white flag, here's all your data dear users, in Markdown." No product, date, or link. Verified absent: the thread contains zero `<a>` elements. *Fix:* name the feature and link the announcement, or downgrade the claim to "Microsoft appears to be moving this direction." - **Hasty generalization** — paragraph 1: "People love Markdown because it's impossible to hide the crud." A single asserted cause for a broad preference, with no evidence that this is the reason people cite. *Fix:* cite adoption data, or state it as the author's own reason. - **False dilemma** — paragraph 5, the Lite/Pro split. It presents Markdown-only and full WordPress as the two options, when the actual space includes a Markdown *mode*, an import/export path, or a headless endpoint — none of which require a product tier. *Fix:* argue for the capability and let packaging follow. - **Appeal to novelty / chronological snobbery** — paragraph 4: the 2006 constraint is "an anachronism" because it is old. Age is not itself an argument; the post partly concedes this ("we could argue as to whether that was a good thing") without resolving it. *Fix:* argue from the constraint's current costs. #### Tone of voice - Advocacy in a personal register, hedged and invitational: "imho," "I'd love to see," "Let me know what you think!" The double question mark at the close signals a discussion prompt rather than a manifesto. Confident about direction, explicitly uncertain about mechanism — an honest posture for a proposal with no implementation attached. ### 🛡️ DARVO Analysis - **Deny:** none present. The post makes no accusation and defends against none. - **Attack:** none. The nearest thing is calling a design constraint "an anachronism," which criticizes a decision rather than the people who made it, and is immediately softened by conceding it may have been right in 2006. - **Reverse victim/offender:** none. No party is cast as victim or offender anywhere in the thread. - **Emotional cues and rhetoric:** the "white flag" metaphor is the only adversarial framing, and it casts Microsoft as conceding rather than as an aggressor. Not applicable to this source as a DARVO pattern — the genre is a product proposal, not a defense against criticism. ## 🎯 Conclusion - **Bottom line.** The packaging proposal (WordPress Lite/Pro, Markdown-native Bluesky) is the least durable part of the post. The framing flip is the durable part: build so your content is useful *to* AI systems rather than bolting AI *into* your product. That reframing survives rejecting both product asks. - **Next steps for readers.** Audit what your site emits in plain, machine-readable form today — feeds, semantic HTML, REST shape, a Markdown representation. Run the block-editor round-trip test on your own posts before forming an opinion about a Markdown-only tier. And treat the Microsoft claim as unverified until someone links the release note. ## 🔄 Refactor Appendix — People love Markdown because it's impossible to hide the crud ### 📚 Literature Atoms (H3) #### [H1] Markdown's legibility prevents hidden markup bloat > [!quote] > People love Markdown because it's impossible to hide the crud. **Context & use**: - Opening line of the thread; the thesis the rest hangs from. - The claim is about inspectability, not simplicity — a format whose source is its presentation cannot carry invisible payload. Useful as the general principle behind format choices well beyond Markdown. **Tags**: #xref #aphorisms <!-- atomicity: 1 idea ✓ --> #### [H2] Markdown is sufficient HTML, not reduced HTML > [!quote] > Everything in Markdown, it's just enough HTML. **Context & use**: - Paragraph 2; Winer notes he has argued this for years. - Reframes Markdown as a sufficiency argument rather than a compromise. This is the line to reach for when someone treats Markdown as a lesser format. **Tags**: #xref #aphorisms <!-- atomicity: 1 idea ✓ --> #### [H3] Build products AI can read, not products containing AI > [!quote] > the new approach makes WordPress more useful to AI apps. Big difference in perspective. **Context & use**: - Paragraph 5, the WordPress ask; the most portable idea in the post. - Directly relevant to courtneyr.dev, Outpost, and post-kinds: the question stops being "where does AI go in this plugin" and becomes "what does this plugin emit that a machine can use." **Tags**: #xref #articleseed <!-- atomicity: 1 idea ✓ --> #### [H4] Ship risky UX changes as experiments, not as replacements > [!quote] > If it's hard to do in the present system, start an experimental system and let the users drive the process **Context & use**: - Paragraph 4, the Bluesky ask. - The generalizable governance move: when a change is contested and unproven, lower the cost of being wrong instead of arguing harder for it. **Tags**: #xref <!-- atomicity: 1 idea ✓ --> ### 🧠 Permanent Candidates (H4) #### [P1] Machine-readable output beats embedded AI features **Claim** (one sentence, Courtney's voice): A product earns more from emitting content that machines can consume cleanly than from embedding AI features inside itself. **Evidence pointer**: [[#H3]] **Scope & conditions**: Holds where the product's value is its content and where consumption happens elsewhere — publishing, docs, CMS. Weakens where the AI feature *is* the product surface, or where content is private and never leaves the app. **Links**: - [[Open Web Publishing]] — because extends - [[AI Feature Bolt-Ons]] — because contrasts on where the intelligence lives - [[courtneyr.dev Content Strategy]] — because applies-in my own publishing stack <!-- atomicity: 1 idea ✓ --> #### [P2] A format that cannot hide its own bloat stays honest **Claim** (one sentence, Courtney's voice): Formats whose source is their presentation resist accumulating invisible complexity, because every addition is visible to the person editing. **Evidence pointer**: [[#H1]] **Scope & conditions**: Holds for authoring formats read and written by humans. Does not hold for compiled or binary interchange formats, where opacity is the point and tooling is the inspection layer. **Links**: - [[Plain Text Durability]] — because extends - [[Block Markup in post_content]] — because contrasts on inspectability <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Run the block-editor → Markdown → block-editor round trip on 20 of my own posts and record what breaks. This is the empirical question nobody in the thread answers. #fleeting #inbox - [F2] Check what Microsoft actually shipped that prompted the "white flag" line — the post gives no link and the thread has zero hyperlinks. #fleeting #inbox - [F3] Article seed: "Make WordPress useful to AI, not full of AI" — the framing flip applied to post-kinds, Outpost, and feed output. #articleseed - [F4] Does post-kinds already emit a clean machine-readable representation, or only rendered HTML? Audit before writing the article. #fleeting #inbox ### → Things 3 (max 2 actions) - [ ] Run the Markdown round-trip test on 20 courtneyr.dev posts and log what formatting is lost — courtneyr.dev content audit #things - [ ] Draft the "useful to AI, not full of AI" post using post-kinds output as the worked example — writing queue #things <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Tweets/People Love Markdown Because It's Impossible to Hide the Crud.md|People Love Markdown Because It's Impossible to Hide the Crud by Dave Winer]] ## Highlights - People love Markdown because it's impossible to hide the crud. And because people love it so much it's become a favorite of tech startups esp in the AI field. This is a great turn of events. We're getting back to the web, and the sooner everyone gets on board, imho, the better. ([View Highlight](https://read.readwise.io/read/01m21cm3kymwpfcd14jzvdqhv0)) - Note: Thesis. The claim is about inspectability, not simplicity: a format whose source is its presentation cannot carry invisible payload. Asserted, not evidenced — no adoption data offered. - Tags: open-web, markdown, atom/literature/h1 - I've written about this for a few years. Everything in Markdown, it's just enough HTML. And with that, Microsoft has created a white flag, here's all your data dear users, in Markdown, to use as you please. Instead of waiting for Claude et al to start reading Word files. ([View Highlight](https://read.readwise.io/read/01m21cm6j4hrew88974ezfvjzn)) - Note: "Just enough HTML" is the sufficiency argument — Markdown as adequate, not lesser. But the Microsoft "white flag" claim names no product, no date, no link. Verified: this thread contains zero hyperlinks, so it is genuinely uncited rather than stripped by text extraction. - Tags: fallacy/unsupported-assertion, markdown, atom/literature/h2 - For WordPress, I'd love to see a *Lite* product that only uses Markdown. The current product would become WordPress Pro. Make it super easy for someone to start out fresh with WP, they can upgrade to Pro later, if they want. Bring the barrier to entry down, and at the same time make it more useful for AI applications. WordPress, like many other products has been trying to make AI useful inside WordPress, the new approach makes WordPress more useful to AI apps. Big difference in perspective. And i think the new approach follows the grain of the web circa 2026. ([View Highlight](https://read.readwise.io/read/01m21cmbx7qer6xdnvrt3ebstc)) - Note: The portable idea: build so machines can read your output rather than embedding AI in the product. The Lite/Pro packaging is a false dilemma — a Markdown mode, export path, or headless endpoint all get the same result without a product tier, and no migration cost for block markup in post_content is acknowledged. - Tags: atom/literature/h3, articleseed, wordpress