Show Advanced KnowledgeHide Advanced Knowledge

Frameworkless SASS

Source see: sass-guidelines.md

1 Initial Problem

The Problem described here targets the a long term goal of removing deps to Bootstrap and moving towards SASS. For ILIAS 8 only parts of this will be possible, such as reducing the deps towards bootstrap in small steps.

Why use SASS instead of LESS?

LESS and SASS both are style-sheet-languages that compile to CSS, created to solve certain shortcommings in CSS that mostly revolve around possibilites to abstract and reuse code. They are comparable in possibilities, where SASS is slightly more expressive than LESS. The previous choice for LESS was motivated mostly by the usage of LESS in Twitter's Bootstrap Framework that was introduced to ILIAS. Currently it seems as if SASS just won the competition of languages that compile to CSS, with Bootstrap moved to SASS as well in the current version. The less compiler (running on node.js) did not recieve any updates since 2017, so it seems to be a good time to move to SASS as well.

Why only move the UI-Framework?

The UI-Framework is meant to provide UI components for all other components of ILIAS, with the ultimate goal that other components do not contain any custom HTML or CSS-code anymore. We are not there yet, but we are indeed getting closer. The scope of the effort to rethink how style code could be organized and structured was the UI-framework, since the effort spent on existing custom UI-code seems to become obsolete sometime soon anyway. The HTML/CSS-code in individual components currently is maintained by the component's maintainer and we can indeed observe, that it is already hard to keep that code up to date, even with the former development regarding Bootstrap and LESS. We do not expect that situation to become better and consider it to be in the best interest of maintainers to move their components to the shared collection of UI components of the UI framework as fast as possible. We do not forbid anyone to use the mechanisms for (of?) SASS that we intend to introduce for individual UI code in their component, but we don't think it is feasible or even worth taking these components into further consideration when renovating the style code of the UI framework.

Why would we want to get rid of Bootstrap as a framework?

From our perspective, Bootstrap was introduced to solve three problems:

1. Building grid layouts and responsive layouts was hard with the then-existing means of HTML and CSS.
2. The community generally lacked available expertise in building and styling UI components so sticking to an existing framework seemed to be a good way to save some work and to use some knowledge from elsewhere on our end.
3. Bootstrap implements some concrete UI components, such as modals, that we also wanted to use.

As well our hope was that

1. using Bootstrap would allow people with Bootstrap knowledge to easily redesign ILIAS as well.

Problem 1 has mostly become obsolete in the meantime due to the introduction of the CSS-grid and flexbox layouts to standard CSS, which was already incoporated in ILIAS 6. Regarding 2, we managed to build some serious expertise regarding the required fields of knowledge in our community in the meantime, with the added benefit that these experts also have knowledge of ILIAS as a general application. Thanks not least to the UI framework, working on UI and UX related questions is emerging as a field of work in its own right in the ILIAS community. The goal we had with 4 seem to never have materialized, probably due to the fact that ILIAS actually just uses Bootstrap instead of being completely implemented with it as a framework. 3 still seems to be a valid reason to use Bootstrap, but we don't believe that this benefit makes it worth to carry the whole bootstrap framework along as a dependency and to risk the sideeffects of this in other parts of the UI.

2 Conceptual Summary

We hereby propose to the JF to move the style code of the UI-Framework from LESS to SASS. We propose to get rid of the framework dependency to Bootstrap completely during that move. We furthermore propose to introduce a certain structure-model for the SASS-code based on a customized version of Inverted Triangle CSS (ITCSS). This new guideline will superseed the current LESS Guideline. We ask the JF to express its general support for that move so we can be confident to go on to make more detailed plans to get us there. We furthermore request the JF to ask questions or state constraints for our endeavor so we can look into them for a next iteration.

For Further Information see: https://github.com/ILIAS-eLearning/ILIAS/blob/trunk/src/UI/docu/sass-guidelines.md

As well as the according working group:  https://docu.ilias.de/goto_docu_grp_7484.html

Further note, that this will impact the System Styles, since the set of variables will be changed. In this step we also plan to work on the set variables offered in the System Style GUI

3 User Interface Modifications

3.1 List of Affected Views

Administration -> Layout -> System Styles Variables

3.2 User Interface Details

{For each of these views please list all user interface elements that should be modified, added or removed. Please provide the textual appearance of the UI elements and their interactive behaviour.}

3.3 New User Interface Concepts

None, but many of the existing will have a changed CSS/Less/SCSS structure

4 Technical Information

See here for a working version of the code of the project: https://github.com/catkrahl/ILIAS/commits/UI_itcss-ui-classes

5 Privacy Information

{ Please list all personal data that will need to be stored or processed to implement this feature. For each date give a short explanation why it is necessary to use that date. }

6 Security Implications

{ Does the feature include any special security relevant changes, e.g. the introducion of new endpoints or other new possible attack vectors. If yes, please explain these implications and include a commitment to deliver a written security concept as part of the feature development. This concept will need an additional approvement by the JourFixe. }

7 Contact

• Author of the Request: Amstutz, Timon [amstutz]
• Maintainer: Multiple
• Implementation of the feature is done by: {The maintainer must add the name of the implementing developer.}

8 Funding

If you are interest in funding this feature, please add your name and institution to this list.

• …

9 Discussion

10 Implementation

{The maintainer has to give a description of the final implementation and add screenshots if possible.}

Test Cases

Test cases completed at {date} by {user}

• {Test case number linked to Testrail} : {test case title}

Approval

Approved at {date} by {user}.