Allow custom css UI file

[JustinGeorgi]

This PR checks for a theme.css file served from, OH_CONF/html. If that file exits it links it to the MainUI page after f7 css calculations have been made so that user directives are not over-riden by any f7 settings.

The ability to set MainUI site-wide css has come up several times in forum questions and requests. I think I remember at some point @ghys had some hesitancy with regards to enabling a site-wide css file like this, but I don't remember what the objection was and I can't find where I thought this comes from anymore so I may be misremembering. Either way, this small change just enables an advanced user to create a single css file.

However, if this starts to get a lot of use, I can see refactoring many of the current styles to use a series of --oh- specific css variables which would allow for easy creation and sharing of different MainUI themes (something that has just come up again in the most recent wishlist thread on the forums).

[relativeci]

#2525 Bundle Size — 10.87MiB (~+0.01%).

8cc865d(current) vs 1258cf0 main#2520(baseline)

Warning

Bundle contains 2 duplicate packages – View duplicate packages

Bundle metrics   2 changes 1 regression

	Current #2525	Baseline #2520
Initial JS	1.91MiB(~+0.01%)	1.91MiB
Initial CSS	577.48KiB	577.48KiB
Cache Invalidation	22.8%	19.4%
Chunks	226	226
Assets	249	249
Modules	2942	2942
Duplicate Modules	152	152
Duplicate Code	1.8%	1.8%
Packages	96	96
Duplicate Packages	2	2

Bundle size by type   1 change 1 regression

	Current #2525	Baseline #2520
JS	9.08MiB (~+0.01%)	9.08MiB
CSS	864.45KiB	864.45KiB
Fonts	526.1KiB	526.1KiB
Media	295.6KiB	295.6KiB
IMG	140.74KiB	140.74KiB
HTML	1.38KiB	1.38KiB
Other	871B	871B

Bundle analysis report Branch JustinGeorgi:jag-custom-css Project dashboard

---

^{Generated by RelativeCI Documentation Report issue}

[ghys]

@JustinGeorgi I don't remember where I made my reservations either but in general I'm very conservative when it comes to letting a simple remote HTTP request (either through the UI or directly) make catastrophic changes (direct JS execution or CSS overrides) that would render the UI inoperable or worse, doing malicious stuff.

I'm also not a fan of just making a request and checking whether there's a 404 response or not. I think it's better to check whether the file exists server-side and add it to a index.html template (which would have to be rendered dynamically).

[JustinGeorgi]

I'm also not a fan of just making a request and checking whether there's a 404 response or not. I think it's better to check whether the file exists server-side and add it to a index.html template (which would have to be rendered dynamically).

I'm in complete agreement here, unfortunately what I understand to be the necessary changes to core to implement this method correctly are beyond my current capabilities and also beyond my current time to learn.

I don't even completely disagree with your conservative viewpoint here, but I do think css is a very limited (and 100% easily reversible) risk. So, in my opinion, the pros outweigh the cons here (especially as there are more potentially dangerous alternatives to achieve this if a user is determined but inexperienced).

All that said, feel free to close this if you really think it's a non-starter. This was just a quick proof of concept while I was working on something else, so there's little lost.