Road to v7

[florianbouvot]

It's time to start thinking about inuitcss v7.

Raodmap:

• Update normalize.css to v8 [[refs #353] Update normalize.css to 8.0.0 #377]
• Remove Bower support [Remove bower support #376]
• Remove old browsers support (= some cleanup)
• Switch to flexbox for media object [[refs #379] [objects.flag|media] Use flexbox #383]
• Switch to flexbox for layout object [[refs #380] [objects.layout] Use flexbox #384]
• Switch to flexbox for list-inline object [[objects.list-inline] Switch to flexbox #414]
• Add documentation [separate repo]

Questions:

• Add more utilities?
• Always propose responsive utilities variants?

@inuitcss/core @herzinger what do you thing? some suggestions?

[herzinger]

I wouldn't add more utilities out of the box, no, and we could devise a system to let the user chose if the ones we have should be responsive or not in a consistent manner (I have something in mind). Apart from that, the whole discussion about moving some stuff to settings.globals and making that file official (not example) applies here as well. There's also the circle CI update, that I believe is already covered in a PR.

[LayZeeDK]

What do you have in mind for documentation?

[florianbouvot]

@herzinger in my mind utilities must be responsive and configurable. I can create a "plugin" with more utilities out of main framework.

What would you move in settings.globals? headings font size 👍, objects settings 🤔, utilities settings 🤔

@LayZeeDK A website that describe how to use the framework and describe every part of it (with example...).

[florianbouvot]

I think we could remove bower support.

[LayZeeDK]

@csshugs has created some pretty sweet documentation websites in the past:

• inuit kitchen sink
• inuit-docks

See #358

Other noteworthy ones are:

• Inuit.css Kitchen Sink by Terabyte Interactive
• Inuit Village by Rodrigo Erades

[florianbouvot]

@LayZeeDK that's true and I did not help him much 😔

[yourownmood]

Maybe move from node and ruby, to only node as dependency?
I could cover node-sass for building/compiling our scss.
We could replacing our scss testing framework with a node based one.

Would you be interested if i set something up?

[florianbouvot]

@yourownmood I don't know where we depend from ruby?

[florianbouvot]

I'm thinking about renaming this:

• $inuit-global-example to $inuit-example
• $inuit-global-spacing-unit to $inuit-spacing

Thoughts ?

[florianbouvot]

I'm wondering if this declarations are already needed in elements.page?

html {
  overflow-y: scroll;
  min-height: 100%;
} 

[LayZeeDK]

The overflow-y: scroll; declaration is pretty opinionated.

I do not see any bad side effects of min-height: 100%;. I always use it in projects.

[florianbouvot]

@LayZeeDK Thank but my question is more: it's not declaration for old browsers?

[yourownmood]

@florianbouvot My confusion came from the fact that in our CircleCi setup we still depend on sass (ruby version) and true-cli (ruby version) instead of the node-sass and 'true` node package.
I've created an issue and PR to remove this dependency and only rely on the node versions of those packages:
#391

[LayZeeDK]

Thank but my question is more: it's not declaration for old browsers?

No, they are still applicable. They are not specific to a browser vendor or version.

[florianbouvot]

@yourownmood ok and thanks for the PR, I let @anselmh check this point.

[florianbouvot]

@LayZeeDK Ok but what the benefit of using this declarations?

[LayZeeDK]

Ok but what the benefit of using this declarations?

It is in the file.

/**
 * Simple page-level setup.
 *
 * 2. Force scrollbars to always be visible to prevent awkward ‘jumps’ when
 *    navigating between pages that do/do not have enough content to produce
 *    scrollbars naturally.
 * 3. Ensure the page always fills at least the entire height of the viewport.
 */

html {
  overflow-y: scroll; /* [2] */
  min-height: 100%; /* [3] */
}

I cannot explain (2) more detailed than what is there.

(3) is good for making sure that the background color is the same in the entire viewport even on pages with very little content. Additionally, if you have a toolbar that is fixed to the bottom, then you want it to be the bottom of the viewport, not the bottom of the content.

[florianbouvot]

@LayZeeDK 🤣

• (2) doesn't seem necessary on macOS, I will try on Windows
• (3) not needed for background-color

I've the impression that it concerns old browsers 🤔

[LayZeeDK]

Demo for (2)
https://stackblitz.com/edit/inuitcss-page-overflow-y

[LayZeeDK]

Revisiting (3), I am struggling to find a modern browser use case other than for JavaScript:

getComputedStyle(document.documentElement).height;

[herzinger]

(2) doesn't seem necessary on macOS, I will try on Windows

Some Chrome themes still show this issue, even on Mac (where usually the main scrollbar is invisible). Originally it was specifically for Windows browsers.

In any way, I see no need to remove any of that, as it's pretty short and inoffensive.

[florianbouvot]

@herzinger thank you for your feedback.

[lhermann]

I'm thinking about renaming this:

• $inuit-global-example to $inuit-example
• $inuit-global-spacing-unit to $inuit-spacing

In favour of removing global. It's nice to think in terms of unit through. I always alias $unit: $inuit-global-spacing-unit; as well as $unit-small and so forth. Strictly speaking it's just a pixel value, not only useful for spacings.

we could devise a system to let the user chose if the ones we have should be responsive or not in a consistent manner (I have something in mind)

That would be helpful!

[inlikealion]

I agree with @lhermann That dropping the term unit tips the scale from being crisp and to the point to lacking clarity. A lot of the inuitcss and @csswizardry class naming pushes back on the "terse at all costs" for maintaining clarity and consistency.

[rowild]

@florianbouvot How do you think about changing all padding/Margin values to em in v7?

[florianbouvot]

@rowild I think it's not a good idea, I think it's better to px or rem unit for padding and margin : easier to manage, predict...

[rowild]

Yes, rem of course. But currently inuitcss does not generate rem values for padding and margin, right? Or am I overseeing something?

[nicoqh]

Is it time to revisit #157 as well?

I'm not entirely up to date on the latest baseline grid discussions, but it still seems to me that unitless line heights should be ditched.

[herzinger]

@nicoqh the current @inuit-font-size mixin does account for what you pointed out on that issue in its calculations tho, so it's a bit of a mute point. Maybe we could review the mixin itself eventually and make the change, as there's a chance it would make said calculations simpler, but it's not a priority in my opinion. The end result would be indistinguishable when it comes to output.

[nicoqh]

... but it's not a priority in my opinion

Agreed!

[inlikealion]

Hey team, how's this going? Are there any specific needs to help increase development momentum towards the v7 release? Any primary blockers or input needed?

Has @csswizardry addressed the direction the community-driven project is taking, or his future involvement? I think it might be cool to clarify who is helming things for this cycle so people know who to rally behind, ask for tasks, report to etc. This may already be happening and those of us not as deeply involved are just missing it, but that's just an indication that clarity and communication for onboarding new community members would be beneficial.

Cheers 👍

[csshugs]

@inlikealion
I know, I wasn’t very active here the last 2 years but you (and everyone else) can always ask me for help or feedback on any issue or idea for inuitcss.

I’m currently very confident about v6 of inuitcss. I think it works very robust, although I’m aware about the missing docs which might be a showstopper for a few potential inuitcss users. This is something I’m motivated to tackle with v7, apart from a few other ideas I gathered over the past 2 years that can make the framework much more adaptable.

[csshugs]

To come back to the original topic of this issue: I don’t think there are any more cleanup tasks for us to make that concern the support of older browsers.

Add more utilities?

No. IMO, this is not the way inuitcss was ever meant to go.

Always propose responsive utilities variants?

For the few utilities that we still provide, we should provide responsive variants optionally.

[herzinger]

Has @csswizardry addressed the direction the community-driven project is taking, or his future involvement? I think it might be cool to clarify who is helming things for this cycle so people know who to rally behind, ask for tasks, report to etc. This may already be happening and those of us not as deeply involved are just missing it, but that's just an indication that clarity and communication for onboarding new community members would be beneficial.

As far as I'm aware, @csswizardry hasn't being involved with this project in any way, shape or form for more or less half a decade. I wouldn't be surprised to hear that he isn't even using it for a while, to be honest. From the time I got more involved with it a bunch of year ago, he wasn't even mentioning it much or at all, nevermind showing up in the repo, be it with code or in the issues, and the @inuit/core team and some active colaborators such as myself were the ones deciding and implementing stuff. Even that slowed to a halt some lengthy time ago.

As @csshugs said, the v6 is pretty stable and ready to use, tho, even if it could have some improvements and updates in regard to the development landscape, for sure.

[LayZeeDK]

Harry Roberts still promotes something like inuitcss through the ITCSS methodology.

[herzinger]

Yes, what I mean to say is that the last few versions of the framework have no actual input from him, and I believe no further input is to be expected, either in new code or validation. We do follow his ITCSS philosophy (and I'll be the first to defend it whenever some suggestion might stray a bit from it), but he is not personally involved for a long time. If you follow him at all, you'll see his main focus has gone more into performance optimization and such and away from straight up architecture and development in the last few years, and much of the core blocks of inuitcss have changed much by our hands since, like the current baseline / vertical flow system, which is completely different, and the grid system that is current moving on to flexbox, to cite a few.

TL;DR: while this project started as Harry Roberts' brain child, lives under his github handle, and follows his methodology, he is not directly involved or actively endorsing it anymore, and I don't think we should expect him to be again in the foreseeable future. Or that's how I see it as one of the more active and old contributors, at least.