Admin UIs on the front-end are difficult to theme

Isn't that the reason why we have a dedicated admin theme setting?

Ah that was not clear for me, sorry.

I'm not sure we can make it significantly easier without Web Components/Shadow DOM.

In terms of implementation, Edit module allows admin themes to define a edit_stylesheets key in their YML file, that CSS will then get loaded on the front-end. IMHO that's the only sane way to implement it in Drupal 8, with the abstractions that are available to us.

I'm not sure we can make it significantly easier without Web Components/Shadow DOM.

Exactly, we're beholden to the cascade without some impermeable barrier in a shared DOM. And ShadowDOM support is currently negligible: http://caniuse.com/#feat=shadowdom

I think the best we can do now is put bomb-proof CSS resets into the admin modules that expose components in the display theme environment.

I dont think there is a good solution to it, except having a single admin theme that would style the admin elements for custom themes out of the core. Something closer to what WP does. All other solutions look too complex and hacky to me - would rather prefer to have this problem unsolved and write some small sass library with some unified admin styling to carry from project to project to having something hacky to make the local tasks tabs look nicer.

First you say

I prefer the solution that the edit module has […]

Then you say

I've got a not-perfect-but-better suggestion here […]

that seems to conflict? :)

So this is the actual proposal:

Instead of having to support these custom admin stylesheets for each module, we allow an admin theme to define a more generic stylesheet called "admin-helpers" that a module can load for when it's trying to do admin stuff on the frontend.

Something like that could indeed also work.

But other than being less explicit about which features are supported (Contextual, Quick Edit, Node Preview …), how does this help exactly? It removes some cruft (no need for something like contextual_stylesheets, quickedit_stylesheets per module/feature), but at the same time potentially loads far too much CSS and requires a convention rather than an explicit system.

I don't think this statement is true, otherwise I think this would indeed be fine:

[…] but it is much better than duplication the same styling across many more files, which is what will happen if we implement the edit module solution across all modules that require it […]

Which duplication? There is no CSS duplication AFAICT: the "admin helper CSS" for Contextual module is very different from that for Quick Edit module, for example.

And because of that, this statement seems wrong to me too:

It is also better because it scales across contrib, the Seven theme can't define a custom admin stylesheet for IPE.

If there was duplication, this would be true to some extent. But any contrib module that needs "admin helper CSS" would probably require its own CSS; even if a part would be duplicated, then very likely there would still be custom CSS needed.

AFAICT the entire proposal in #11 hinges on the assumption that multiple modules/features that need admin CSS will need at least partially the same CSS. Can you give an example of this? I don't see it, currently.

What if libraries.yml had a dedicated group/key called something like frontadmin, which could be used to load admin CSS when the default theme is active?

Something like this in an admin theme libraries.yml:

toolbar:
 css:
   frontadmin:
     - toolbar.css
  dependencies:
    - toolbar.module

This is probably terrible pseudo-code, but that't the notion.

Then when CSS is loaded from the default theme, there could be something that checks the admin theme's libraries.yml and only grabs things in the frontadmin group for loading.

That would allow this sort of loading without library alters for every module that needs this.

But not all the "frontadmin" things appear on all the "front" pages. Which means you'd be loading unused CSS.

#17:

If the library item has dependencies declared, then it will only load if that dependency is used, right? Thought it was something like that.

#20 is actually a pretty sweet idea and it would work without web components, too.

As long as admin content on a FE theme is properly prefixed with a class, we could automatically filter and change the CSS to be prefixed by all those classes.

e.g. reserve

.admin-theme-content

And add to each style rule in the admin theme automatically:

.admin-theme-content .component__foo

That would need us to know what parts are admin and which are not, but it might work :).

If not: iframes ;) - that we either fill in dynamically (JS) or statically from the server for the requested resource.

Just throwing this out there:

