A backend UI is a "work place", not a readable only frontend UI.
There no CMS, no backends in any other CMS that i use (WP, J3.x, Drupal, FirstSpirit, DatoCMS, Typo3, ecc.) that have a so big fonts like Atum.
~14 px is the right choice for all who WORK with a CMS.
I have tried and this little change gives a more professional look&feel to the UI (mostly in pages with lists).

It makes sense to modify the base font size, but keeping the same ratio to the base font in some other places is an issue and should be looked after carefully.

Example: we can get hardly readable font-size: 0.7875rem; or even worse font-size: 0.65625rem; for some items (sub-menus, badges) which should be modified to the original value if we change the basefont.

A designer can do that. I am just making the switch to correctly use font sizes the way bootstrap intended them to be used in this pr

The patch works. But with it applied the fonts are a tad small, making the whole interface look 'wrong'. So the base font would be better left at 1. The other changes are fine. The following shows with and without the patch:

Changing the size as a demo is fine. But what gets committed? Is this just a taster waiting for a more comprehensive treatment?

A designer can do that

I therefore suggest to let a designer do this as this patch as is makes Atum very difficult to deal with.

Actually, I think we should ask @brianteeman to set $font-size-base to 1, so that nothing appears to change, and then apply this PR. If that is the way it should be done it will make a designers job easier.

changed the approach and code - see updated first post

I do understand the replacement of the change:

• from $h1-font-size: 1.65rem;
• to $h1-font-size: calc(var(--font-size-base) * 1.65);

Not everyone understands rem and with this change that doesn't matter... as long as the font-size-base is equal to 1rem. (which is done... $font-size-base: 1rem;)

I don't understand this part:

// Set the base font size (1rem = 16px)
$baseFontSize = '0.875rem';

$this->getWebAssetManager()->addInlineStyle("html {--font-size-base: {$baseFontSize};}");

The default font-size of my browser is set to normal which is 16px.
When you add the code above it will be reduced to 14px.
When this font-size is used for the input fields my mobile browser will zoom in until the font-size is set to 16px.

I would not recommend reduce the default set font-size. I would like to keep it 1rem

using a default font-size of 14px is soooooo 2005. :-)

The whole purpose of the pr is to reduce the base font to 14px and at the
same time provide the flexibility for it to be changed

On Sat, 24 Oct 2020, 13:00 Hans Kuijpers, notifications@github.com wrote:

I do understand the replacement of the change:

• from $h1-font-size: 1.65rem;
• to $h1-font-size: calc(var(--font-size-base) * 1.65);

Not everyone understands rem and with this change that doesn't matter...
as long as the font-size-base is equal to 1rem. (which is done... $font-size-base:
1rem;)

I don't understand this part:

// Set the base font size (1rem = 16px)
$baseFontSize = '0.875rem';

$this->getWebAssetManager()->addInlineStyle("html {--font-size-base: {$baseFontSize};}");

The default font-size of my browser is set to normal which is 16px.
When you add the code above it will be reduced to 14px.
When this font-size is used for the input fields my mobile browser will
zoom in until the font-size is set to 16px.

I would not recommend reduce the default set font-size. I would like to
keep it 1rem

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#31207 (comment),
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJ4P4IVLHB7GAV5RAAPETTSMK6WTANCNFSM4S3K6NCQ
.

no no no... please not reduce the base font to 14px.
Please set the base font size to 1rem and don't adjust it to something equal to 14px.
The default font-size of browsers is set to 16px and not without any reason.
Please keep it as 16px although it isn’t an official WCAG font size standard.

I like the flexibility though... but please don't adjust the base font-size back to 14px.

It is done on purpose and is the purpose of this pr to address a
reported issue

On Sat, 24 Oct 2020, 15:32 Hans Kuijpers, notifications@github.com wrote:

@hans2103 commented on this pull request.

In administrator/templates/atum/index.php
#31207 (comment):

@@ -35,6 +35,11 @@
$a11y_highlight = (bool) $app->getIdentity()->getParam('a11y_highlight', '');
$a11y_font = (bool) $app->getIdentity()->getParam('a11y_font', '');

+// Set the base font size (1rem = 16px)
+$baseFontSize = '0.875rem';

