?
avatar brianteeman
brianteeman
13 Dec 2019

Steps to reproduce the issue

Expand the module position dropdown
image

Expected result

This css is loaded
https://github.com/dgrammatiko/joomla-cms/blob/28245843b39e1ec3365dfa33c2b89d2b0e6b185f/administrator/templates/atum/scss/vendor/choicesjs/choices.scss#L24

Actual result

The css from the vendor is loaded after

image

System information (as much as possible)

Additional comments

avatar brianteeman brianteeman - open - 13 Dec 2019
avatar joomla-cms-bot joomla-cms-bot - change - 13 Dec 2019
Labels Added: ?
avatar joomla-cms-bot joomla-cms-bot - labeled - 13 Dec 2019
avatar Quy
Quy - comment - 13 Dec 2019
avatar dgrammatiko
dgrammatiko - comment - 13 Dec 2019

Once jshjohnson/Choices#794 is merged upstream we could just add the preferred z-index before importing their SCSS.

If someone needs to patch this at all costs the !important needs to be added at the relevant line (please let's not do that)

avatar Scrabble96
Scrabble96 - comment - 19 Dec 2019

This is exactly what I was referring to some months ago regarding the z-index of full-screen codemirror: the vendor css opens after the Joomla! core css, rendering the Joomla! css useless without !important added. See my issue #23512 and closed PR #23528, neither of which were resolved, but it all hinges on the order in which css is loaded. Surely the order for all css files should be:

  1. Vendor css
  2. Joomla! core css
  3. Template css
  4. User css
avatar dgrammatiko
dgrammatiko - comment - 19 Dec 2019

@Scrabble96 the order of the styles is like that (although I don't really understand what this joomla core css is).
Eg for com_content edit the css should be:

  • the layout css
  • all the css from each input
  • the css from the template

This particular issue is due to the way we override the original vendor css. I could have just @include vendor/original.css and then added all the overrides on top creating unnecessary bloat for the end users to d/l...
Instead we recompiling the src of that scss to our needs but that didn't actually worked out as planned... Small bug, easy fix

PS. The PR upstream is already merged so I guess I need to do the PR to close this...

avatar Quy
Quy - comment - 21 Jan 2020

@brianteeman The overlapping is no longer an issue in the nightly build. OK to close?

avatar brianteeman
brianteeman - comment - 21 Jan 2020

closing as solved elsewhere

avatar brianteeman brianteeman - change - 21 Jan 2020
Status New Closed
Closed_Date 0000-00-00 00:00:00 2020-01-21 11:12:32
Closed_By brianteeman
avatar brianteeman brianteeman - close - 21 Jan 2020

Add a Comment

Login with GitHub to post a comment