Ability to customize CSS via custom properties

[massimo-cassandro]

Important. Before posting a feature request please make sure to search the closed issues, maybe the feature you want to implement has already been asked and denied for not providing a valid explanation or simply because it was something the user wanted for him or his project.

Please describe the feature you want to be implemented. Please note: features should be something that everyone can use and not just something you need for your project.

Introduce the ability to customize some properties of the default css with custom properties

Explain why the feature is useful Describe some usage cases.

It would increase the speed of customization while always keeping the link to the original css and its updates

Have you seen it somewhere else? If so please provide live examples, images, videos, etc. anything that help us understand the feature request

Additional context Add any other context or screenshots about the feature request here.

[gingerchew]

Hey there @massimo-cassandro,

I really like this idea! Making theming more accessible with custom props is a great addition. I'm going to add the feature request label so we can be sure to include it in an update.

[tomasvn]

What stuff would you like to see, to be customizable? As basically everything could be moved to css variables, @massimo-cassandro

[massimo-cassandro]

I think the more things can be managed by custom variables the more the ability to customize gligthbox will increase: colors. font family, sizes and weight, some dimensions... etc

[gingerchew]

Thinking back to this now, here's a general idea of what it could look like (just brainstorming so values aren't real). As far as "decisions" that need to be made, I think these are things to consider:

Prefixing:

.glightbox-container {
  --overlay-color: #fff;
  /** OR */
  --gl-overlay-color: #fff;
  /** Another Option */
  --glb-overlay-color: #fff;
}

I am definitely in favor of using a prefix like --gl- or --glb-. I'll be using --gl- for the rest of the rest of the code though.

Scope:

:root {
  --gl-image-min-width: 200px;
}
/** OR */
.glightbox-container {
  --gl-image-min-width: 200px; /* declare on the container element */
}
/** OR */
.gslide-image {
  --gl-image-min-width: 200px; /** declare on individual slide type/components */
}

The second and third offer some benefits maybe the most useful of those being preventing scope creep.

Defaults:

/** Declare each custom property */
.gslide-image {
    --gl-image-min-width: 200px;
    min-width: var(--gl-image-min-width);
}
/** OR */
/** Use the fallback option inside var() */
.gslide-image {
  min-width: var(--gl-image-min-width, 200px);
}

Gotta take some time to review the styles and see what can be extracted and what should stay as foundation for each component, but would love insight on the 3 things above.

[massimo-cassandro]

I think that setting all variables inside :root is the easiest way. This way, glightbox could be quickly customized with an extra css containg all the needed variables.

Use the fallback option inside var() seems to be the better way for default values

[gingerchew]

My only hesitation with using the :root is that everything uses :root, for example Bootstrap.

But not enough to be a stick in the mud about it :)

[tomasvn]

I am more for the local scope of the class, and if I need to override it, that would be easy, we should not imo pollute the :root, as there might be other variables set already. And as for the naming I am more inclined to name as --gl-. If it would be only eg. --overlay some other variables could already be --overlay, but with the prefix we would know that it belongs to glightbox

.gligthbox-class {
  --gl-clr: red;
  color: var(--gl-clr);
}

.glightbox-class {
  --gl-clr: blue;
}

[gingerchew]

You actually reminded me of another point which is dealing with the length of some properties in CSS being converted to custom properties:

.glightbox-container {
   // This is my preferred
  --gl-color: #fff;
  // Even though Emmet would get what "c" is when hitting tab, I think this loses a ton of meaning
  --gl-c: #fff;
  // Here though I don't feel like meaning is lost
  --gl-bg-color: #ccc;
  // Only using consonants gives the same feeling as the second option. Concise but loses meaning in the grand scheme of things
  --gl-brdrclr: #000;
}

Obviously there might be some considerations when the names get incredibly long:

.glightbox-container {
  --gl-slide-description-background: #fff; /* This is a little silly */
  --gl-slide-desc-bg: #fff; /* I think this maintains meaning while also not triggering my RSI */
}

An aside:

I know right know we use postcss for polyfilling CSS features, mainly nesting, but this feels like a good place to use SCSS: ```scss $prefix: '--gl-'; $properties: ( 'color': #fff, 'bg': #010203, 'border': 1px solid #fff, 'text-decoration': 1px solid underline ); .glightbox-container { @each $prop, $val in $properties { #{$prefix}#{$prop}: $val; } } ``` Which outputs as: ```css .glightbox-container { --gl-color: #fff; --gl-bg: #010203; --gl-border: 1px solid #fff; --gl-text-decoration: 1px solid underline; } ``` Probably not a good idea to go messing with _too_ much in one go though :)