Since the Frontend theme is responsible for what is displayed and the Admin theme may not know of the front end theme's color and other clashing. I think the module should define some base styles and if a Component is to be "using" on the frontend and should provide it's own theme styles.

So if we had a Seven admin theme and a BlackBartik. BlackBartik would be responsible for updating colors and styles to match better the front-end theme. Admin components that show on the front end theme that may need styling: Toolbar and Contextual links for example.

Basically, leaving the responsibility for 'SMACSS theme' to the theme.

This is similar to D7, means a bit more work for the themes(maybe), but at least there is no theme system admin loading contortion needed.

#2587615-9: Discuss if Drupal's theme system should be component driven I said roughly the same thing here.

Just a general thought: libraries-extend may come in handy for frontend themes wanting to tweak how admin theme-provided components look on the frontend. This stuff is confusing.

To me, the best of both worlds is that we actually make use of the cascade here:

- Module defines any necessary functional styles for front-end admin UI
- Admin theme provides default aesthetic styles for front-end admin UI that mesh with back-end UI
- Front-end theme has an opportunity to tweak aesthetic (or functional styles) in case something in front-end UI clashes with the front-end theme, or just to customize the look.

I added a suggestion for a possible solution in #2632584: Add a "public admin" theme subtype so that admin themes can have subthemes for front-end UI components.

If I understand the issue here, this can be solved by a base theme, can't it? We don't need an extra abstraction layer?

Drupal gives you a lot of functionality if you want it, and that comes with defaults. If you don't like the defaults you *should* have everything you need to override.

Override libraries in your theme info file, override specific files in hook_[css/js]_alter, and core and contrib should provide sane ways to override markup. If that's an issue, make an issue/patch.

A Base theme could provide output that normalizes core and popular module output so that it looks like a cohesive whole, and set a baseline for any sub theme.

#2566847: Move theme quickedit CSS to the Seven theme was closed per @lauriii's comment at #2566847-32: Move theme quickedit CSS to the Seven theme.

So this issue is becoming immediately relevant as we look at moving styling from outside-in (settings tray) into the dialog library so it can be more broadly used.

After some discussion with @wim-leers and @tedbow about where the 'theme' styles for the settings tray (or any other 'admin thing' on the front end) should be located and how they should be implemented. We arrived at a few conclusions.

1. We do want the 'theming' of settings tray to become part of a more broadly applicable library of styles for 'front end things'.
2. It makes sense for this library in some way be part of, or linked to the admin theme.
3. We should implement that in a way that provides simpler and better out-of-the-box developer experience.
4. We do need to effectively 'sandbox' admin things so that themes don't bleed into them.
5. While shadow dom would be an ideal way to isolate admin things, it is not yet well supported enough, however iframe has improved quite a lot, and has the browser coverage we require so we should at least explore that.

Here are the actionable items I am moving forward on.

1. Move all the 'theme' styles (basically everything that relates to the dark background) out of Settings tray module. DONE
2. Make sure that all possible form element implementations are covered by the library IN PROGRESS
3. Extend those styles to cover the other types of dialogs, toolbars etc. that are currently presented on the front end IN PROGRESS
4. Explore how these can be moved into the theme system (a subtheme of Seven?).
5. Create a proof-of-concept for implementing settings tray with iframe.

I think populating a Drupal site with lots and lots of iframes purely to avoid style bleedover seems potentially problematic. Particularly because there are many cases where a custom site wants to theme certain public admin tools—admin tabs and status messages are the ones that most come to mind. Cordoning those off into iframes probably makes overriding those styles more difficult. I also think there's likely going to be potential challenges with viewport sizing, as you mentioned. Also, iframes just do weird things sometimes. Certainly worth exploring, I just think it's potentially going to cause unexpected issues. I also think front-end people looking at Drupal front-end code and seeing lots of iframes everywhere are going to raise an eyebrow. Again, an idea worth exploring. Just feels a bit odd to me at first glance.

