User tests: Successful: Unsuccessful:
Pull Request for Issue #23516
Removed @import url('https://fonts.googleapis.com/css?family=Fira+Sans:400');
from https://github.com/joomla/joomla-cms/blob/4.0-dev/templates/cassiopeia/scss/blocks/_global.scss#L3
Added HTMLHelper::_('stylesheet', 'https://fonts.googleapis.com/css?family=Fira+Sans:400');
to https://github.com/joomla/joomla-cms/blob/4.0-dev/templates/cassiopeia/index.php
Status | New | ⇒ | Pending |
Category | ⇒ | Administration com_media Front End Templates (site) |
@hardik-codes do you understand what needs to be changed here?
@dgrammatiko I'm able to comprehend point 1 and 2 but I need your help in point 3
@hardik-codes go on with those changes and we will patch the rest later on...
Title |
|
Title |
|
Labels |
Added:
?
|
@dgrammatiko please review the changes I've made.
- We have tools that can parse the google servers get the css and append it directly in the template css (eg 1 http request less).
Which tools are that?
Our npm build tools
@dgrammatiko lol clearly I'm missing something, can you provide more details or a link please?
@dgrammatiko ok, wasn't aware you were simply referring to cdn.
As to build.js I've looked but clearly need to look alot more. There is a LOT going on there.
There is a LOT going on there.
Not really just the entire front end...
@dgrammatiko please let me know where the PR is not working, so that I can fix it
@hardik-codes read my last 2 comments...
@hardik-codes Basically remove your <link ....>
and replace with:
HTMLHelper::_('stylesheet', 'https://fonts.googleapis.com/css?family=Fira+Sans:400', array('version' => 'auto', 'preload' => array('preload')));
I never use the preload manager, so I'm not sure if it automatically adds as="font"
, but if not, you may also have to add it to the first array.
The Document
class doesn't support passing attributes for links into the PreloadManager
class if you're adding the preload flag as part of a Document::addScript()
or Document::addStyleSheet()
call (if someone wants to improve this API bit that'd be nice). So if you want to specify attributes, you should NOT pass the preload
flag when registering an asset and do 2 function calls, i.e.:
HTMLHelper::_('stylesheet', 'https://fonts.googleapis.com/css?family=Fira+Sans:400', array('version' => 'auto'));
// If not in Document scope, use Factory::getDocument() instead of $this
$this->getPreloadManager()->preload('https://fonts.googleapis.com/css?family=Fira+Sans:400', array('as' => 'font'));
BTW you cannot preload a css file as font, this will break badly
@dgrammatiko Ah yes, right you are. I forgot they imported the font through the CSS file
Personally I'd copy the CSS that you require and preload the font file instead.
I'm quite confused after so many comments, so please can anyone tell me what is to be done finally to improve the PR
just add:
HTMLHelper::_('stylesheet', 'https://fonts.googleapis.com/css?family=Fira+Sans:400', []);
// Preload the stylesheet for the font, actually we need to preload the font
$this->getPreloadManager()->preload('https://fonts.googleapis.com/css?family=Fira+Sans:400', array('as' => 'stylesheet'));
For now.
The correct approach here is to ditch the Google served fonts
$this->getPreloadManager()->preload('fonts/the_name_of_the_font.woff2', array('as' => 'font'));
- the name is changing in every release
Am I missing something here. Google doesn't change font names
@brianteeman not the name of the font-family in the css but the name of the file that corresponds to that:
@dgrammatiko thanks for the explanation
@dgrammatiko now have a look.
Found this great explanation https://medium.com/clio-calliope/making-google-fonts-faster-aadf3c02a36d
@brianteeman I just read that, so the best option is to self-host the font. Also that's better for Joomla because it means the template will render correctly in localhost without internet connection (eg developing)
The font, by the way, exists here: https://github.com/mozilla/Fira
Except for this comment at the very end
In addition, very popular fonts like Open Sans and Roboto are likely to exist in your users’ cache.
In which case there is no download at all.
@brianteeman but we're using Fira not Open Sans or Roboto. Also assumptions are the best way to fail on performance
Can we please deliver a complete cms without external dependencies.
@HLeithner seriously?
Any cms is dependent on a million things
Every cms needs google or any other cdn to work?
Maybe I'm an idiot then, because none of the websites I created has externel dependencies if possible.
It's 2019, why do templates still have to be built with "non-standard" fonts that must be delivered by extra HTTP requests instead of building font stacks that get progressively enhanced based on what the end user has installed locally (see the font stack used in the WordPress admin as an example, or here on GitHub, or Twitter, or one of a plethora of other services that have decently up-to-date UI standards and are not relying on serving some extra font files to an end user)?
Or, let me put this in another way, since I just re-checked something I'm rebuilding and I'm shipping a couple of fonts related to the project's branding efforts.
What in Joomla's branding is enhanced by Roboto or Fira Sans or any of the other fonts that have been proposed for the 4.0 stack (I'll even be annoying enough to take it to the use of whatever fonts we're pulling for the 3.x templates)? AFAIR the only font in the project branding guidelines is Asenine Wide for the actual name when used with the logo, there aren't supplemental fonts suggested for use meaning everything font related is entirely subjective. Is it not possible to build "modern" interfaces using only system fonts, or is the issue that it might be too big of a maintenance burden to use a progressively enhanced font stack like -apple-system,BlinkMacSystemFont,Segoe UI,Helvetica,Arial,sans-serif,Apple Color Emoji,Segoe UI Emoji,Segoe UI Symbol
(GitHub's)?
I'm sorry for abuse this issue for this discussion, its not the right place. Maybe an own issue would make more sense.
I'm font blind (or what every you want to call it) so I don't care about the font but I'm a programmer and not a designer so for me the system fonts are good enough and don't call home to google or other 3rd party data miners (I know the data protection is not a thing everyone share).
This PR is about satisfying the designers choice of font while mitigating any resultant performance impact. Any discussion about the choice of font, font provider or font-stack is really off topic here and I would suggest it is taken up with the template group in their private repo - if you are lucky enough to have access.
Then this PR and any potential of discussion is a waste of everyone’s time
because that repo has pulled in Roboto as the template font and the
designer has already made clear in a past PR on this repo there’s no
backing down from requiring a non-system font.
On Fri, Feb 15, 2019 at 3:56 PM Brian Teeman notifications@github.com
wrote:
This PR is about satisfying the designers choice of font while mitigating
any resultant performance impact. Any discussion about the choice of font,
font provider or font-stack is really off topic here and I would suggest it
is taken up with the template group in their private repo - if you are
lucky enough to have access.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#23682 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAWfoWMJ9SoTmaij9H7Crs0S3T_Nboy7ks5vNy0qgaJpZM4aUUFz
.
--
I totally disagree with the idea of having a font (other than the system ones) in the backend template. Actually, that's ridiculous and it should never pass from the production team (the limitations are far greater than any possible gains if any).
For the frontend, tho, I guess the idea is to showcase how a web font is correctly used in the CMS, and that is not pulling it from a CDN...
@mbabker and @brianteeman I think what Harald means is that on a pageload the core CMS shouldn't call external ressources from a CDN or whatever.
Of course it's fine to build the CMS with external ressources during the build process. And of course you can do in your template or extension whatever you want.
But given with latest data protection regulations and Firewalls/Proxy in corporate networks I would be very hesitant to have a core template which by default loads eg a font from Google CDN. It has to be self-hosted.
I'd agree a bit more if we were talking about the admin template. The frontend template IMO is less of an issue to use a CDN with. But, as I was ranting about, you don't need to include extra font downloads in your template if you don't build a template using non-system fonts (which, OK, for the frontend template if you want to get opinionated on this then cool, that can be and in most cases is replaced by the user anyway).
I have tested this item
work as descriped
I have tested this item
works as advertised
Status | Pending | ⇒ | Ready to Commit |
RTC
Labels |
Added:
?
|
Category | Administration com_media Front End Templates (site) | ⇒ | Front End Templates (site) |
Status | Ready to Commit | ⇒ | Fixed in Code Base |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2019-11-28 14:55:37 |
Closed_By | ⇒ | wilsonge |
Thanks!
@hardik-codes couple of comments here:
You removed one TODO item by removing the import in the scss file. The idea back in the day was, (I think I put that comment there) to get an API for lazy loading fonts. Of course from the day that TODO was written quite a few things have changed in the repo. Particularly @mbabker introduced another API for
preload
, thus the JS API might be disregarded, but...You absolutely have to preload the fonts using the preload manager. Essentially you need to have in the head a tag like:
<link rel="preload" href="font.woff" as="font">
. For more info (in case you're not familiar) check: https://developer.mozilla.org/en-US/docs/Web/HTML/Preloading_contentOnce you've preloaded the required fonts, you only have to get some css to do the linking between the page elements and the font. This shouldn't be another css file (as you're doing it right now). We have tools that can parse the google servers get the css and append it directly in the template css (eg 1 http request less).
So, to conclude here: use link preload and embed the css in the template using the Joomla build tools is the best approach here. Your approach although it improves things a bit, is far away for the ideal/possible in Joomla 4