[Idea v2] Scompose elements files in real atomic elements

[equinusocio]

Hi @jonathanharrell, what do you think about break up elements files to real single components?

What i mean is that actually the forms.css files contains all elements style and i think that we should have a specific file for each element like input.pcss, checkbox.pcss, radio.pcss, progress.pcss etc.. like buttons.pcss and code.pcss are.

By this way we follow the atomic design principles and fix code will be more easy.

[jonathanharrell]

Yeah that makes sense. I will work on that for v2.

[equinusocio]

About that i think we will need another folders level like elements/forms/checkbox.pcss etc

[jonathanharrell]

Broke out files much more in fe25860.

[equinusocio]

@jonathanharrell I think this issue is not completed yes. We missed something big.

I think we have to make a hiq core that provide a default configration. But if i import just a component, that component should have his own configuration that read varibles from core (if i'm importing it) and if i don't want the core global settings i should be able to use that components and change is configuration. Right now HIQ is too much monolitc. Take iotaCSS components and elements as example. Each component can live alone with his CSS configuration API, reading global core settings if exist, or just read his local configuration/customisation:

https://github.com/iotacss/components.button

[jonathanharrell]

Note that variables.pcss is no longer being imported into HiQ. That file just exists for reference. All variable references include static fallbacks that serve as the default values.

As an example, I can import buttons.pcss and use it without needing to import any configuration. Using border radius as an example:

border-radius: var(--button-border-radius, 0.2rem);

If the user has defined --button-border-radius anywhere in their project, it will use that value, otherwise it will use 0.2rem.

So our variables are functioning differently than sass variables. By default, HiQ does not actually define any variables. This is to take advantage of the fallback system that native CSS variables provide.

Of course, if I want to, I can comment in the entire variables.pcss file and modify everything at once, but I don't have to.

[equinusocio]

I'm talking about decoupling internal variables from ”public" variables.

As you said, if i'm using another component/framework that define --button-border-radius at project-level, our button will be affected.

We need to isolate private component variables from "public variables". Take this example:

Somewhere in the project:

:root {
  --hiq-button-border-radius: 20px;
  --hiq-button-font-weight: 700;
}

inside our button.pcss we need something like:

button {
  --buttonRadius: var(--hiq-button-border-radius, 0);
  --buttonFontWeight: var(--hiq-button-font-weight, 400);

  border-radius: var(--buttonRadius);
  font-weight: var(--buttonFontWeight);
}

By this way public CSS api are decoupled from the component. If we need a refactor we can just change internal variables (not exposed to the users) without breaking changes.

[jonathanharrell]

Nice – yeah that makes sense.

[equinusocio]

@jonathanharrell We can also be sure that no other variables with the same name can override our -- buttonRadius because our variable is placed directly inside in the element selector as first ancestor.

PS: Do you really understand my terrible english? :D

[jonathanharrell]

Yeah that makes sense, although I want to make it possible to use HiQ with browsers that don't support CSS variables. Currently, we can use PostCSS to compute variables at build time, but only if they are defined on the root. There is no way to do this with variables that are defined within any other scope.

For now, I think something like this would be better:

button {
  border-radius: var(--hiq-button-border-radius, 0);
  font-weight: var(--hiq-button-font-weight, 400);
}

We just reference variables defined on :root. This way, the postcss-custom-properties plugin can compute the value if someone wants to support a browser like IE11.

Eventually, when IE11 usage is down to an insignificant number, we can change to something more like your example.

And yes, I can understand your English. :) Code examples help me the most to quickly understand your points. Thanks for your feedback!

[equinusocio]

By this way you will not decouple variables.

[jonathanharrell]

True, but for now I think supporting IE11 is more important. Eventually, we can refactor the way you suggested.

[equinusocio]

Wait, we can precompile variables when we build hiq.css. If someone are importing just a component it will probably have a custom postcss configuration. If they want to support ie11 they can simply set it in their postcss configuration. With my proposal we can cover both use cases :)

[jonathanharrell]

Not sure how exactly that would would work. If someone is using postcss-custom-properties (the plugin that most closely follows the spec), it is not possible to compute variables that are defined anywhere other than :root. I suppose they could use the postcss-css-variables plugin which I believe can compute at all levels.

[jonathanharrell]

FYI, here is the section of the new documentation I have been working on about providing fallbacks:

Custom Property Fallbacks

If you are supporting older browsers that do not support custom properties, you can run your css through PostCSS and use the PostCSS custom properties plugin. This will compute the custom properties at compile time.

Note that if you do this, you will lose some of the benefits of custom properties, including the ability to dynamically change them with JavaScript or override them within scoped selectors or media queries. To preserve custom properties for the browsers that do support them, configure the PostCSS custom properties plugin like this:

module.exports = {
    plugins: [
        // other plugins here
        
        require('postcss-custom-properties')({
            preserve: true
        })
    ]
}

This will result in both the original custom property and the computed property being included in the final css output:

button {
  background-color: hsl(210, 100%, 50%);
  background-color: var(--gray-lighter);
}

The custom property is included second and, therefore, will override the static value if the browser supports custom properties.

[equinusocio]

@jonathanharrell So we can switch to postcss-css-variables that allow variables declaration inside any selector like the original spec and allow us to achieve better modularity.

[jonathanharrell]

Ok I will try that out and do some cross-browser testing to make sure it works.

[jonathanharrell]

Looks like currently there is a parsing error with postcss-css-variables that prevents it from working properly. I will have to stick with postcss-custom-properties for now. Will need to save this refactoring for a future version once the postcss-css-variable issue is resolved, as I think usability with IE11 and older version of Edge is more important at this time.

[equinusocio]

Hi @jonathanharrell how are you :) Any news about this issue?

[jonathanharrell]

Hi @equinusocio, thanks for checking in. Unfortunately nothing has been done to address the issue in the postcss-css-variables plugin. I still want to support IE11 at this point so cannot make the move towards decoupled component variables quite yet. Possibly we could create a parallel version which takes this step, or wait until IE11 usage further declines.

[equinusocio]

Can you enter the issue link?

[jonathanharrell]

MadLittleMods/postcss-css-variables#62

[equinusocio]

@jonathanharrell Tell me if you need help o want to exchange some ideas

[jonathanharrell]

Thanks @equinusocio I plan to work more on this towards the end of this year/beginning of next year. Feel free to send along any ideas you have.

[jonathanharrell]

Locally scoped custom properties are now supported in v3.0.0: https://github.com/jonathanharrell/hiq/releases/tag/v3.0.0. HiQ is now dropping support for Internet Explorer.