I think populating a Drupal site with lots and lots of iframes purely to avoid style bleedover seems potentially problematic.

The primary reason is not to avoid bleedthrough, it is to provide a clean and simple developer experience for adding administrative functionality to the front end while maintaining consistent visual affordances. Bleedthrough is an implementation obstacle.

there are many cases where a custom site wants to theme certain public admin tools—admin tabs and status messages are the ones that most come to mind.

I think those two in particular may be exceptions that continue to be themed by the front end theme.

Cordoning those off into iframes probably makes overriding those styles more difficult.

How so? If the styles all come from a sub-theme of Seven all the themer needs to do is clone that subtheme and change what they need to. In doing that they no longer need to worry about overriding any styles from their front-end theme.

I also think there's likely going to be potential challenges with viewport sizing, as you mentioned.

Yes but they are not insurmountable. CKEditor module is, and always has been, using iFrame quite successfully and it is responsive.

Also, iframes just do weird things sometimes. Certainly worth exploring,

Do you have some examples of the weird things we might encounter?

I also think front-end people looking at Drupal front-end code and seeing lots of iframes everywhere are going to raise an eyebrow.

Perhaps. Yes ideally we would want a cleaner more modern solution like shadow dom but that is not yet ready so this seems to me like the only viable option.

I really think that bleedthrough as an implementation obstacle is much less of a problem than you are making it out to be. If the styles are handled with class names and selectors that are well-scoped, there really shouldn't be any issue.

This is a significant proposal that could be considered an API change, and I think the reasons for pursuing this do not seem to merit the scale of the potential change.

Maybe I'm missing something. Could you provide some examples where the fact that we're not using iframes has caused real-world problems? I haven't run into any so far.

If the styles are handled with class names and selectors that are well-scoped, there really shouldn't be any issue.

My experience so far has shown that even with very heavy scoping it's really hard to get the styling to be consistent across every possible Drupal theme. To paraphrase Tim Plunkett 'we have to deal with the intersection of two infinite sets, the infinite set of possible forms that a module may want to render in the tray, and the infinite set of possible selectors a front-end theme might introduce'.

If it were the case—as it is in some other CMSs that system provided a single finite and pre-defined set of classes, ie. If you just had classy and nothing else—then this would be less of a problem. However in the Drupal 8 world we have absolutely no idea what classes, pseudo-classes, elements, data attributes etc. will be in the front end theme, so it's impossible to effectively wall them off.

Having said that, if you some ideas on how we could do it effectively I'd love to hear them. I don't love the iFrame solution either, because we will have to do alot of other work to make it happen, particularly with a11y.

Thought I would post to this issue here since we running into this problem with the Settings Tray module

#2853208: [META] Determine best method ensure consistent theming of Off Canvas Tray

In that issue we are trying to look at a few different ways to 'sandbox' the Off-Canvas dialog so the default theme's CSS doesn't bleed into it.

The 2 approaches that have patches in progress in child issues are:
#2826722: Add a 'fence' around settings tray with aggressive CSS reset.
#2853222: Explore using an IFrame to sandbox CSS for the Off Canvas tray(very rough)

I think if we take the CSS approach it might involve something along the lines of what quickedit does to pull in extra styles sheet.

The iframe approach which I initially was not very interested in actually works. There are issues though as far as determining when forms should submit to the parent or the frame and links, opening either in the frame or the parent and avoiding opening a nested iframe. But if you are interested in the details take a look at that issue.

Re: @mdrummond's comment in #32

Also, iframes just do weird things sometimes.

I have also heard this and want to make sure we get feedback from people who have run into problems. Better to hear them early to maybe decide against using the iframe approach or at least handle the problems. Honestly some people have been horrified when I mention we are considered using an iFrame so we shall see.

