I have a website that is using Angular material. I like elements and everything except default font sizes and elements are huge. To see website in acceptable scale me or my users have to zoom out at least 75% on the desktop and majority of my users are desktop users. Is there a way to specify in angular material to use smaller fonts, elements, etc?
in your main css file
add following
html {
font-size: 62.5% // adjust the size with percentage here.
}
and i recommend using em and rem for font-sizing
let me know if it didn't worked, i might provide another solution
Before you attempt anything, make sure you are using the correct fonts and font sizes by following the typography guide.
Font sizes can be adjusted by customizing the typography. Changing the size of elements is technically possible, but to do it you would need to override the styles for every Angular Material component - so it is highly impractical.
Also, component sizes as well as font sizes are determined by the Material Design specifications, so changing things means you are no longer properly following the specification, and IMO you would end up with a bad looking web site (at least bad looking in terms of following Material Design).
Related
I'm optimizing the speed of a WordPress website (on mobile only for the moment), with success except for CLS. The CLS became extremely high after optimizing CSS delivery (with WP-Rocket), but I don't see any layout shifts, even when I use Dev Tools (performance test). (on mobile)
Here’s the example : https://trustmyscience.com/israel-a-pratiquement-eradique-la-covid-19/
Results here, with CSS delivery optimization
So it seems to be an invisible layout shift, that Lighthouse perceive as a real layout shift. Lighthouse shows me the problem comes from <div class="entry-content body-color clearfix link-color-wrap progresson">. So, it seems to be related to some "wrapping" of the all article content, that maybe shifts into the background (without being visible), because of some CSS rules maybe ?
Here, the element with the highest layout shift
The element with the highest layout shift (detail)
When I deactivate CSS delivery optimization, CLS go back to almost 0 (but LCP is too high).
Results WITHOUT CSS delivery optimization
I need this CSS delivery optimisation because of LCP importance, but I also now need to solve this issue because of CLS introduction in Core Web Vitals, and need to find what Lighthouse is detecting as a LS. Also, maybe, Lighthouse needs a correction for that ? As it isn't a visible layout shift...
Do you have any idea on how to solve this ? Or do you think I need to reach LS developers to show them this ?
Thank you in advance for your help.
Regards,
The CLS is visible, it's the font.
Don't you notice that when you visit the page, the text gets resized? That's a common cause of CLS.
How to solve?
Serve your fonts locally. Do not use any plug-in like OMGF. Do it manually.
Download the fonts. Choose 2 fonts, one for body, another for headings. You won't need bold, italic, or bold+italic fonts. These will be applied by user's browser.
Convert to woff2 (only woff2 is enough, didn't face any issues)
Upload it to your server
Add font face CSS to declare the fonts
Apply the fonts using CSS elements
Disable Google fonts if you're using any WP theme or builder
Preload the fonts
This will solve the CLS problem, will also reduce the Total Blocking Time.
You might gain a bit in performance by self-hosting the fonts instead of making a call to the Google Fonts API, but fonts are not the main issue here. Javascript is.
There is a lot of Javascript on this website, so the main thread is busy downloading it, parsing it and executing it.
I ran both Lighthouse (with Clear Storage and Simulated throttling enabled) and WebPageTest with a Moto 4G profile.
As you can see from Chrome DevTools and WebPageTest, roughly 56% of the processing time spent on the main thread is due to scripting. Do you really need all of that Javascript?
Here is what I noticed in the Chrome DevTools Performance panel:
There seems to be 5 front-end.js scripts (and 1 min-front.js). Are they duplicates?
Do you need animations with gsap and ScrollTrigger?
Aren't lazyload.min.js and areimagesloaded.js doing the same thing? (I might be wrong)
Are you importing the entire lodash library? If so, try importing just the functions you are actually using.
Do you really need a polyfill for Intersection Observer? I think that all modern browsers support it natively nowadays.
CLS is basically the sum of all unexpected layout shifts that occur on a page. As you can see from the dashed orange line in the chart below, the 4 .woff2 font files contribute to the CLS: the first layout shift occurs as soon as the fonts are fetched.
But as I said, I would focus on removing all unnecessary Javascript. In particular, I would examine third-party JS like the one coming from choices.consentframework.com, which takes 1730ms to load and represents 25% of the content size (see below).
After JavaScript, focus on the images.
The Performance panel in Chrome DevTools shows a lot of requests for images. Are you fetching only the images that are in the viewport, or all the images that are on the page?
Most of these images are WebP and seem already optimized, but there are a few GIFs, which are really bad for performance. It seems that these GIFs are served by https://www.viously.com/ (I guess it's an Ad Server, it's the first time I see it).
Last but not least, double-check that all of your <img> and <video> have size and width attributes set. Images and videos are replaced elements with intrinsic dimensions, and forgetting to set sizes for images in your HTML is a common cause of layout shifts.
See also this article by Addy Osmani for a few more tips on how to optimize CLS.
I am working on an Angular Application with Angular material. I noticed that there are subtle differences between the two. Especially in the inputs. Is that on purpose? Can I get them the same by some Configuration? Here one example what I mean.
vs
Paddings & Margins are different
MD has a border radius that AM not has
I know it doesn't seem much, but i would really like to get the look equal.
I am using the most excellent PHP library ePub to on-the-fly create digital books from HTML stored in my database.
As these are part of a collection, I am including a cover image for every book. Everything works fine in the code but depending upon the device/software interpreting the ePub, the image may get cut off. I have seen 600x800 pixels as a recommended size, but it still cuts it off (for example in Aldiko in Android). Is there a standard size that is recommended in the documentation?
Honestly, I would love a good and readable recommendation for documentation of the ePub format.
So, it seems that Aldiko has the problem, and not the other e-Readers I have tested (Calibre, Overdrive).
After trying various ratios, I found that Aldiko only respects the height:100% style I have called out in the height direction. It doesn't scale the image, only sets the height at 100% of the screen width. I am going to have to go with this being a bug in Aldiko, and keep the recommended 600x800 ratio for maximum resolution.
Another interesting thing I discovered as well; the Aldiko reader didn't recover as well from non-standard HTML. On one of the database entries, a <style> tag inside the <body> disappeared, but the style text did not. This is not the same for the other e-Readers.
The best general advice I found on the internet is Preparing Images for Ebooks Project (PIFEP).
I am looking for a way to use css and viewport properties to force one div of formatted text content to take up exactly the screen width, regardless of the user specified zoom. Something like the reflow functionality some pdf readers have. I'd prefer not to use javascript.
Is that even possible? I am targeting the BlackBerry browser specifically.
Can't tell about Blackberry browser specifically, but here's a bit of general considerations:
Don't give your page fixed width, except maybe 100%; check on an actual device.
Don't measure things in pixels (except raster images), use pt, em and % where possible.
Be careful with floats and absolute-positioned things.
I use a non-default Windows colour scheme on most of my machines, and have a laptop with a 124 DPI screen, which Windows is set to.
A lot of programs I tested or even use daily seem to have problems with that, showing for example non-standard sizes of controls, cut-off UI elements, unreadable text and so on. There is the whole range from slightly annoying to (nearly) unusable.
Now I feel that a lot of these issues are unnecessary. A simple test run on a high-resolution screen in a few colour schemes would show them, some of them are even very easy to correct (like always using clWindow, clWindowText and clBtnFace instead of clWhite, clBlack and clSilver). Some of them are harder, like proper control sizing.
So my question is: Do you try to follow the recommendations in the UI guidelines regarding system colours, sizing and spacing of UI elements, and font sizes and faces? Is testing for compliance to them part of your QA process? Do you even try to lay out your forms in dialog units instead of pixels, even though most of the IDEs (Delphi in my case) have pixel-oriented designers?
[EDIT]: On re-reading this after sleeping I notice that this question may look like an invitation for fruitless discussion. It is not meant that way, I'd definitely be interested in tools to help me create applications that conform to the UI interface guidelines, an area where I feel Delphi is letting me down a little. See also my own answer.
I definitely don't. It costs time that I prefer spending on improving the experience of many rather than the few who use non-standard windows settings. A few things I usually do, which should still fix some of these issues:
use clWindows etc. because that's the standard for Delphi controls anyway, so why change it?
place labels above entry fields rather than to the left, which should solve many size problems
make sure the forms resize properly, by setting the anchors
make sure the tab order is correct (which can become a major annoyance if not done)
But I certainly don't take the time to set up test computers with odd resolutions and colors, or even worse, change my development box to use them (which will screw lots of things that again take time to reset properly).
If a paying customer reports problems with non-standard settings, it depends on the customer whether they will be addressed. If he orders 100 licenses, his chances are good. If he uses these settings because he is visually impaired, his chances are good. If he makes it part of the requirement, I will do it, but charge for the additional work.
Today, so much software doesn't work properly at a non-standard DPI that I don't think it's worth trying to fix it. The trouble-shooting FAQs for many applications just instruct users to switch to a normal font size for related problems. Microsoft acknowledged lack of proper DPI support in 3rd-party software and redesigned the display scaling methods in Windows Vista, where all GDI operations are scaled on a low level instead of relying on applications being aware of the DPI setting.
Final answer: it depends on your software's audience. If your software is likely to be used by disabled users, it might be worth the effort.
Apart from using the proper colour constants for standard colours I invest some extra effort for applications that we need to use internally on high DPI screens, or where customers may need this.
I have a unit with helper functions for determining proper sizes and placement margins, which compute these from the default GUI font and the standard values in dialog units as given in the UI guidelines, and with helper functions to compute the maximum width / height of an array of controls, place controls, things like that. For fixed size forms and dialogs I calculate the placement of controls once after translating their text with GNU gettext, for resizable forms I do this in an OnResize handler.
This gives good results, is however time-consuming. I would like to have something like the wxWidgets sizer functionality, which automates resizing once the minimum size of a control is set. I have never seen something similar for Delphi, though.
I occasionally test it myself for large fonts, because my Vista laptop is set to Large Fonts. Colors, not so much, but I rarely specify colors on controls.
However, proper resizing is pretty hard. I usually set Forms scale to false, so as that they won't resize wrong.
There are a few tools for auto-resizing forms. I did look into them, but never got around to testing them properly:
TFormResizer
ElasticForm - ironically (given the component's area) most of the text in this page won't show up in Chrome...
JVAutoFormSize (in JVCL - doesn't seem to be very useful from what I read)