The media library view looks correct when invoked from an admin page. But when brought up from the settings tray (via layout builder), it loads the front-end theme, and loses its custom styling.

I expected it to retain the admin theme's styling.

CommentFileSizeAuthor
Edit_layout_for_Demo_Landing_Page___NAMM_org.png144.05 KBmherchel

Comments

mherchel created an issue. See original summary.

phenaproxima’s picture

phenaproxima
he/him
Primary language English
Location Massachusetts
commented

I think this might be a potential stable blocker for Media Library.

A few options were discussed in Slack. @mherchel said this:

There’s really 3 options:
1) CSS reset a la settings tray.
2) Iframe to prevent styles from leaking in
3) Web component… but that gets really tricky and has browser support issues

#2 is, in my opinion, a non-starter; iframes interact with the browser in a fundamentally different way from a normal document, and Media Library is heavily reliant on document-bound JavaScript. Trying to sandbox it in an iframe for styling reasons would likely break a lot of our implementation assumptions and lead to a huge amount of refactoring, not to mention potential security and accessibility issues. So I vote that we avoid iframe usage like the plague.

I would greatly prefer #1, because it seems like the most attainable option. Our CSS selectors are currently fairly "meek" from a cascading point of view, in the sense that they mostly rely on class composition to achieve the desired look. We could likely fix a lot of the styling issues @mherchel uncovered here by targeting some of the CSS to an ID, which has very high precedence. This is a similar approach to what Settings Tray did; we wouldn't necessarily need a full reset, but we could probably take advantage of IDs to impose the styling opinions we feel most strongly about.

mherchel’s picture

mherchel
he/him
Primary language English
Location Gainesville, FL, US
commented

Yeah, I agree w @phenaproxima. A reset would be easy to implement, and get 95% of the job done. Styles that end up leaking through can then be cleaned up by the themer.

I do want to say that it appears that the default styles from the library are also not being loaded. I removed the CSS files from my front-end theme, cleared cache, and then reloaded, and the view still was not styled.

phenaproxima’s picture

phenaproxima
he/him
Primary language English
Location Massachusetts
commented
Issue tags: +Needs tests

I do want to say that it appears that the default styles from the library are also not being loaded.

I'm tagging this issue for tests of that specific problem. That sounds like a straight-up bug.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented

FYI: the same is true for the "link" and "image" dialogs (from the Text Editor module) when doing in-place editing of a body field using CKEditor.

That's because we haven't done the work to make dialogs in the front-end theme match the back-end theme.

IOW: this problem is not specific to Media, but with Media Library + Layout Builder in Drupal 8, it'll be encountered far more often.

mark_fullmer’s picture

mark_fullmer
he/him
Primary language English
Location Tucson
commented

A reset would be easy to implement, and get 95% of the job done. Styles that end up leaking through can then be cleaned up by the themer.

Our team has tested doing a JS-style inline CSS reset modeled after #2952390: Off-canvas styles override CKEditor's reset and theme for this. Though it does capture 95% of the styling, we're concerned about that last 5% where certain elements would either need to be massaged in a more idiosyncratic way. To give one example of this, the details CSS from core/themes/seven/css/components/details.css is needed, but this includes a .seven-details class that wouldn't be present in active themes, so that CSS needs to be reworked (a couple ways to do that).

A solution we're toying with that would faithfully render 100% of the admin theme is shown in a sandbox module at Media Library Theme Reset.

While this is unpleasantly duplicative of core CSS, it does provide a solution that would be plug-and-play for all themes thus avoiding the need for themers to do a round of cleanup.

Any thoughts on whether an approach like this could be added in the core Media Library?

xjm’s picture

xjm
she/her
Primary language English
commented
Priority: Normal » Major

Promoting to major as per #2834729: [META] Roadmap to stabilize Media Library.

lauriii’s picture

lauriii
he/him
Primary language Finnish
Location Finland
commented
Parent issue: » #2195695: Admin UIs on the front-end are difficult to theme

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.9 was released on November 6 and is the final full bugfix release for the Drupal 8.7.x series. Drupal 8.7.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.8.0 on December 4, 2019. (Drupal 8.8.0-beta1 is available for testing.)

Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

bkosborne’s picture

bkosborne
Primary language English
Location New Jersey, USA
commented

This is the issue that's blocking me from switching my sites to using media library for all media form widgets. We use layout builder heavily and are currently using the entity browser widget for selecting media items. It works well because the entity browser widget loads in an iframe, so it has complete "fencing" of the CSS.

Isn't the best solution here to render the media library dialog in an iframe? Even with the module Mark Fullmer contributed, the media library looks very bad/broken when used on our front end themes.

maskedjellybean’s picture

maskedjellybean
Location Portland, OR
commented

+1 for using an iframe. Until this gets resolved I'm using Mark Fullmer's module as well, but even though it makes the Media Library usable it still looks pretty bad. You're never going to be able to predict all the styling that someone will put into their front-end theme that you will need to override.

