Open arky opened 6 years ago
make sure community is OK with reduced browser support of bootstrap 4
Related:
https://github.com/iiab/iiab-menu/issues/9 "Redevelopment Plans"
This tkt (#1112) and #1031 and #1159 and iiab/iiab-menu#9 overlap a lot, so let's soon close those that are not actionable~
Let's nurture next-gen-realism design choices around the thoughts that've begun here iiab/iiab-menu#9
I've closed #1159. Feel free to close further tkts so we can consolidate the best front-end UX ideas (Bootstrap 4 and/or others) around discussion (like) iiab/iiab-menu#9
Context: IIAB's existing home page (http://box) places Content Packs a.k.a. modules according to this JavaScript logic: https://github.com/iiab/iiab-menu/tree/master/menu-files/js
The problem is that bootstrap, even 4, does not scale fonts very well, so I wrote some js. BUT, I think this can be used instead (magic numbers 26 and 14 could still be adjusted).
:root {
--base-font-size: calc(14px + (26 - 14) ((100vw - 300px) / (1600 - 300)));
--base-line-height: calc(1.3em + (1.5 - 1.2) ((100vw - 300px)/(1600 - 300)));
}
body {
font-size: var(--base-font-size);
}
h1 { font-size: calc(1.2 * var(--base-font-size)); }
Now I'm not sure even this is necessary.
@tim-moody explained during todays's community/team call (http://minutes.iiab.io) how browsers can store local state that is private and protected from web servers (unlike web cookies!) in order to store personal preferences (like IIAB language/page verbosity) in the client:
function setLocalStore() {
if (selectedLangs.length > 0)
localStorage.setItem("selected_langs", selectedLangs.toLocaleString());
else
localStorage.setItem("selected_langs", "");
}
It seems this local storage / local state could even be used by a student's smartphone walking by different IIAB web servers, e.g. if a school has many different IIAB's in different classrooms?
The way this works is that client machines (i.e. most all browsers) can indeed store such key-value pairs (language and font/layout/verbosity preferences etc) while the browser "fully protects" these preferences within each browser. Such that web servers (apparently!) can never get access to these personal/linguistic/verbosity/layout preferences.
Why not scratch all the css calculation stuff and instead use media-queries? Web browsers are always dealing in 72dpi despite screen dpi of the device. Therefore a 3" (horizontal width) device is hardly different than a 3.2", 3.6", 4" device. eg: the media-query groupings are quiet well defined:
` / Smartphones (portrait) ----------- / @media (max-width : 320px) { / Styles / }
/ phablets, small tablets / @media (min-width : 321px) and (max-width: 767px) { / Styles / }
/ iPads (portrait and landscape) ----------- / @media (min-width : 768px) and (max-width : 1024px) { / Styles / }
/ Desktops and laptops ----------- / @media (min-width : 1024px) { / Styles / } `
All phones should fit under that 320px category. Large font it up! Desktop would be normal and the others would be interpolated.
iiab-menu.js file(s) need complete overhauling. The JavaScript file does browser detection and makes font adjustments, these are now handled by Bootstrap 4.
@darkenvy Can you please help with this?
https://github.com/iiab/iiab-menu/blob/master/menu-files/js/iiab-menu.js#L59-L63
Refer: https://github.com/iiab/iiab/issues/1031