1rem on browser default is indeed 16px
multiply it by .875 will reduce it to 14px.
please don't do that

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#31207 (review),
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJ4P4O42RDV724LKGJMYJTSMLQPVANCNFSM4S3K6NCQ
.

I've seen the issue and I've seen the many words, including capital words, being used so address an issue.

Changing the way how font-sizes have been calculated throughout scss is a great improvement. Not everyone understands rem and this is a nice towards understanding.

Changing base font-size back to 14px is not the way we should implement.

Screenshot taken from my laptop with html { font-size: 16px; }

Screenshot taken from my laptop with html { font-size: 14px; }

Font-size used on getbootstrap.com

It seems that they look at the browser setting and use 1rem as font-size.

I would approve this PR only if the reduction of the base font-size by .0875rem is removed.

Use Google to search for minimum font-size

the default font-sizes set by browsers

Which makes sense for displaying blocks of content. This is not. Better to compare with similar ui

Text should still be readable and 14px is considered rather small these days.
A font-size from 16px up to 20px is considered normal these days.

even on this fancy pancy dashboard the default font-size is set to 1rem.
https://demos.creative-tim.com/material-dashboard/examples/dashboard.html
https://demos.creative-tim.com/material-dashboard-pro/examples/dashboard.html

Github: 14px
issues.joomla.org: 14px
Gitlab: 14px
Bitbucket: 14px
AWS: 10px
office.com: 14px
myaccount.google.com: 14px

I stick to evidence not feeling

I can play that game too @brianteeman

https://www.cloudflare.com/ : 16px
https://runcloud.io/ : 16px
https://slack.com/ : 16px
https://www.w3.org/WAI/standards-guidelines/wcag/ : 16px
https://www.mozilla.org/ : 16px
https://developer.mozilla.org/ : 16px
https://www.gov.uk/ : 16px

and the list of both of us can be continued by the both of us.
please don't decrease the font-size to 14px

Still waiting for the reason

And to repeat what I said before and gave examples for. Font sizes suitable for walls of text on frontend sites are not the same as in the UI of an admin interface

The reason is readability. Specially on mobile devices.
Instead of 14px the font-size of 16px is the norm. Even on admin interfaces.

If your text inputs have a smaller font size than 16px , iOS browsers will zoom in on the left side of the text input, often obscuring the right side and forcing the user to manually zoom out after using the text box.

I must be really stupid then as I have never seen that with joomla 3 which has an input size of 13px

@hans2103 Please actually test the PR
I understand your objections are

1. its changing the base font to 14px (it is not)
2. its changing the input size to less than 16px (it is not)

this is NOT changing the default font size at all. It is only setting a variable that is used to calculate the font size in SOME classes

I would be happy to merge this pr, adding an option to set the basesize per template or per use can be added later. Also the default fontsize can be changed if needed. AdminLTE v3 uses 1rem but anyway I like the 14px but that doesn't matter.

It can be changed in a later pr or could be done more flexible in the user profile if someone writes a pr. Now we need some tests.
@brianteeman can you merge the latest 4.0-dev branch into this pr, thanks

As requested branch updated.

@HLeithner

I would be happy to merge this pr