mark_fullmer’s picture

mark_fullmer
he/him
Primary language English
Location Tucson
commented

Just chiming in here to agree that https://drupal.org/project/media_library_theme_reset is an imperfect solution here; our team also has some front-end CSS that takes precedence over the reset, due to how it was implemented.

So, +1 to a solution such as an iFrame.

phenaproxima’s picture

phenaproxima
he/him
Primary language English
Location Massachusetts
commented

So, +1 to a solution such as an iFrame.

I'd like @seanB to confirm this, but to reiterate what I said in #2: I'm fairly sure that, due to the way the media library fundamentally works, it is impossible for us to have it load in an iframe. Its interactions with the AJAX system, and with the rest of the page, preclude that. I believe that moving it into an iframe would likely require a lot of deep rewrites in the media library module, which are no longer possible (it's a stable module, after all). Unless there's some contrib proof-of-concept demonstrating that the media library can be in an iframe without enormous pain, then I don't think that is a viable option.

Besides, that would sidestep the real issue, which is that admin-side stuff is often incompatible with frontend themes. It is a difficult, pre-existing problem in core which the media library exposes in an exacerbated fashion. Doing crazy hacks and interesting workarounds for the media library will fix a symptom, but not cure the disease.

bkosborne’s picture

bkosborne
Primary language English
Location New Jersey, USA
commented

Okay, thanks for providing that explanation. Also, I apologize, I didn't read your first comment that explained why pursuing the iframe option was not practical. So then it seems like trying to apply a super aggressive CSS reset to the media library may be the only path forward.

phenaproxima’s picture

phenaproxima
he/him
Primary language English
Location Massachusetts
commented

No apology necessary! I know how frustrating this problem can be, and I appreciate the feedback that proves how urgent of an issue this is. Ideally we'd fix it in a way that worked for other admin-facing frontend things in core (*cough*Layout Builder*cough*). So although a CSS reset isn't ideal, it might be the best we can do for the time being. It does look like a plan to address this core-wide is materializing over in #2195695: Admin UIs on the front-end are difficult to theme, though, so there's hope!

seanb’s picture

seanb
Primary language Dutch
Location Netherlands
commented

+1 to the CSS reset (as a contrib solution) because of what phenaproxima already explained. Changing this to an iframe would require major changes in how the module works at the moment and provides it's own set of challenges.

I've struggled with the frontend theming myself as well. Some sites want the backend theme to be applied in layout builder, others theme the media library in the look and feel of the frontend (which is not as easy as I would like it to be). We should probably provide a documentation page to point people to the contrib module and provide some explanation on how to theme this in frontends as short term solutions. Fixing #2195695: Admin UIs on the front-end are difficult to theme is the real solution, but that will probably take a while unfortunately.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

phenaproxima’s picture

phenaproxima
he/him
Primary language English
Location Massachusetts
commented
Issue tags: +Triaged Media Initiative issue
mherchel’s picture

mherchel
he/him
Primary language English
Location Gainesville, FL, US
commented

I'm dealing with this within Olivero now in #3172957: Olivero: Media library within Layout Builder modal is unstyled.

Once again, I'm thinking that the styling should be part of core. I'm currently looking at the way that Claro/Gin style the library, and there's a significant amount of styling/templates that go into it.

Also 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;
}
mglaman’s picture

mglaman
Primary language English
Location WI, USA
commented

There is another problem, beyond styling. If the frontend them replaces input[type="submit"] with button[type="submit"], the AJAX filtering for Media Library breaks. See #2998908: Views exposed form Ajax selector doesn't work on buttons.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

jayhuskins’s picture

jayhuskins
he/they
commented

I'm curious if we could flip this issue on its head by rendering layout builder in the admin theme as this module does:
https://www.drupal.org/project/layout_builder_admin_theme
then inject the front-end styles and rendering for the block previews.

dataweb’s picture

dataweb
Primary language Dutch
commented

Hi there, i created a module that takes the Claro Media Library templates, hooks and preprocess functions to whatever theme.
It would be nice to review the module in the context of this issue.
https://www.drupal.org/project/claro_media_library_theme

mark_fullmer’s picture

mark_fullmer
he/him
Primary language English
Location Tucson
commented

i created a module that takes the Claro Media Library templates, hooks and preprocess functions to whatever theme.
It would be nice to review the module in the context of this issue.

This is an approach that does indeed work, if requiring a fair amount of CSS duplication and template file re-registering. It takes the same approach as the contrib module media_library_theme_reset, which has an open issue for supporting Claro: #3100124: Add support for Claro.

I am a maintainer of that module. Maybe instead of creating a separate module, we could collaborate and integrate the Claro theme option that you've architected into Media Library Theme Reset? I'd be happy to work on the integration with you, if that sounds good. Let me know!

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.