Default-HTML-Frame for Mail in System Style (2/3)

[kjansen2608]

This adds the SCSS and compiled CSS file for the new default html frame.

For full description see:
#9564

[catenglaender]

Fantastic project! A great step forward to make E-Mails look visually more appealing and connected to the instance's branding. Love to see it. 😄 🎉

Has there been a discussion, concept or meeting notes document guiding what design properties we carry over from the skin and which ones we set independently?

For example, I think we might want to also pull the font-size and font-family variable into the email as institutions would probably very much like to see their house font styling in their emails (assuming the local PC has the font installed and the email client can render in custom fonts).

What we have never really done in ILIAS is checking variables during compile and use this information to activate fallbacks or throw an error. I wonder if this would help us to protect the E-Mail style code from design choices coming from the system style that email-clients cannot handle well. For example, we can check the $il-font-family-sans-serif variable if it does contain the fallback 'sans-serif' and if not throw an error. The built-in sass:string has some limited tools to process things like that: https://sass-lang.com/documentation/modules/string/
With such a guard layer in place I would like to pull quite a lot from the skin. @yvseiler and I work on new and improved typographic spacings and seeing those in the emails as well would be amazing.

Just some food for thought. As a starting point, I would be okay with approving the current state as is and tweak and improve from there.

I very much appreciate the hard work everybody has been doing with this. Rendering in email clients is a mess, but this is a wonderful foundation to get to a satisfying result.

[yvseiler]

Hi @kjansen2608

Thank you a lot for contributing to ILIAS.

Following review from @catenglaender as CSS Authority to Sign off on Code Change and as we have no further comments on this matter, we are happy to give our approval here.

kindly,
@thibsy, @klees and @yvseiler

[kjansen2608]

@catenglaender Thanks a lot for the nice feedback, really appreciated.

The font settings are the only thing we haven’t moved into variables yet. As far as I know, the email styles currently rely on standard fonts because many clients don’t handle custom ones reliably. But we could definitely look into that. Thanks for the great idea with the compile check, that would make the whole setup more robust. As far as I’m informed, custom fonts also need some special handling, since similar to the logo they would have to be delivered as attachments with the email. Maybe we can bring it up in the future CSS group meetings and see how we could make it work :)