It's become obvious that these random floating points everywhere
are unwieldy. Now they're all in one place with some fairly logical
variable names which will help out in design->implementation phase.
Font size of the whole app would ideally be controlled by a single
value. This value is currently hard coded using the :root CSS selector.
It is the intention to make this value configurable within riot. In the
interim all font-sizes have been converted to rem by the simple process
of regex. Replacing px values with their equivalent rem values assuming
a font size of 15px and then rounded to three decimal places, which was
the base at the time of this transformation.
I'm expecting another commit cleaning up rem values but I thought it
best to leave that to review.
This commit doesn't address any scaling issues. I thought it better to
land this unwieldy, mechanical, invisible change before the others
otherwise the pr would be impossible to review thoroughly.
This keeps the layout of the emoji fixed as much as possible.
Other changes:
* Fix width of each emoji container to static 52px
* Bump minimum width of right panel from 250px to 264px to match the
width in the figma
* Use normal font-weight for labels as per design
* Smaller vertical gap between emojis, again to match design
Instead of twisting `AuthBody`, this adds a new component for the different
styling of post-auth security flows. This also makes them fixed width and
adjusts padding to match designs.
This adds a step after login to complete security for your new session. At the
moment, the only verification method is entering your SSSS passphrase, but nicer
paths will be added soon.
This new step only appears when crypto is available and the account has
cross-signing enabled in SSSS.
Fixes https://github.com/vector-im/riot-web/issues/11214
Removes one of the two places we use Velocity, so we're one step
closer to getting rid of it for good.
Should therefore fix the fact that Velocity is leaking data entries
and therefore <hr> elements.
Hopefully also makes the logic in getEventTiles incrementally simpler,
if still somwewhat byzantine.
when badges with and without highlighted state have a very
different brightness (as they might do in dark mode), hardcoding
the fg color of a badge independent of it's highlighted state
to $accent-fg-color doesn't work well, so add an extra SASS
variable we can reassign to something more specific in the custom theme