Shadow DOM is definitely the right tool for the job here. That's explicitly designed to solve the problems you're trying to tackle here. Browser support might not be there yet, but perhaps there's a way to keep the current CSS—which admittedly might be buggy if a theme isn't scoping their styles properly—as well as adding styles via Shadow DOM, which would work as a nice progressive enhancement in browsers that support Shadow DOM. As more browsers support Shadow DOM—which seems highly likely—then styling of these components would improve.

To me, that's a far better way to tackle this problem than iframes or reset CSS, both of which are well-intentioned efforts, but which will have lots of unpredictable side effects and edge cases.

I've found iframes tend to be particularly buggy in responsive situations. In some cases, you need to explicitly define the heights and widths of iframes to get around problems, but that can be very problematic when the amount of content in an iframe can vary widely. Styles that depend on the viewport size are going to have issues within an iframe. I also think that most front-end developers who look at code littered with iframes are going to raise their eyebrows, and that's going to lead them to thinking that Drupal isn't a good choice for front-end development. If iframes would likely work without any challenges, that would be one thing, but I don't think that would be the case.

Even a very aggressive reset CSS filled with important statements is likely to be problematic. It's just not possible to predict what CSS will be written, and what level of specificity it will have. And adding loads of importants also is a huge code smell that will raise lots of eyebrows.

There are lots of ways that sites can break the way Drupal works. We can't control all of them. One approach (which is admittedly labor intensive) could be to look for CSS rules in some popular themes that might cause problems with front-end UI and file issues/patches to ask maintainers to change them. If themes are using properly scoped BEM classes in their styles, they really shouldn't be interfering with front-end UI. Our documentation already advocates for BEM classes in theme's CSS, but further advocacy around the consequences of not doing so could help educate the community.

Exploring Shadow DOM, even if it doesn't work everywhere right now, seems like a reasonable approach to provide extra protection for front-end UI styles as a progressive enhancement that will become more valuable over time.

@mdrummond

Exploring Shadow DOM, even if it doesn't work everywhere right now, seems like a reasonable approach to provide extra protection for front-end UI styles as a progressive enhancement that will become more valuable over time.

How would we implement shadow dom as a progressive enhancement without duplicating a significant amount of code?

was all: initial discussed already somewhere?

From #2853208-16: [META] Determine best method ensure consistent theming of Off Canvas Tray by ksenzee:

This is a lot like the Drupal Gardens themebuilder. In fact, it's almost exactly like the themebuilder. We explored most of these options for that project, and ended up with an aggressive CSS reset plus an ID-based specific prefix for all the styles we actually wanted. That would be my recommendation here as well. It was practically bulletproof, and a lot easier to maintain than an iframe- or JS-based solution would have been.

I say we go with a proven solution and see how we can improve on them later when browsers get up to speed. Core is not the right place for radical experimentation of frontend tech.

@nod_ re #41 I did try "all: initial"
It does work I think but from the page your link it doesn't look like it is widely supported especially in mobile.

I tried adding it to #2826722: Add a 'fence' around settings tray with aggressive CSS reset. it does reset properties that would otherwise be overridden by the default theme.

I assuming though that like the shadow-dom it would probably be trouble to use it because we can't rely on it in all browsers.

Re: #42
That does sound like a good point.

Shadow DOM is definitely the right tool for the job here... Browser support might not be there yet

I don't see any discussion on this issue about the possibility of polyfills, such as Shady DOM and Shady CSS. Have those been explored and found inadequate? If so, what specifically makes them inadequate?

It would be awesome if someone could update the issue summary with a current list of Drupal UIs currently experiencing (or working way too hard to circumvent) the problem described by this issue title. For example, per #31, the off-canvas dialog used by Settings Tray is playing whac-a-mole with CSS resets.

Yes, straight from the Mozilla Dev docs: https://developer.mozilla.org/en-US/docs/Web/Web_Components/Shadow_DOM

Shadow DOM provides encapsulation for DOM and CSS in a Web Component. Shadow DOM makes it so these things remain separate from the DOM of the main document. You can also use Shadow DOM by itself, outside of a web component.