Looks like you may not have fully seen the consequences I posted above concerning the ratio obtained when x * less than 1 (#31207 (comment))

Not only line-height would have to be modified in many places but some stuff becomes unreadable.
Example for Quickicons

Sample data description is even worse

Articles manager

I disagree with all your examples being wrong. They all look great to me

They all look great to me

For your eyes only.

I can play that game too @brianteeman

https://www.cloudflare.com/ : 16px
https://runcloud.io/ : 16px
https://slack.com/ : 16px
https://www.w3.org/WAI/standards-guidelines/wcag/ : 16px
https://www.mozilla.org/ : 16px
https://developer.mozilla.org/ : 16px
https://www.gov.uk/ : 16px

and the list of both of us can be continued by the both of us.
please don't decrease the font-size to 14px

Backend for admins, not frontend for mobile users... never see a backend with all useful content with more than 14px.
Slack use 15px fot the chat, but with the font Stack-Lato that is a "big" font. PX are not "important" if we don't speak about font family. Joomla use Roboto that is a font made for been readable from 8px to Npx.

Not only line-height would have to be modified in many places but some stuff becomes unreadable.
Example for Quickicons

For me are perfectly readable on a FullHD 1920x1080 notebook with 15" lcd. Considering that the medium size of FullHD monitor are 22" to 24" and the most diffused resolutions in the world are lower that a FullHD.
A label under a icon must have a size lower than font size of < p >.
Remember that we are speaking about a backend, we can't compare to Frontend's "best practice".

ASANA, Trello, Hubspot, Mailchimp, Salesforce or other CMS like WP, Drupal, etc (that everyone need to know a little before "coding" a good UX in a CMS backend) use 13px/14px fonts not only for the UI but for core contents too.

Why reinventing every time the wheel? Is it so hard to follow who made better thing?
And please, stop confusing admin UI with Frontend UI. Stop comparing fonts in "Joomla Dashboard" and try to compare articles list or edit view.

IMHO

As I have said, I do NOT oppose to have a basefont using the equivalent of 14px.
I have repeatedly explained that, in that case, the ratio applied to some classes make the texts concerned unreadable for many people. Yes, in backend.

I have posted a screenshot of articles views.

I use a 4096 x 2304 Retina display. Please stop comparing your eyesight with mine. Thanks.

unreadable for many people.
so far just you not many

As I have said, I do NOT oppose to have a basefont using the equivalent of 14px.

I know, it was for hans2103.

I have repeatedly explained that, in that case, the ratio applied to some classes make the texts concerned unreadable for many people. Yes, in backend.

I can understand, but... define "many" please.

I have posted a screenshot of articles views.
You yes, not hans2103
I use a 4096 x 2304 Retina display. Please stop comparing your eyesight with mine. Thanks.

Ok but this must be objective.
Resolution is not important if you not specifiy the size in inches of device and the device pixel ratio (DPR) applied by your OS.
If you are using that resolution with a 24" and Joomla doesn't know you have so high DPI, there is something to solve in Media Queries for high dpi devices.
Or it is your OS fault, if it is not applying any "device zoom". (4k monitor in monitor under 27" often scale the size of all OS elements and fonts, for example Windows 10 try to do a 125% if the monitor is FullHD and lower than 15").
If you are using this resolution with a 32" monitor at 50cm, you shouldn't have any problems with 12px too.

Anyway, you are outside the range about most used display resolutions.
https://gs.statcounter.com/screen-resolution-stats/desktop/worldwide

When this happen, a base UX setting must be made for the "many users", and only optional settings have to be made for the "few users".
So 14px (normalized) for 95% of 2020's web users, a settings to have bigger font for other few user.

I really don't see the point of most of this pr. If you want the base font size to be 14px then simply set font-size-base: 14px. DONE.
rem will change based off of that.
there's no need to recalc something thats already done. These 2 statements are identical

$badge-font-size:                  .75rem;
$badge-font-size:                  calc(var(--font-size-base) * .75);

if you REALLY wanna force a base font size then do
:root {
font-size: 14px;
}

@simbus82 lets look @ the chart you provided properly...

This shows that 40% AND GROWING are using high dpi displays. Most likely 4k. This is a growing trend not some oddball qwerk.
on small dpi devices 14px would be hard to read. Which also is becoming the norm.

so, by your own arguments we MUST use a base size of 16px. NOW, having said that I'm sure browser companies have spent a vast fortune on figuring out the best font size for the majority of situations. That size is an industry standard 16px!
If your really that split on 14 vs 16 then the simplest fix is to make it a param. Changeable on a per user basis. You could even go a step farther and make it a question during install. Leave the default to 16 ( aka auto ) and the optional size to 14.

Lastly the largest majority of people are over 50 so don't have the vision they might have once had. https://blog.aarp.org/notebook/top-10-demographics-interests-facts-about-americans-age-50#:~:text=There%20are%20108.7%20million%20folks%20age%2050%2Dplus.,for%20the%2018%2D49%20population.
Also its a medical fact that larger print is easier on the eyes! This means for people who spend a large amount of time in front of a computer screen larger font will help prevent headaches, stress & fatigue!

pr need label ´conflicting files´.

if you REALLY wanna force a base font size then do

That is not what the PR does as I have repeatedly said