YouTube Video 04YKlSNf89o 🔗 **Source:** [YouTube Video 04YKlSNf89o](https://www.youtube.com/watch?v=04YKlSNf89o) > [!note]+ Document Notes > tags: [web-components, drupal-theming, declarative-shadowdom] > author: John Albin > source: DrupalCon > reference: https://www.youtube.com/watch?v=04YKlSNf89o > date created: 2024-12-20 14:15 > > # 🏷️ Title: Declarative ShadowDOM and the Future of Drupal Theming > <!-- deep-read:sections start --> ## 🧰 Action Inbox - [H1] Experiment with declarative shadowDOM in new projects — newly available August 2024 #web-components - [H2] Create light DOM components using custom elements API — simpler migration path #drupal-theming - [H3] Evaluate web components for SDC integration — real-world examples provided #drupal-development ## 🧭 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 - [John Albin's Presentations](https://john.alwood.net/presentations) - [Can I Use - Web Components](https://caniuse.com/) ## 📝 Summary - John Albin demonstrates how declarative shadowDOM enables server-side rendering of web components in Drupal - Web components offer an alternative to React/JavaScript frameworks using native browser APIs - Three web component APIs: custom elements, templates, and shadow DOM work together for encapsulated components - Declarative shadowDOM became newly available August 5, 2024 across all major browsers - Drupal Single Directory Components (SDC) can integrate web components for modern theming approaches ## 📖 Main Content Web components represent a significant shift toward using native browser APIs instead of JavaScript frameworks like React. The declarative shadowDOM specification, newly available in all browsers as of August 2024, enables server-side rendering of web components without requiring JavaScript. The web components standard consists of three APIs: custom elements (for defining new HTML tags), templates and slots (for reusable markup patterns), and shadow DOM (for style and markup encapsulation). Previously, web components required JavaScript to create shadow DOM, limiting server-side rendering capabilities. Declarative shadowDOM allows developers to define shadow DOM structure directly in HTML using `<template shadowrootmode="open">`, enabling progressive enhancement patterns where components work without JavaScript and enhance with interaction scripts. For Drupal developers, this technology integrates well with Single Directory Components (SDC), allowing creation of encapsulated, reusable components that can be server-rendered and progressively enhanced with JavaScript functionality. ## 🗒️ Notes #### ⏱️ [00:00](https://www.youtube.com/watch?v=04YKlSNf89o?t=0) — [H1] Introduction and Bold Prediction - Key idea: The era of ReactJS is coming to an end due to native browser performance advantages - Evidence: "There is no JavaScript framework that will ever be as fast as the web platform" #### ⏱️ [01:30](https://www.youtube.com/watch?v=04YKlSNf89o?t=90) — [H2] Browser Baseline Feature Availability - Key idea: Web features are categorized as limited, newly available, or widely available - Evidence: "Widely available means that feature was newly available for 2.5 years" #### ⏱️ [02:15](https://www.youtube.com/watch?v=04YKlSNf89o?t=135) — [H1] Declarative ShadowDOM Timeline - Key idea: Declarative shadowDOM became newly available August 5, 2024 - Evidence: "Will become widely available February 5th, 2027" #### ⏱️ [03:00](https://www.youtube.com/watch?v=04YKlSNf89o?t=180) — [H2] Server-Side Rendering Pattern - Key idea: The fastest applications start with server-side rendering - Evidence: "If you wait until it gets loaded into the client before you start rendering some HTML, it's going to be too slow" #### ⏱️ [04:30](https://www.youtube.com/watch?v=04YKlSNf89o?t=270) — [H2] Progressive Enhancement Parallel - Key idea: React's server/client components mirror progressive enhancement principles - Evidence: "Those who have been around a long time - this is progressive enhancement, that's all it is" #### ⏱️ [06:00](https://www.youtube.com/watch?v=04YKlSNf89o?t=360) — [H1] Web Components Three APIs - Key idea: Web components consist of custom elements, templates, and shadow DOM - Evidence: Demonstrates color scheme toggle component with all three APIs #### ⏱️ [08:15](https://www.youtube.com/watch?v=04YKlSNf89o?t=495) — [H2] Custom Elements API Basics - Key idea: Browser treats unknown tags with dashes as custom elements - Evidence: "Any element that has at least one dash in the name, custom elements API guarantees that any official HTML element will never have a dash" #### ⏱️ [11:30](https://www.youtube.com/watch?v=04YKlSNf89o?t=690) — [H2] Connected Callback Lifecycle - Key idea: Browser parses children then calls connectedCallback when element attached to DOM - Evidence: "It parses the children, creates all the children, then finally comes back and calls the connected callback" #### ⏱️ [13:45](https://www.youtube.com/watch?v=04YKlSNf89o?t=825) — [H2] Templates and Slots Introduction - Key idea: Template tag content is not displayed, slots define content insertion points - Evidence: "Browser's default behavior when it sees a template - it's basically like display none" #### ⏱️ [16:00](https://www.youtube.com/watch?v=04YKlSNf89o?t=960) — [H1] Shadow DOM Encapsulation - Key idea: Shadow DOM creates separate, encapsulated DOM for custom elements - Evidence: "It's basically like its own private DOM - prevents styles from main page bleeding to your web component" #### ⏱️ [19:30](https://www.youtube.com/watch?v=04YKlSNf89o?t=1170) — [H1] JavaScript-Free Shadow DOM - Key idea: Declarative shadowDOM works without JavaScript for server-side rendering - Evidence: "There's literally nothing in the JavaScript, but it still renders perfectly, still has a shadow DOM" #### ⏱️ [22:00](https://www.youtube.com/watch?v=04YKlSNf89o?t=1320) — [H2] CSS Communication Patterns - Key idea: CSS custom properties cascade into shadow DOM, enabling styling control - Evidence: "Every single custom property that you create that would apply to the custom element goes into the shadowDOM" #### ⏱️ [25:15](https://www.youtube.com/watch?v=04YKlSNf89o?t=1515) — [H2] Light DOM Components Alternative - Key idea: Using only custom elements API without shadow DOM reduces complexity - Evidence: "Some people just stay here - the encapsulation is too heavy-handed for our uses" #### ⏱️ [27:30](https://www.youtube.com/watch?v=04YKlSNf89o?t=1650) — [H3] Accessibility Challenges - Key idea: Shadow DOM creates accessibility issues with ARIA attributes - Evidence: "If you add ARIA attributes to shadowDOM markup, accessibility tools can't see it" #### ⏱️ [30:00](https://www.youtube.com/watch?v=04YKlSNf89o?t=1800) — [H1] Drupal SDC Integration Example - Key idea: Single Directory Components can integrate web components with variants and properties - Evidence: Demonstrates flip card component with Drupal 11.2 variants feature ## 📚 References - [John Albin's Presentations](https://john.alwood.net/presentations) - [Can I Use - Baseline Features](https://caniuse.com/) - [Drupal Single Directory Components](https://www.drupal.org/docs/develop/theming-drupal/using-single-directory-components) ## 🗣️ Paraphrase - Web components using native browser APIs will eventually replace JavaScript frameworks because native implementations are inherently faster than library abstractions - Declarative shadowDOM enables server-side rendering of web components, solving the previous limitation that required JavaScript for shadow DOM creation - Drupal's Single Directory Components provide an excellent integration path for web components, allowing developers to create encapsulated, reusable components with proper theming integration ## 📰 Newsletter **Web Components Come to Drupal: The Future of Theming is Here** The WordPress community should take note of an exciting development in the Drupal ecosystem. Declarative shadowDOM, now available in all major browsers, is enabling a new approach to component-based theming that doesn't require JavaScript frameworks. John Albin's presentation demonstrates how web components can integrate with Drupal's Single Directory Components, creating encapsulated, reusable UI elements that work with server-side rendering. This approach offers several advantages for WordPress developers to consider: - **Performance**: Native browser APIs are faster than JavaScript framework abstractions - **Progressive Enhancement**: Components work without JavaScript and enhance with interactivity - **Encapsulation**: Shadow DOM prevents style conflicts between components - **Server Rendering**: No client-side JavaScript required for initial render While WordPress doesn't have an exact equivalent to Drupal's SDC system, the principles of web components could influence future WordPress theming approaches, especially as the block editor continues to evolve toward more component-based architectures. Resources: [Learn WordPress](https://learn.wordpress.org/), [Block Editor Handbook](https://developer.wordpress.org/block-editor/), [WordPress Developer Docs](https://developer.wordpress.org/) ## ✅ Action Items #### WordPress - Core: Evaluate web components compatibility with block editor architecture - Themes: Research shadow DOM implications for theme styling and customization - Community: Share knowledge about declarative shadowDOM capabilities with theme developers - Documentation: Create guidance for progressive enhancement patterns in WordPress themes - Design: Consider encapsulation benefits for design system components #### Community - Maintainers: Experiment with web components in experimental themes and plugins - Contributors: Share examples of web components integration patterns - Sponsors: Fund research into modern theming architectures ## 🧪 Hypotheses - Web components will become the preferred method for creating reusable UI components as browser support reaches "widely available" status - Declarative shadowDOM will enable better server-side rendering performance compared to JavaScript framework solutions - WordPress will eventually adopt web components patterns for block editor components - Light DOM components (custom elements only) will be adopted faster due to lower complexity and fewer accessibility issues ### 📊 Methodology - Performance comparison between React components and equivalent web components in real applications - User adoption tracking of web components vs JavaScript frameworks over the next 2-3 years - Analysis of accessibility tool compatibility with shadow DOM implementations ### ❓ Questions - How will WordPress's block editor architecture adapt to leverage web components? - What are the practical implications of shadow DOM's accessibility limitations for production websites? - How can the WordPress community develop component standards that work across different hosting environments? ### 🔮 Future Research - Integration patterns between web components and WordPress's block editor - Performance benchmarks comparing web components to current WordPress theming approaches - Accessibility best practices for web components in content management systems ### 💡 Implications - Practice: WordPress developers should begin experimenting with web components for theme development - Policy: WordPress core team should consider web components in future architectural decisions - Education: Developer training programs need to include web components alongside React/JavaScript frameworks - Funding: Investment in web standards-based solutions may provide better long-term ROI than framework-specific development ### 🧠 Learning Styles Assessment Reading level estimate: Grade 12-14 (technical presentation with code examples) #### 👀 Visual learners - Present: Code screenshots, browser inspector views, component diagrams - Improve: Architecture diagrams showing DOM/shadow DOM relationships, CSS cascade visualizations #### 🔊 Aural learners - Present: Live presentation format with spoken explanations - Improve: Audio summary of key concepts, recorded code walkthroughs #### 🗣️ Verbal learners - Present: Technical terminology definitions, API explanations, analogies to existing concepts - Improve: Glossary of web components terms, comparison tables with familiar technologies #### 🧩 Kinesthetic learners - Present: Live coding demonstrations, working examples - Improve: Step-by-step tutorials, interactive code sandboxes, hands-on workshops #### 🧠 Logical learners - Present: Clear API structure, systematic progression through concepts - Improve: Decision trees for choosing between approaches, performance benchmarks #### 🧑‍🤝‍🧑 Social learners - Present: Conference presentation format, Q&A session - Improve: Discussion forums, peer review of implementations, community examples #### 🧘‍♀️ Solitary learners - Present: Detailed code examples, individual exploration opportunities - Improve: Self-paced learning materials, practice exercises, reference documentation #### 🌿 Naturalistic learners - Present: Evolution from older to newer technologies, natural web standards progression - Improve: Ecosystem impact discussions, sustainability considerations of different approaches ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Standard HTML elements used in examples, semantic structure maintained - Improve: More explicit discussion of ARIA implications, alternative approaches for shadow DOM accessibility #### Keyboard navigation - Present: Interactive components demonstrate keyboard functionality - Improve: Explicit keyboard navigation testing, focus management documentation #### Contrast and readability - Present: Clear code examples, good contrast in slides - Improve: Ensure all code samples meet contrast requirements, larger font sizes for code #### Media and captions - Present: Video presentation available - Improve: Transcript provided here, but official captions would enhance accessibility #### Standards reference - Present: References to web standards and browser support - Improve: Explicit WCAG compliance discussion for web components ### 🌍 DEIB Assessment #### Cultural breadth - Present: Technical content accessible to international developers - Improve: Consider different development environments, hosting constraints in various regions #### Inclusive language - Present: Gender-neutral technical language, professional tone - Improve: Define technical jargon more consistently, avoid assumptions about prior knowledge #### Neurodiversity support - Present: Well-structured presentation with clear headings - Improve: More frequent summary points, consistent formatting patterns #### Representation - Present: Focus on technical merit rather than personal attributes - Improve: Could include diverse examples, use cases from different contexts #### Psychological safety - Present: Respectful technical discussion, acknowledges complexity - Improve: More explicit encouragement for experimentation, learning from failures ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Solid reasoning from browser performance principles to framework conclusions - Inductive strength: Good examples building to general principles about web components - Causal reasoning: Clear cause-effect relationships between browser features and development practices - Analogical strength: Effective analogies between React patterns and web components #### Fallacies - Appeal to novelty: Some emphasis on "new" technology without full consideration of adoption challenges - False dichotomy: Minor oversimplification of framework vs. native choices (both can coexist) #### Tone of voice - Overall tone: Expert technical educator, enthusiastic about web standards, practical focus on implementation ### 🛡️ DARVO Analysis - Deny: No defensive patterns detected - Attack: No attacks on persons or technologies, constructive criticism only - Reverse victim/offender: No victimization narratives present - Emotional cues and rhetoric: Enthusiasm for web standards, but balanced with practical considerations ## 🎯 Conclusion Declarative shadowDOM represents a significant advancement in web components technology, enabling server-side rendering without JavaScript dependencies. For Drupal developers, <!-- deep-read:sections end -->