To create a Shadow Root, using the standard, you just need to:

// create shadow DOM on the <p> element above
      var shadow = document.querySelector('#hostElement')
        .attachShadow({mode: 'open'});

And in doing so you create, effectively, a protected DOM that isn't impacted by whatever is going on in the main DOM. If you wanted to assign styles to an element that does impact a contributed theme or isn't impacted by a contributed theme, this is an effective way to do it.

I'm happy someone else has brought it up because I feel like I've pestering the issue #2826722: Add a 'fence' around settings tray with aggressive CSS reset. a lot. Don't want to be broken record. But Custom elements + Shadow Dom would be nice. But Shadow DOM would be a really effective way to accomplish what you want there.

Re #46, that's great for the browsers that implement Shadow DOM. But Firefox+Edge+IE still comprise 30% of desktop browser usage, so per #44, the polyfill options need to be evaluated to see which, if any, are adequate for what this issue needs solved. For example, https://github.com/webcomponents/shadycss#limitations lists some limitations, but I'm not clear on whether any of those are hard blockers for solving this issue."Document level styling is not scoped by default" seems like it could be, but that item also lists some options for how to work around that.

I don't see any discussion on this issue about the possibility of polyfills

I missed #20 when I wrote that, so apologies for that. Thanks for bringing it up back then. I don't know if any discussion about the polyfills available at that time took place, but hopefully those polyfills have gotten better in the meantime.

In the past when I've suggested a web component like solution, it has opened the door for someone to list all the reasons why all of the web components set of specifications aren't really suitable for a solution right now:

1. Browser support
2. The requirement of polyfills
3. Maybe later

Yet, out of all the solutions listed (which I gather are: using a good CSS reset + proper namespacing and good selectors for CSS) only Shadow DOM can guarantee protection from tampering / accidentally overriding by a contributed theme. Shadow DOM protects against a theme's re-CSS-resetting or anything else that's happening in the main DOM. Shadow DOM allows you scope css inside of the shadow root so that it only really needs to care about the elements that inside it's pocket of DOM.

The Custom Element spec would allow you to bundle up the work as a single element that can be used. That spec can be used even if we didn't want to come to terms about how to distribute the component as a bundle using either HTML Imports or ES6 modules.

I'm going to have to track down all the places I've made this argument, but I don't seem to have made it here so here's a bit of a rehash of previous arguments.

The webcomponents.js polyfill has a adaptable loader that only loads what each browser needs.
https://github.com/webcomponents/webcomponentsjs/blob/master/webcomponen...

When a browser no longer needs the polyfill it won't be loaded. Therefore it is well suited for eventual removal when browser capabilities catch up. This impacts the overall size of the polyfill, ranging from < 10kb to < 100kb. The loader itself is < 4kb.

Custom elements is a great way of engineering components.
As developers we seek to bundle up a bit of a reusable functionality as a unit, so that we can reuse that unit whenever we need to solve the same problem again. Having a nice way to reuse that solution as a HTML tag is really nice (subjective).

Custom elements can define their own apis
Through the definition of custom attributes and properties, each element can provide a base functionality (when no attributes or properties are set) that can be overridden an modified through settings those attributes and properties.

Use of slots (from the spec) allow custom elements to wrap and extend normal html content
In my use of custom elements, I primarily have provided content creators a means to declare that their content "is a" text+image component, or a callout, or whatever. So that I could address styles in a scoped manner for those elements. This approach works well when you have custom elements for the wrapping element and the individual elements it wraps.

