One Block, Every Possibility.  🔗 **Source:** [One Block, Every Possibility.](https://unblockwp.com/features/) > [!note]+ Document Notes > tags: [wordpress, block-development, gutenberg, html-output, web-performance, clean-markup] > author: [MISSING] > source: UnblockWP (unblockwp.com) > reference: https://unblockwp.com/features/ > date created: 2026-06-29 09:00 > > # 🏷️ Title: Features — UnblockWP > <!-- 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 - [UnblockWP Features](https://unblockwp.com/features/) — the source page. - [Timber](https://timber.github.io/docs/) — Twig templating for WordPress, the data-layer inspiration. - [Twig](https://twig.symfony.com/) — the templating language UnblockWP binds with. - [WordPress AI connectors / Abilities API](https://make.wordpress.org/core/) — the BYO-key channel the AI assistant rides on. ## 📝 Summary - **What it is.** UnblockWP is a developer-oriented WordPress block tool. Its pitch: every block renders one clean HTML element with full control over markup, styles, scripts, and data — explicitly positioned against the nested `<div>` soup that core/page-builder blocks emit. - **Why it matters.** Block "bloat" (wrapper divs, inline style attributes, duplicated CSS) is a real and recurring DevRel/Core-Performance complaint. A product that markets clean output as the headline feature is a signal about market pain, not just a feature list. - **Key stakeholders.** Block developers and freelancers who hand-build markup; agencies chasing Core Web Vitals; theme authors; WP Core Performance team; and the broader Gutenberg-vs-classic-control debate. - **Risks and tradeoffs.** It's a marketing page — claims are unbenchmarked. A Twig/Timber data layer plus HTML/CSS/JS editing plus an AI assistant is a large surface area; "no proprietary AI" is good, but BYO-key shifts cost and governance to the user. Lock-in risk if blocks store Twig in a non-portable format. - **Bottom line.** The positioning is coherent and addresses a genuine gap (clean, controllable output without writing custom blocks). Worth a hands-on perf comparison before recommending; treat performance and accessibility claims as untested until measured. ## 📖 Main Content - **The core promise is markup control.** The page leads with the claim that each block renders a single clean HTML element and "nothing is abstracted away." For a WordPress audience this is a direct shot at the layered wrapper markup that core blocks and most page builders produce. The value proposition is: get builder-speed authoring without sacrificing the hand-coded output a developer would write. - **Visual panel + CSS inspector, kept in sync.** It pairs a visual controls panel (layout, typography, effects) with a CSS inspector that edits selectors directly, both updating in real time. The framing — "design visually and learn CSS along the way" — targets the gap between no-code builders and hand-coding, and doubles as an education claim. - **Responsive and at-rule handling.** Manages breakpoints, container queries, and any CSS at-rule (`@media`, `@container`, `@supports`), scoped and reusable. Default breakpoints match WordPress, with custom breakpoints and in-editor device preview. This is more standards-aligned than typical builder breakpoint systems. - **Data layer via Twig/Timber.** A "Timber-inspired data layer using Twig" binds any block to posts, users, terms, custom fields, or WooCommerce products. It claims 50+ formatting filters, full query support with pagination, and zero-config integration with ACF, Meta Box, JetEngine, and Pods. Relational fields resolve to "chainable providers" with dot-notation access. Twig is a mature, well-documented language, so the "AI already knows Twig" claim is plausible. - **AI assistant ("Unbot").** Three specialized agents (structure, design, writing) and eight skills (images, animations, forms, responsive, data binding, accessibility audits). Crucially: no proprietary AI — it routes through WordPress AI connectors with the user's own API key (OpenAI, Anthropic, Google). That's an architecturally responsible choice and aligns with where Core AI is heading. - **Code editing in the editor.** Edit HTML, CSS, JS with syntax highlighting, autocomplete, and live preview; choose the HTML element, add attributes, attach event handlers — all synced with the visual UI. The element set is explicit: section, container, div, heading, paragraph, text, anchor, image, iframe, SVG, loop, condition, variable. - **Query/Loop block.** Five query types (posts, terms, users, static items, main query), full pagination, nested loops, named queries, data aliases, empty-state handling. Queries can be configured from the sidebar or written as Twig in the HTML inspector. - **Performance claims.** "One CSS file per page with only the styles it uses," small files inlined in the head, lazy expression evaluation, and "no unnecessary database queries." These are the load-bearing performance assertions — and the ones most in need of independent verification. - **Contested/uncertain.** Every claim is vendor-stated. No benchmarks, no demo metrics, no accessibility conformance data despite shipping an "accessibility audits" skill. "Each renders one clean HTML element" is repeated as a guarantee but a features page can't prove the rendered DOM stays clean across nesting, loops, and conditions. ### 🗒️ Notes - Headline framing is **anti-abstraction**: control over markup/styles/scripts/data is the spine the whole page hangs on. - The **education angle** ("learn CSS along the way") is a DevRel-relevant wedge — it reframes a dev tool as an on-ramp. - **Twig choice is strategic**: mature language → AI models already trained on it → assistant can author expressions. This sidesteps the cold-start problem of a proprietary expression syntax. - **BYO-key AI** is the standout governance decision. Avoids vendor AI lock-in and aligns with WordPress AI connector direction; cost and rate limits move to the user. - **Element vocabulary is finite and HTML-semantic** (section, heading, paragraph, anchor, image, iframe, SVG) plus control primitives (loop, condition, variable). This is closer to a templating language exposed as blocks than a classic block library. - **Perf story** is per-page critical CSS + inlining + lazy eval + query frugality — textbook Core Web Vitals levers, asserted not demonstrated. - **WooCommerce data provider** (pricing, stock, gallery, reviews, cart, SKU, sale detection, currency formatting) signals a commerce-template ambition beyond simple content sites. ## 📚 References - [UnblockWP — Features](https://unblockwp.com/features/) - [Timber Documentation](https://timber.github.io/docs/) - [Twig — The flexible, fast templating engine](https://twig.symfony.com/) - [WordPress Core Performance Team](https://make.wordpress.org/performance/) - [ACF](https://www.advancedcustomfields.com/), [Meta Box](https://metabox.io/), [JetEngine](https://crocoblock.com/plugins/jetengine/), [Pods](https://pods.io/) — the named field frameworks. ## 🗣️ Paraphrase - UnblockWP sells one idea hard: blocks that emit exactly the HTML you'd hand-write, with no hidden wrappers, and a visual panel sitting in lockstep with a real CSS inspector so you can edit selectors directly. - Under that sits a Twig-based data layer (Timber-style) that wires content — posts, fields, WooCommerce products — into any block, plus a BYO-key AI assistant that writes the Twig and audits accessibility, and a performance story built on per-page critical CSS and lazy evaluation. ## 📰 Newsletter Tired of cracking open a "simple" paragraph block and finding three nested `<div>`s wearing trench coats? UnblockWP is pitching the cure: every block renders one clean HTML element, and "nothing is abstracted away." It pairs a visual panel with a live CSS inspector (design now, learn CSS by osmosis), speaks fluent `@container` and `@supports`, and wires content through a Timber-flavored Twig data layer — so your ACF, Meta Box, Pods, and WooCommerce fields drop in without ceremony. The AI assistant is refreshingly un-proprietary: it rides WordPress AI connectors with your own OpenAI/Anthropic/Google key. The headline-grabber for the Core Web Vitals crowd: one CSS file per page with only the styles it uses, small ones inlined in the head. Caveat emptor — this is a features page, not a benchmark. Lovely claims; bring your own Lighthouse run before you believe the perf numbers. ## ✅ Action Items #### DevRel - Developer advocacy: build a side-by-side "core blocks vs UnblockWP" rendered-DOM demo; measure wrapper count and CSS payload. - Education: a workshop on clean block output and container queries that's tool-agnostic, using UnblockWP as one worked example. - Developer experience: capture the "visual panel ↔ CSS inspector sync" UX as a pattern worth documenting in core block tooling. - Developer marketing: a teardown post on Twig-as-block-expression-language for the WP dev audience. - Community management: solicit real perf numbers from users to counter unbenchmarked vendor claims. - Internal/external/cross-project: feed clean-markup demand signal to the Gutenberg and Themes teams. #### OSPO - Policy & Governance: note BYO-key AI as a reference pattern for responsible AI integration in OSS plugins. - License Compliance: verify UnblockWP's license and whether stored Twig/markup is portable (export/lock-in check). - Security Management: review the implications of in-editor JS/event-handler editing for capability gating and stored XSS. - Software Inventory: track Timber/Twig dependency surface if evaluated for production. - Developer Support: draft guidance on safe use of arbitrary HTML/JS blocks for client sites. - Community Engagement: connect with Timber maintainers on the "Timber-inspired" framing. - Strategic Alignment: map clean-output tooling against Core Performance OKRs. #### Community - Maintainers: discuss whether core can adopt opt-in "lean markup" modes for blocks. - Contributors: a "first issue" rotation cataloguing wrapper-div reduction opportunities in core blocks. - Sponsors: none indicated. - Ecosystem: coordinate a shared block-output benchmark suite so claims like UnblockWP's become testable. #### WordPress - Core: track demand for finer markup control; evaluate whether block supports can reduce wrapper nesting. - Core Performance: build a reproducible test of "one CSS file per page, only used styles" against core's stylesheet strategy. - Core AI: study the BYO-key connector approach as a model; check alignment with the Abilities API direction. - **Core Program Team:** flag clean-markup as a cross-team theme (Core + Performance + Themes). - Mobile: N/A — no mobile-app surface in source. - Playground: build a Playground demo reproducing the rendered DOM for verification. - Community: meetup demo kit on container queries and lean block output. - Training: a Learn lesson on Twig/Timber data binding concepts (tool-neutral). - Marketing: N/A. - Support: anticipate questions about arbitrary HTML/JS block safety. - Design: study the visual-panel/CSS-inspector sync as a design pattern. - Documentation: examples-first patterns for container queries and `@supports` in block CSS. - Photos: N/A. - TV: N/A. - Polyglots: N/A. - Accessibility: independently test the "accessibility audits" skill output against WCAG 2.2 AA; vendor self-audit ≠ conformance. - Meta: N/A. - CLI: N/A. - Hosting: note per-page CSS inlining interaction with full-page caching. - Tide: a clean-output / wrapper-count metric could be a Tide scoring candidate. - Openverse: N/A. - Themes: evaluate clean-markup tooling against theme-author needs; revisit theme.json's role. - Plugins: security review of stored HTML/JS/event-handler features before any endorsement. #### The WPCC - Programs: N/A. - Projects: a community-run block-output benchmark project. - Funding experiments: N/A. ### FAIR - Technical independence: BYO-key AI is a small win for independence — no forced vendor AI dependency. - Policies and covenants: N/A for a single product page. - Productized governance artifacts: N/A. ## 🧪 Hypotheses - H1: UnblockWP-built pages emit measurably fewer DOM nodes and less wrapper nesting than equivalent core-block pages. - H2: The per-page "only used styles" CSS strategy reduces total CSS bytes versus core's enqueued block stylesheets on a typical content page. - H3: Inlining small per-page CSS in the head improves LCP on cold loads but can hurt repeat-view caching versus a shared cached stylesheet. - H4: A Twig/Timber data layer lowers time-to-first-template for developers already fluent in Timber, but raises the learning curve for pure visual users. - H5: Exposing arbitrary HTML/JS/event-handler editing increases stored-XSS surface unless gated to high-capability users. ## 📊 Methodology - This source is a product/marketing features page, not a study — so formal methodology is **N/A as authored**. Treated here as product-claims analysis. - To test H1–H2: build the same layout in core blocks and in UnblockWP; compare rendered DOM node counts, wrapper depth, and total CSS/JS bytes via DevTools and Lighthouse. - To test H3: WebPageTest cold vs warm runs, comparing inlined per-page CSS against a shared cached stylesheet; measure LCP, CLS, and repeat-view transfer size. - To test H4: time-on-task usability study, Timber-fluent vs visual-only cohorts. - To test H5: security review and a deliberate stored-XSS attempt across capability levels. ## ❓ Questions - How is the Twig stored per block, and is the markup portable if the plugin is deactivated (graceful degradation or broken shortcode-style residue)? - Does "one clean HTML element" hold through nested loops and conditions, or do control primitives reintroduce wrappers? - What capability checks gate the HTML/JS/event-handler editor? - How does per-page inlined CSS interact with full-page caching and CDNs? - Is the "accessibility audits" skill validated against WCAG 2.2 AA, or is it heuristic LLM output? ## 🔮 Future Research - A community benchmark suite for block-output cleanliness (node count, wrapper depth, CSS bytes) usable across builders and core. - Investigate whether core Gutenberg could offer an opt-in lean-markup mode informed by tools like this. - Study BYO-key AI connector patterns as a governance template for AI features in the plugin ecosystem. ## 💡 Implications - **Practice:** Validates developer demand for markup control inside the block editor; agencies chasing Core Web Vitals are an obvious audience. - **Policy:** BYO-key AI is a quietly important precedent — responsible AI integration without bundling a vendor. - **Security:** Arbitrary HTML/JS/event handlers in the editor demand strict capability gating and review; a real consideration for any plugin endorsement. - **Education:** The "learn CSS along the way" framing is a teaching opportunity DevRel can borrow regardless of the product. - **Funding models:** N/A from this source. ### 🧠 Learning Styles Assessment - Reading level estimate: Flesch-Kincaid Grade ~10–12 (dense, jargon-heavy marketing prose: "chainable providers," "lazy expression evaluation," "container queries"). Flesch Reading Ease likely ~40–50 (fairly difficult). Assumes a technical reader. #### 👀 Visual learners - Present: implied product screenshots (CSS panel, Unbot chat, HTML/CSS inspector, Loop block grid) referenced in the source. - Improve: annotated before/after DOM diagrams; labeled architecture diagram of the data layer. #### 🔊 Aural learners - Present: none. - Improve: a 2–5 minute audio walkthrough of the feature set; narrated demo. #### 🗣️ Verbal learners - Present: feature names and short definitions; the Twig/Timber analogy. - Improve: a glossary (container query, at-rule, provider, named query, data alias) with plain-language examples. #### 🧩 Kinesthetic learners - Present: "See it in action or start building" CTA implies a sandbox. - Improve: a guided Playground lab reproducing one clean-output page step by step. #### 🧠 Logical learners - Present: enumerated feature lists, element vocabulary, five query types. - Improve: a decision tree for "when to reach for Twig vs the sidebar"; a comparison table vs core blocks. #### 🧑‍🤝‍🧑 Social learners - Present: none evident. - Improve: community forum, showcase of community-built templates, peer review of clean-output patterns. #### 🧘‍♀️ Solitary learners - Present: self-serve "start building" path. - Improve: self-paced tutorial track with self-check checkpoints. #### 🌿 Naturalistic learners - Present: none. - Improve: tie the lean-CSS/lazy-eval story to a sustainability/energy-efficiency narrative (lighter pages, less compute). ### 📊 Accessibility Assessment #### Screen reader semantics - Present: the tool exposes semantic HTML elements (section, heading, paragraph, anchor) and the user chooses the element — a structural plus. - Improve: element choice doesn't guarantee correct heading order or landmark use; the product should nudge valid structure. (WCAG 1.3.1) #### Keyboard navigation - Present: not addressed in source. - Improve: editor and rendered output must be fully keyboard operable; verify no traps in the CSS inspector/Unbot UI. (WCAG 2.1.1, 2.1.2) #### Contrast and readability - Present: not addressed. - Improve: the visual panel's color/gradient picker should warn on sub-4.5:1 text contrast. (WCAG 1.4.3) #### Text resizing and reflow - Present: container queries and responsive breakpoints support reflow in principle. - Improve: verify rendered output reflows at 200% zoom / 320 CSS px without clipping. (WCAG 1.4.4, 1.4.10) #### Media and captions - Present: iframe/SVG/image elements supported; no caption tooling mentioned. - Improve: prompt for alt text on image blocks; accessible names for SVG/iframe. (WCAG 1.1.1) #### Forms and interactions - Present: a "forms" skill is listed. - Improve: ensure generated forms have labels, error handling, and adequate target size. (WCAG 1.3.1, 3.3.1, 2.5.8) #### Standards reference - Net: the product ships an "accessibility audits" skill but provides no conformance evidence. Map all of the above to **WCAG 2.2 AA**; treat the audit skill as a heuristic aid, not a conformance claim. ### 🌍 DEIB Assessment #### Cultural breadth - Present: none — single-language English marketing page. - Improve: localized docs; multi-region examples. #### Inclusive language - Present: neutral, product-focused language; no obvious exclusionary terms. - Improve: define jargon for non-native English readers; plain-language summary. #### Neurodiversity support - Present: chunked feature sections with consistent structure. - Improve: more frequent headings, icon+text labels, predictable layout in the editor. #### Representation - Present: N/A — no people depicted in the text. - Improve: inclusive imagery in screenshots/demos. #### Psychological safety - Present: low-stakes marketing context; respectful framing. - Improve: clear, non-blaming docs and a moderated community channel. ### ✅ Logical Validity #### Strong reasoning - **Analogical (strong):** "Timber-inspired data layer using Twig, a proven templating language" — anchors a new feature to a known, trusted tool, and the follow-on ("every major AI model already knows Twig") is a plausible causal claim that strengthens the assistant feature. - **Causal (moderate):** "One CSS file per page with only the styles it uses" → smaller payloads → better performance. The mechanism is sound and matches Core Web Vitals practice; only the magnitude is unproven. - **Deductive framing:** "Each block renders a single clean HTML element" is presented as a guarantee from which the control claims follow — valid *if* the premise holds in rendered output. #### Fallacies - **Unsupported assertion / appeal to (implied) authority:** Performance and cleanliness claims ("no unnecessary database queries," "only the styles it uses") are stated without benchmarks. Fix: publish reproducible metrics. - **Glittering generalities:** "Nothing is abstracted away," "No limits," "Describe it, it builds it." Persuasive, unfalsifiable as written. Fix: scope the claims with concrete boundaries and examples. - **Hasty generalization risk:** "every major AI model already knows Twig" — broadly plausible but absolute. Fix: soften to "widely supported." - Note: these are normal marketing-copy patterns, not deception; flagged for fair calibration, not as bad faith. #### Tone of voice - Confident, terse, developer-to-developer ("Describe it, it builds it," "Query anything, loop through it"). Imperative, benefit-forward, lightly aspirational. Credible to a technical reader but light on evidence. ### 🛡️ DARVO Analysis - N/A. This is a product features page with no accuser, no defense, and no conflict. No denial, attack, or victim/offender reversal is present. DARVO does not apply. ## 🎯 Conclusion - **Bottom line.** UnblockWP markets a coherent, genuinely-wanted thing: builder-speed authoring that emits hand-coded-quality HTML, backed by a Twig/Timber data layer, a BYO-key AI assistant, and a Core Web Vitals-friendly CSS strategy. The positioning lands because block bloat is a real pain point in the WordPress ecosystem. - **Caveats.** Everything is vendor-stated. The clean-output, performance, and accessibility claims are exactly the ones a DevRel/Core-Performance reviewer should verify hands-on before endorsing. - **Next steps for readers.** Build the same page in core blocks and in UnblockWP; diff the rendered DOM, CSS bytes, and Lighthouse scores. Review the HTML/JS editing feature for capability gating and XSS surface. Test the accessibility-audit skill against WCAG 2.2 AA rather than trusting the label. ## 🔄 Refactor Appendix — Features — UnblockWP > Density: 2–5 Literature atoms (H3), 0–3 Permanent candidates (H4). > Defaults: 3 Literature, 1 Permanent. Resonance filter: if you can't > articulate in one line why a claim matters, drop it. ### 📚 Literature Atoms (H3) #### [H1] Blocks can render one clean HTML element > [!quote] ID:rw_unblockwp_01 > Each block renders a single clean HTML element. You control the markup, the styles, the scripts, and the data. Nothing is abstracted away. **Context & use**: - Opening line of the features page — the product's spine. - Names the core WordPress pain (wrapper-div bloat) and the value prop in one breath. **Tags**: #xref #articleseed <!-- atomicity: 1 idea ✓ --> #### [H2] Visual panel and CSS inspector stay in sync > [!quote] ID:rw_unblockwp_02 > A full visual panel for layout, typography, effects and more. Plus a CSS inspector to edit every selector directly in code. **Context & use**: - Bridges no-code and hand-code; doubles as a "learn CSS" education claim. - Pattern worth documenting for core block tooling. **Tags**: #xref <!-- atomicity: 1 idea ✓ --> #### [H3] Twig data layer borrows Timber's proven model > [!quote] ID:rw_unblockwp_03 > A Timber-inspired data layer using Twig, a proven templating language for WordPress. **Context & use**: - Anchors a new expression system to a trusted, AI-familiar language. - Explains why the assistant can author expressions reliably. **Tags**: #xref <!-- atomicity: 1 idea ✓ --> #### [H4] AI assistant is BYO-key, not proprietary > [!quote] ID:rw_unblockwp_04 > No proprietary AI system. Unblock connects through WordPress AI connectors with your own API key, currently supporting OpenAI, Anthropic, and Google. **Context & use**: - A responsible-AI governance precedent for plugin authors. - Aligns with WordPress AI connector / Abilities direction. **Tags**: #xref #addendum <!-- atomicity: 1 idea ✓ --> #### [H5] Per-page critical CSS is the performance lever > [!quote] ID:rw_unblockwp_05 > One CSS file per page with only the styles it uses. Small files are inlined in the head. **Context & use**: - The load-bearing, most-testable performance claim. - Core Web Vitals reviewers should benchmark this against core's stylesheet strategy. **Tags**: #xref #articleseed <!-- atomicity: 1 idea ✓ --> ### 🧠 Permanent Candidates (H4) #### [P1] Clean block output is a marketable product category **Claim** (one sentence, Courtney's voice): Demand for hand-coded-quality HTML from the block editor is strong enough to anchor a product's entire pitch. **Evidence pointer**: [[#H1]] **Scope & conditions**: Holds while core blocks and page builders emit nested wrapper markup; weakens if core ships a first-party lean-markup mode. **Links**: - [[Block bloat and Core Web Vitals]] — because extends - [[Gutenberg vs hand-coded control]] — because contrasts on authoring model - [[Core Performance team priorities]] — because applies-in WP performance work <!-- atomicity: 1 idea ✓ --> #### [P2] BYO-key connectors are a responsible-AI pattern for plugins **Claim** (one sentence, Courtney's voice): Routing AI features through WordPress connectors with the user's own key avoids vendor lock-in and pushes cost and governance to the site owner. **Evidence pointer**: [[#H4]] **Scope & conditions**: Holds when the WP AI connector/Abilities layer is available; breaks for users without an API key or where a turnkey experience is required. **Links**: - [[WordPress Abilities API]] — because applies-in core AI direction - [[FAIR technical independence]] — because evidence-for <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Build a rendered-DOM diff: core blocks vs UnblockWP, same layout — node count + CSS bytes — https://unblockwp.com/features/ #fleeting #inbox - [F2] Does deactivating the plugin leave portable markup or broken residue? Verify export/lock-in. #fleeting #inbox ### → Things 3 (max 2 actions) - [ ] Benchmark "one CSS file per page" claim against core stylesheet strategy with Lighthouse — DevRel/Core Performance #things - [ ] Security-review the in-editor HTML/JS/event-handler feature for capability gating + stored XSS — OSPO/Plugins #things <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/One Block, Every Possibility..md|One Block, Every Possibility. by unblockwp.com]] ## Highlights - Each block renders a single clean HTML element. You control the markup, the styles, the scripts, and the data. Nothing is abstracted away. ([View Highlight](https://read.readwise.io/read/01kw9qp6qg3261kq29d4x1qhk4)) - Note: Core positioning: one clean HTML element per block, full control of markup/styles/scripts/data — the anti-block-bloat pitch. - Tags: clean-markup, atom/literature/h1, block-development - A full visual panel for layout, typography, effects and more. Plus a CSS inspector to edit every selector directly in code. Both stay in sync in real time, so you can design visually and learn CSS along the way. Manage responsive breakpoints, container queries, and any CSS at-rule, all scoped and reusable across your site. ([View Highlight](https://read.readwise.io/read/01kw9qphj7f63fwmh8hshtjgez)) - Note: Visual panel + live-synced CSS inspector (breakpoints, container queries, at-rules) — design-visually-learn-CSS bridge. - Tags: atom/literature/h3, clean-markup, gutenberg - A Timber-inspired data layer using Twig, a proven templating language for WordPress. Bind any block to posts, users, terms, custom fields, or WooCommerce products. 50+ filters for formatting, full query support with pagination. And because every major AI model already knows Twig, the assistant writes your expressions for you. ([View Highlight](https://read.readwise.io/read/01kw9qp9tpfysqmr986xxwj5ym)) - Note: Twig/Timber-inspired data layer; pitch leans on "every major AI model already knows Twig" (a hasty generalization flagged in Logical Validity, but the data-binding model is the substance). - Tags: wordpress, atom/literature/h2, block-development - Three specialized agents for structure, design, and writing. Eight skills for images, animations, forms, responsive, data binding, and accessibility audits. No proprietary AI system. Unblock connects through WordPress AI connectors with your own API key, currently supporting OpenAI, Anthropic, and Google. ([View Highlight](https://read.readwise.io/read/01kw9qpcggbckzs7xp0n50n5ct)) - Note: BYO-key architecture: no proprietary AI, routes through WordPress AI connectors — a genuine responsible-AI / FAIR-independence positive. - Tags: atom/literature/h2, wordpress - One CSS file per page with only the styles it uses. Small files are inlined in the head. Lazy expression evaluation, no unnecessary database queries. ([View Highlight](https://read.readwise.io/read/01kw9qpexdhr8qv5z04wwjccn4)) - Note: Performance claims: per-page CSS with only used styles, inlined small files, lazy evaluation — aligns with Core Web Vitals goals (claim, unverified). - Tags: web-performance, atom/literature/h3 ## Links - [[Clean Code Is the Human-AI Interface]] — applies-in: one predictable HTML element per block gives both developers and agents a legible editing surface. - [[Cheap Inspection Collapses the Signal-Substance Gap]] — contrasts: the product's performance and accessibility claims remain marketing until a hands-on benchmark makes checking cheap.