Consider updating from Inuit css

[PatReynolds]

Inuit css is six years old - there are newer css that are better and easier to use - should we change, and to what?

[AlOneill]

Some initial thoughts.

We need to know what "better" and "easier to use" actually mean.

There are newer versions of InuitCSS out there too, but we would need to check backwards compatibility with what we have now and assess the cost of updating. I believe the newer versions make use of newer CSS capabilities: these would need to be assessed against browser compatibility before we get too excited.

Using a different CSS framework would be a major undertaking, especially if our class names have to change (and/or entire layout structures be replaced). For App pages, the developers might be able to streamline the changes, but for RefineryCMS pages, where search and replace cannot be done online except manually, the changes will have to be done rather more painstakingly, offline and in a decent text editor.

As I understand these things, the core of Inuit is relatively light (i.e. small) for a CSS framework.

There are things to like about our current InuitCSS:

• as I understand these things, the core of Inuit is relatively light (i.e. small) for a CSS framework
• the class (style) names are made up of readily-understood (and remembered!) syllables, whereas other frameworks make abundant use of abbreviations, sometimes a single letter
• some of us are pretty handy with the Inuit classes, having used them for several years at least
• we also understand much of the basis of the framework, which makes it relatively easy to adapt it to our needs

Conversely, there are some things that we have never got sorted, such as integrating the way the different sections (modules?? — no, but cannot recall for now) are compiled into a whole, in a more efficient manner and so that file-size is reduced.

[richpomfret]

Can we define what Inuit can provide in the more recent/latest version and highlight backward compatibility issues? We may not wish to update right now, but we should be aware of what updates may provide for us and this can drive the update (if benefit is clear vs cost).

[jayto581]

Determining what a newer version of InuitCSS could provide or highlighting any backward compatibility issuers is not a straight forward task.

The creator of InuitCSS has never created any official documentation. Instead he relies on comments in his CSS code files. He encourages developers to look at the InuitCSS framework’s source code files for assistance.

FreeUK Genealogy projects are currently using InuitCSS version 5.01 (released March 2014)

An unofficial InuitCSS 5.0.1 documentation site (http://terabytenz.github.io/inuit.css-kitchensink/) has been create by a third-party. It combines the source code comments and examples together on a convenient page showing what the version 5.01 framework can do.

Some time in 2016, the creator of InuitCSS stepped back from the project’s day-to-day operation.

InuitCSS version 6.0.0 (released February 2018) After several beta versions, version 6.0.0 was released on February 26, 2018. The setup, directory structure, and namespace was changed. Also, most of the code was rewritten. The following note was included in a pre version 6.0.0 beta change log:

This release contains a lot of changes, including breaking changes, deprecations and a lot of improvements, bugfixes and new features. Please bear this in mind and double-check everything before you upgrade your project to the new version.

An unofficial inuitCSS 6.0.0 documentation site (http://inuit-village.github.io/inuit-village/) has been create by a third-party.

Work on version 7.0.0 started in October 2018 and is currently in development. No official version 7.0.0 release date has been announced. GitHub activity has been very low over the last couple of years. https://github.com/inuitcss/inuitcss

Much has changed since in website development since 2014. Microsoft Internet Explorer, once a dominate browser, is no longer a major factor. CSS standards have matured and many of the past hacks have been since been solve by Flexbox and CSS Grid in simpler and cleaner ways.

I’m not saying the old InuitCSS is bad. It offered clever and useful solutions at the time, but moving forward other better supported frameworks should be considered if there are clear benefits vs cost..

[richpomfret]

@jayto581 let's move this into a document and have a basic plan in place for that possible time in the future when our code suddenly breaks in the face of a browser update. We can look to test out the new version of Inuit perhaps, in a safe testing environment and assess what breaks/what kind of work may be involved in doing such an update..

[AlOneill]

I've had a play with Inuit 6, to begin to get a better sense of how involved it would be to upgrade. In short, a lot of work and a lot of testing. The main challenges I've noted so far are that:

• our SCSS, which generates our CSS would have to be restructured
• most (maybe even all) our class-names would have to be changed in all our pages/partials
• flex is very different from our grid system: in some ways it is not as flexible (!) — I think this would affect Refinery pages more than app pages — will continue to ponder and assess

• managing the changes will be tricky as a lot needs to be done at the same time — we'll need a sound plan of action

  If we change to a different CSS framework (I will look around, but any suggestions?), then the challenges will be more or less the same.

[jayto581]

I have updated and moved my findings to a Google Doc as requested.

https://docs.google.com/document/d/1HAPLIt7y8KqHYZsxmrQfSbMRagY98bLtVoIp2Ga7JRI/edit

[AlOneill]

@jayto581 TY. Have read your doc and left a few comments.

Given the work involved in updating, whichever solution we choose, plus the initial and subsequent learning required, it is very clear that we will need to choose wisely. Caveat emptor.

[PatReynolds]

Need to decide what we want the framework to do, and see how this affects the options. Story on ice until we have the resources.