Custom elements already fit within normal Twig templating.
By bundling up all this functionality as a simple element, one can easily place it in a twig template (as long as it's library is loaded) and use it's functionality.

Platform interoperability
I can now make a single element that works in for the .Net, Adobe, PHP, Ruby, and JS application platforms for my company. I am in the process of getting my internal partners to adopt my components to solve a number of common display issues when it comes to creating UIs.

@cosmicdreams: thanks for that info. Just so you know, I'm a big fan of Shadow DOM, so you don't need to convince me of its virtues. I think the same is true for many other people on this issue. The browser support limitation is kind of a big deal though.

From https://www.polymer-project.org/2.0/docs/devguide/shadow-dom#shadow-dom-... :

These polyfills provide reasonable emulation of native shadow DOM while maintaining good performance. However, there are some shadow DOM features that can't be polyfilled completely. If you're supporting browsers that don't include native shadow DOM, you need to be aware of these limitations. It's also helpful to understand some details of the shady DOM polyfill when debugging applications under shady DOM.

Therefore:

only Shadow DOM can guarantee protection from tampering / accidentally overriding by a contributed theme

is only a true statement to the extent that we evaluate those polyfills and understand where their limitations intersect our use cases. I don't think either Mozilla or Microsoft has yet made any statement as to when they plan to release native support for Shadow DOM. They're working on it, but what does that mean: months? years?

@effulgentsia in regard to the timing question:

I've been tracking that question for a few years. Technically, Firefox starting tracking development on Shadow DOM 2 years ago: https://platform-status.mozilla.org/#shadow-dom

Recently they've started completing a some of issues in that epic. Most notably:
1. implement attachShadow and slots: https://bugzilla.mozilla.org/show_bug.cgi?id=1404842
2. Add slot element: https://bugzilla.mozilla.org/show_bug.cgi?id=1402941

Key issues to watch are:
* Meta issue for all DOM issues: https://bugzilla.mozilla.org/show_bug.cgi?id=1405934
* Meta issue for all Layout issues: https://bugzilla.mozilla.org/show_bug.cgi?id=1405937

IE has Shadow DOM as one of it's highest voted issues:
https://developer.microsoft.com/en-us/microsoft-edge/platform/catalog/?q... (checkout the nice, but perhaps out of date, chart of standards support)

Although, it's not currently being developed for IE Edge: https://developer.microsoft.com/en-us/microsoft-edge/platform/status/?q=...

Or maybe it is but they're not really talking about it? https://twitter.com/kylealden/status/696668006412193792

Hard to say. That last tweet makes it sound like they're working on it but it's not going to be in latest Creator's Update: https://docs.microsoft.com/en-us/microsoft-edge/dev-guide

I'll be listening for any update on their progress.

One more small quibble @effulgentsia (and I feel bad to report this) you stated the claim that Firefox and IE "still comprise 30% of desktop browser usage". A recent analysis of global browser share puts that figure at 12.34% .

source: http://gs.statcounter.com/browser-market-share#monthly-201610-201710-bar (for more granularity see the line chart instead).

Which is still significant I think. I'm not sure if we have solid rules or precedent on how much market share we will base a decision on and how much we won't. I think this same question came up when we were questioning if we should drop IE 7 and 8 support.

Notable trends: Firefox now has more market share than IE + Edge. If Firefox were to finish it's implementation of Shadow DOM then 89.51% of the web will have support for the standard. Note: I included UC Browser's share because it's based on Webkit, but I couldn't find facts on which version. I didn't include MS related shares or the ambiguous "Other".

A recent analysis of global browser share puts that figure at 12.34% .

If you include mobile, then yes, since mobile is virtually entirely Chrome and Safari. If you just include desktop (which I think is more representative of what's more commonly used for Drupal administration), it's 26% on statcounter, and slightly more than that on netmarketshare.

Hey @effulgentsia, maybe it would be good idea to create a new issue to specificly focus on the question of whether we can use Shadow DOM on it's own to scope regular HTML elements so they can be protected from whatever's going on with the DOM.

I found a neat code example here: https://stackoverflow.com/questions/43119814/using-shadow-dom-within-con...

That shows show someone wanted to protect a bit of markup that was going to be used by a text editor. Seems like we could experiment with this approach to see if we can implement scoped styles to a concrete administrative element like the settings tray to see if we can put up a barrier between what's going on in the element vs the rest of the page.

Should we explore that in #2915311: JavaScript VDOM library evaluation: integrating web components?

I'm quite late to these discussions. I came from Claro's #3020422: Toolbar style update, and looked around the various issues about moving module theme CSS into Seven. I haven't seen any mention of accessibility, except for a brief hint in #37 here, so I'd like to bring up a WCAG guideline. (I'm not sure which issue to direct my comments to, but this one seems to be the main top-level overview.)

I was struck by this comment from Cottser in #2539992-18: Move theme toolbar CSS to the Seven theme:

We won't break Bartik because we have Stable in place :) so we are free to make sensible decisions as to what makes sense to keep in core or where things should live in our @internal themes, Bartik and Seven.

So what happens when we release D9.0.0? I'm assuming we will reset Stable, since it seems like the only opportunity we'll have to let all themes benefit from markup improvements in the years since D8.0.0. But if toolbar styles have moved into Seven (or Claro) then won't that leave every other theme with an un-styled toolbar? They'd have to implement toolbar styles of their own.

When the toolbar was introduced in D7, the major goal was having a consistent visual navigation on both the public and admin sides of the website, to aid users in finding their way to a task from anywhere. In doing so, it helps a lot towards WCAG guideline 3.2: "Make Web pages appear and operate in predictable ways". Styles such as the icons and active menu trail do well at addressing the technique of "using the same non-text content for a given function whenever possible" in 3.2.4 Consistent Navigation. If every front-end theme has to implement it's own toolbar styles, there's a high risk that the toolbar will fare poorly with this success criterion.

This was to say how it matters for WCAG. I can see there's been a lot of discussion about the scoping aspects of toolbar and other modules which need to work on the front end, I'm still digesting that. Shadow DOM seems to pretty good for accessibility, but with a very important gotcha that IDREFs don't work across the shadow boundary. Most of the a11y stuff I've read about shadow DOM comes from 2014.

I discussed this issue with @justafish, @shaal, @effulgentsia, @wim.leers, @alexpott and @tedbow at DrupalCon Amsterdam 2019. We talked about the different use cases we try to support. This is what we agreed on:

1. When I enable a module with any admin interfaces, I want them to be designed so I can use the features from the module, without having to write any code
2. When I change my admin theme, I want the admin UI to be designed consistently so that the UI looks professional
3. When I build a site where end users create content, I want to be able to configure content creation to use the frontend theme so that I can build a consistent end-user experience

I opened some child issues based on the next steps we identified during the discussion:
#3103375: Let themes indicate whether they work as front-end and/or admin themes
#3103378: Require themes to specify whether they support content editing
#3103380: Allow rendering dialogs using the admin theme
#3103382: Allow specifying which theme should be used for rendering a render array

#63: Thanks for opening those! Commented on them. Does that mean this issue should become a meta/plan issue?

It would be awesome to see a solution to this, although I understand why it is very difficult. I've been trying to implement Layout Builder on a site and it has been a ton of work to get it looking decent. Now I've added the ability to use Media Library within CKEditor and found that Media Library is almost unusable when viewed in the front-end theme. If Layout Builder is the future of Drupal this is going to be very inhibitive.

Note that the CSS reset just got easier with the addition of #3170864: Add postcss-preset-env. We can now do a

#Selector * { all: initial; } and it will compile down to the following:

* {
  animation: none 0s ease 0s 1 normal none running;
  -webkit-backface-visibility: visible;
          backface-visibility: visible;
  background: transparent none repeat 0 0 / auto auto padding-box border-box scroll;
  border: medium none currentColor;
  border-collapse: separate;
  -o-border-image: none;
     border-image: none;
  border-radius: 0;
  border-spacing: 0;
  bottom: auto;
  box-shadow: none;
  box-sizing: content-box;
  caption-side: top;
  clear: none;
  clip: auto;
  color: #000;
  columns: auto;
  column-count: auto;
  column-fill: balance;
  grid-column-gap: normal;
  column-rule: medium none currentColor;
  column-span: 1;
  column-width: auto;
  content: normal;
  counter-increment: none;
  counter-reset: none;
  cursor: auto;
  direction: ltr;
  display: inline;
  empty-cells: show;
  float: none;
  font-family: serif;
  font-size: medium;
  font-style: normal;
  font-feature-settings: normal;
  font-variant: normal;
  font-weight: normal;
  font-stretch: normal;
  line-height: normal;
  height: auto;
  -webkit-hyphens: none;
      -ms-hyphens: none;
          hyphens: none;
  left: auto;
  letter-spacing: normal;
  list-style: disc outside none;
  margin: 0;
  max-height: none;
  max-width: none;
  min-height: 0;
  min-width: 0;
  opacity: 1;
  orphans: 2;
  outline: medium none invert;
  overflow: visible;
  overflow-x: visible;
  overflow-y: visible;
  padding: 0;
  page-break-after: auto;
  page-break-before: auto;
  page-break-inside: auto;
  perspective: none;
  perspective-origin: 50% 50%;
  position: static;
  right: auto;
  -moz-tab-size: 8;
    -o-tab-size: 8;
       tab-size: 8;
  table-layout: auto;
  text-align: left;
  text-align-last: auto;
  text-decoration: none;
  text-indent: 0;
  text-shadow: none;
  text-transform: none;
  top: auto;
  transform: none;
  transform-origin: 50% 50% 0;
  transform-style: flat;
  transition: none 0s ease 0s;
  unicode-bidi: normal;
  vertical-align: baseline;
  visibility: visible;
  white-space: normal;
  widows: 2;
  width: auto;
  word-spacing: normal;
  z-index: auto;
  all: initial;
}

I'm curious how resetting all styling would help solve this issue.

Do we want to re-evaluate Shadow DOM as a solution now, for D10, where we no longer need to worry about IE 11?

I also opened #3230518: Figure out how we want to incorporate web components in Drupal 10 for a broader discussion about web components.

These days something like css cascade layers would address the problem (when they're/implemented):

https://www.bram.us/2021/09/15/the-future-of-css-cascade-layers-css-at-l...
https://www.w3.org/2021/10/TPAC/demos/css-architecture.html

+1 to that, but it'll be a while before all of Drupal's supported browsers do that. Firefox ESR will likely be the last holdout, as they release every 1.5 years (and have just had a release) IIRC.

In the meantime, our best bet is doing an all: revert. This is supported on all of Drupal 10's browsers, and differs from all: initial, because it resets all of the properties back to the browser defaults (not the spec's defaults). This means <div>'s will reset back to display: block, instead of display: inline

Just opened up #3291797: Refactor Drupal 10 settings tray / off-canvas to use modern CSS

The next release of Firefox ESR is only 1 week away.
https://support.mozilla.org/en-US/kb/firefox-enterprise-101-release-note...

Firefox 102 is the next ESR and will be released on June 28, 2022.

I'm making great progress on #3291797: Refactor Drupal 10 settings tray / off-canvas to use modern CSS, but I want to note some headaches here.

One problem I'm seeing is that themes can control the markup inside of the settings tray, but we're writing the settings tray reset to be outside of the theme.

Example of this is that Olivero has special theming/markup for messages. However, settings tray is expecting specific markup. I now have to take into account Olivero's changes. The same goes with Claro overriding Tabledrag markup.

I'm handling it, but there's more. If a theme decides to remove the form-item class from the markup via template, styles will break. We can't really account for everything.

I think the correct solution is to use web components. I'm still proceeding with the above issue because it's really needed, but in the future, web components can solve this.

Another issue I'm having is with the form autocomplete items. They get injected at the end of the body element, so I do not have control.

I was wrong.