>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #1804488. --> Reported by: [Snugug](https://www.drupal.org/user/820332) >>> <h3 id="summary-problem-motivation">Problem/Motivation</h3> <p>One of the things to come from <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-5"><a href="https://www.drupal.org/project/drupal/issues/1801582" title="Status: Closed (won't fix)">#1801582: Add a new, non-default framework-based theme to Drupal core</a></span> was the want to implement a system similar to Jacine's proposed <a href="http://jacine.net/post/19652705220/theme-system">Theme Component Library</a> for Drupal 8 Core. While I'm not sure if we're going to have time to implement everything we need, I believe we can start and, if it doesn't make it into D8 Core, we can continue this in Contrib. </p> <h3 id="summary-proposed-resolution">Proposed resolution</h3> <p>I think the steps to start are something as follows:</p> <ul> <li><del>Get feedback from more frontend to see if most of us agree this is the direction we want to go.</del> seems like we agree here?</li> <li><del>Determine how much of this proposal is already covered by other proposals (I believe Twig actually may cover a fair deal of this)</del> Twig can use this issue :)</li> <li><del>Determine if there is enough time to get this complete to an acceptable phase before the D8 feature freeze.</del> LETS GO!</li> </ul> <h3 id="summary-remaining-tasks">Remaining tasks</h3> <ol> <li>Decide on &amp; create item components <ul> <li>menu</li> <li>item_list</li> <li>table</li> </ul> </li> <li>Decide on and create container components <ul> <li>a title and a thingy (block, comment, etc)</li> <li>an administration page</li> </ul> </li> <li>Re-work all existing markup from core to use these components: (This task belongs to TWIG)</li> </ol> <h3 id="original issue">More from the original issue</h3> <p>The following is, what I believe to be, a brief high level overview of what the Component Library needs to do and what it should not do.</p> <p>Jacine sums up what is looking to be accomplished brilliantly in her post (link above):</p> <blockquote><p>Components are usually a combination of containers and formats that make up custom UI elements. Examples of components include Tabs, Vertical Tabs, Form Widgets (like password confirm and machine name), Carousels, Accordions, etc. Components usually have recommended use cases for application. Their implementation can vary from CSS and JavaScript standpoint, but their markup is pretty standard.</p></blockquote> <p>The goal of a Theme Component Library is to provide the markup and let the theme handle the CSS and JavaScript</p> <ul> <li>Provide a set of common markup patterns as wrappers to be called (button patterns, unordered list patterns, ordered list patterns, headers, def lists, form elements, etc&hellip;) with the goal of having one set of predictable, easy to override, semantic markup. Jacine has done a lot of great work on the <a href="http://jacine.github.com/drupal/">demo page</a> she put together already.</li> <li>Provide an easy way for themes to override a specific pattern and have it apply to all patterns without the use of override functions.</li> <li>Provide predictable, precise, and useful CSS classes based on <a href="http://smacss.com/">SMACSS</a> guidelines that are easy to override or remove, ideally without the need of lots of override functions.</li> <li>Allow for components to ingest other components and template files (where appropriate).</li> <li>Disallow, to the best of our ability, markup to be directly injected into a component from a theme function or for a theme function to output markup directly without using a template/component. This is extremely frustrating currently and continuing to allow this would defeat the purpose of the component library.</li> <li>Provide development and UI hooks to allow developers and site builders to make use of the components through code or through UI</li> <li>Provide development hooks to allow developers to add additional components to the Component Library</li> <li>Provide a Style Guide menu callback with all components on screen (or divided between major groupings) to allow for easy theming</li> <li><strong><em>VERY SPECIFICALLY</em></strong> do not include any default CSS or JS for these components unless absolutely necessary (such as in the case of widgets). When default CSS or JS is needed, make sure it is as minimal as possible and very easy to override/remove, ideally without a process/preprocess function. Think Stark as the default theme for these components, not Bartik. <ul> <li>This may seem like it's missing the point of the component library, but from a front end developer's perspective, this is precisely what we want; predictable, semantic, clean markup that's easy to override that doesn't come with a bunch of CSS or JavaScript that we need to wrangle into place. While it will make life harder for site builders or backend developers not seeing their vision 100% initially, the goal here is to make frontend's life easier. Additionally, doing it this way allows for Contrib to come in with themes/modules (the line will start to blur) that are style guides to style this all (opening up easy integration with Bootstrap or Foundation or Skeleton or whatever in Contrib).</li> </ul> </li> </ul> > Related issue: [Issue #2235485](https://www.drupal.org/node/2235485) > Related issue: [Issue #1804614](https://www.drupal.org/node/1804614) > Related issue: [Issue #2702061](https://www.drupal.org/node/2702061)