{"id":857,"date":"2024-07-02T12:02:37","date_gmt":"2024-07-02T12:02:37","guid":{"rendered":"https:\/\/www.yellowfalconmedia.com\/blog\/2024\/07\/02\/modifying-css-in-wordpress-theme-cms-wordpress-sitepoint\/"},"modified":"2024-07-02T12:02:37","modified_gmt":"2024-07-02T12:02:37","slug":"modifying-css-in-wordpress-theme-cms-wordpress-sitepoint","status":"publish","type":"post","link":"https:\/\/www.yellowfalconmedia.com\/blog\/2024\/07\/02\/modifying-css-in-wordpress-theme-cms-wordpress-sitepoint\/","title":{"rendered":"Modifying CSS in WordPress theme – CMS & WordPress – SitePoint"},"content":{"rendered":"

Discussion continued from W3C validator reliability? – #31 by Archibald<\/a><\/em>
As the errors do not seem to be affecting the appearanc
Could they be affecting the performance or SEO of the page?
I have a problem with the text displayed in the article post. In the CSS, I\u2019ve included these styles to format it by default, but on its desktop version, the text appears very small. Is there any other element in the stylesheet preventing the text of the last post from appearing like the penultimate one without the need for inline CSS, giving it the same size and default justification? [Link to stylesheet<\/a>]
Could they be affecting the performance or SEO of the page?
Analysing your web page with Lighthouse within Google Chrome\u2019s Developer Tools gives an excellent rating of 99\/100. It is picking up that, for mobile width pages, the \u2018search this site\u2019 input element is overlapped by the magnifying glass graphic, both being interactive elements. It is not picking up any other SEO issues.
Is there any other element in the stylesheet preventing the text of the last post from appearing like the penultimate one without the need for inline CSS, giving it the same size and default justification?
You can use Developer Tools to inspect text (and other elements) Select the left-most icon on Developer Tool\u2019s toolbar then hover over the text you wish to inspect. If you then click on selected text you will be able to see where the text gets its CSS from. I note in desktop view that the text listing the characteristics of the camera appears rather small. Develop tools shows font-size: 1.2em<\/code> in this file:
https:\/\/www.fotov60.com\/wp-content\/litespeed\/css\/5dcb158dce52540584d3bae115f63f3c.css?ver=bf25a<\/a>
and Developer Tools shows that computes to be 12px.
I am picking up that this file is not available:
https:\/\/www.fotov60.com\/wp-content\/themes\/web%20fonts\/orkney-regular-webfont.woff<\/code>
(note the space character is invalid in a URL and has been replaced by %20).
There is a really staggering amount of CSS: in five files (I think) and inline. Your blog could be styled with a tiny fraction of this CSS if coded without WordPress.
There is a really staggering amount of CSS: in five files
That\u2019s why I left the direct link to the original CSS https:\/\/www.fotov60.com\/wp-content\/themes\/fotov60\/style.css?ver=4.4<\/a> because Litespeed minified and chunked it to optimize it for site speed, making it hard to view the content correctly. In the link at the end of my previous post, you\u2019ll find the single CSS file instead of the 5 created by Litespeed, allowing you to see all the styles applied at once. If not, using Developer tools directly on the already optimized website can be confusing regarding the origin of the CSS.
I am picking up that this file is not available:
https:\/\/www.fotov60.com\/wp-content\/themes\/web%20fonts\/orkney-regular-webfont.woff<\/code>
To fix the font issue, would you recommend changing the folder name containing it to \u2018webfont,\u2019 without spaces, to avoid this problem?
Your blog could be styled with a tiny fraction of this CSS
Once the text issue is resolved, I\u2019d like to reduce the size of this file, but I\u2019m unsure where to start as it handles presenting the mobile view of the WordPress theme, and I\u2019m afraid of breaking it.
You can use Developer Tools to inspect text
If I want to be able to use Developer tools directly, I have to enter this other URL https:\/\/www.fotov60.com\/?LSCWP_CTRL=before_optm<\/a> to prevent Litespeed\u2019s work on the CSS, and then truly see where each element comes from, as I mentioned in my previous post, it\u2019s in that CSS stylesheet I shared the link to. The issue is that I don\u2019t know what to modify to make it look as I expect, as I thought I was doing it right, and apparently something interferes with the final result.
That\u2019s why I left the direct link to the original CSS
I was referring to the staggering amount of CSS used by your online web page, although it is a fairly simple web page.
To fix the font issue, would you recommend changing the folder name containing it to \u2018webfont,\u2019 without spaces, to avoid this problem?
I think my browser and your server are taking care of the space character in the URL (by using URL encoding). Is orkney-regular-webfont.woff<\/code> file in that folder on your server?
The issue is that I don\u2019t know what to modify to make it look as I expect, as I thought I was doing it right, and apparently something interferes with the final result.
Please give the location of an example of what you are wanting to modify and what modification you wish to make.
Is orkney-regular-webfont.woff<\/code> file in that folder on your server?
Here is a screenshoot of cpanel, showing the folder and the fonts in it.<\/p>\n

\"fonts<\/p>\n
<\/use><\/svg>fonts url<\/span>720\u00d7691 120 KB<\/span><\/use><\/svg><\/div>\n

<\/a><\/div>\n

Please give the location of an example of what you are wanting to modify and what modification you wish to make.<\/p>\n

\"blogexample\"<\/p>\n
<\/use><\/svg>blogexample<\/span>749\u00d7572 191 KB<\/span><\/use><\/svg><\/div>\n

<\/a><\/div>\n

This is an example of how I would like the text to look. I think I\u2019ve already achieved it with the headings, but with the rest of the text is where I encounter problems. I managed to style the example text through inline CSS, but what I\u2019m interested in is that it is well defined in my CSS stylesheet so that inline styling is not necessary. The latest post visible on my blog is the one to which I haven\u2019t applied any inline styles, and it doesn\u2019t display correctly. To view its CSS correctly through Developer tools, you need to visit the blog through this link https:\/\/www.fotov60.com\/?LSCWP_CTRL=before_optm<\/a> to prevent the Litespeed plugin in WordPress from modifying the CSS.
Is Orkney a good choice for titles and texts, or is it better to use Raleway for the text?
I was referring to the staggering amount of CSS used by your online web page, although it is a fairly simple web page.
It\u2019s possible that there are duplicated parts and\/or disordered code, but a freelance developer added responsive functionality through CSS to a theme I was using before and wanted to keep. I had previously \u201cfixed\u201d small issues I had come across. Can you think of a way to streamline the code without the risk of \u201cbreaking\u201d something?
At the moment, I\u2019ve identified some things that I believe I don\u2019t use on my blog. If you can confirm that I can safely delete them, I would appreciate it.
Here is a screenshoot of cpanel, showing the folder and the fonts in it.
Font family \u2018Orkney\u2019 is being used OK, so I wonder if file orkney-regular-webfont.woff<\/code> is corrupt in some way. At least it does not look like the space in the URL is causing the issue.
This is an example of how I would like the text to look.
On your Hasselblad blog, Developer Tools (I\u2019m using Firefox) is showing the text to be \u2018Orkney\u2019 (as \u2018orkneyregular\u2019 has failed to download), 0.875rem (=14px), rgb(51, 51, 51). This is declared in lines 302 to 307 in style.css, with the color declared as a default for the body on line 34.
The text in your screenshot above seems to be 20px (=1.25rem) and may be black, not dark grey . . . . as far as I can tell from the screenshot.
Is Orkney a good choice for titles and texts, or is it better to use Raleway for the text?
When looking at any website, I usually take no notice of what the text looks like. Perhaps that is just a personal thing and that I am not very observant. I think many website designers pay much too much attention to appearance details and often not enought attention to text content, image content and navigation. Reading your blog, I would not have been aware that the text is anything other than ordinary sans-serif.
As mentioned a while ago, I am surprised the subheading text of your blog appears in a larger font than the main heading text.
Can you think of a way to streamline the code without the risk of \u201cbreaking\u201d something?
Reducing some CSS is going to make no noticeable difference. Even though style.css alone runs to 2490 lines of code, your total CSS (not only style.css) is only 8.2% of your page load size (with Litespeed).
The text in your screenshot above seems to be 20px (=1.25rem) and may be black, not dark grey . . . . as far as I can tell from the screenshot.
You can view the content of the screenshot directly on the blog in the second post on the main page to see its actual relative size. I don\u2019t think inline CSS would be very useful for determining its size since it\u2019s only defined as <p class=\"has-text-align-justify has-medium-font-size\"><\/code>, and I can\u2019t find its equivalent in em or rem.
the text to be \u2018Orkney\u2019 (as \u2018orkneyregular\u2019 has failed to download), 0.875rem (=14px), rgb(51, 51, 51).
The CSS you mention is the following, right?
What do I modify in them to make it correct?
At least it does not look like the space in the URL is causing the issue.
I think you\u2019re right about this, because otherwise, the rest of the fonts wouldn\u2019t load being in the same folder, right? Maybe the best option is to remove that font and its loading in the CSS? With the Orkney font available in all other formats, I can do without orkneyregular, which is in WOFF format, I believe.
Speaking of fonts, is it good to load bold, italic versions, etc\u2026 or is the regular version enough?
I don\u2019t think inline CSS would be very useful for determining its size since it\u2019s only defined as <p class=\"has-text-align-justify has-medium-font-size\"><\/code>, and I can\u2019t find its equivalent in em or rem.
The class has-medium-font-size<\/code> is defined, via a CSS variable, in line 92 of the HTML. It is a long line \":grinning:\". Here are the CSS variables for font size in that line.
--wp--preset--font-size--small: 13px;--wp--preset--font-size--medium: 20px;--wp--preset--font-size--large: 36px;--wp--preset--font-size--x-large: 42px;<\/code>
Note the declation includes the !important rule:
.has-medium-font-size{font-size: var(--wp--preset--font-size--medium) !important;}<\/code>
The CSS you mention is the following, right?
Yes, I was mentioning the p {....}<\/code> declaration on lines 302 to 307.
Using vw<\/code> units might be a better option to achieve a responsive result?<\/strong>
Yes, I was mentioning the p {....}<\/code> declaration on lines 302 to 307.
Then I must modify like this?
Can I combine the styles of <body><\/code> and <p><\/code> into one, or do they each belong to a different element? If yes, how would it look?
Once these changes are made, can I remove the inline CSS from the example post?
As mentioned a while ago, I am surprised the subheading text of your blog appears in a larger font than the main heading text.
Do you check in dev tools or is only at eye checking?
In principle, you can see that the titles are defined with descending sizes, unless another rule is affecting them.
Can I combine the styles of <body><\/code> and <p><\/code> into one, or do they each belong to a different element? If yes, how would it look?
I suggest you keep that CSS. The body declaration acts as a \u2018default\u2019 for your whole web page. However I think Sans-Serif should be sans-serif.
Do you check in dev tools or is only at eye checking?
I noticed that by eye.
In principle, you can see that the titles are defined with descending sizes, unless another rule is affecting them.
Your blog title and your subheadings are all <h2><\/code> elements (Hasselblad blog at least).
Developer Tools shows the blog title is 28px while the subheadings are 33.6px.
<h2><\/code> has font size 2.8em which means that it is 2.8 times the size of the font size of its parent element. The parent element is <div class=\"entry\"><\/code> which on llne 148 of style.css has a font size of 1.2em. So this is 1.2 times the size of its parent element. The parent element\u2019s font size comes from the font size of the <body><\/code> on line 29 of style.css. The body font size is declared as 62.5% so that means it is 62.5% of the default browser font size which is usually 16px. So working that out the font size of your subheadings will be:
16px x 62.5% x 1.2 x 2.8 = 33.6px<\/code>
This is how Developer Tools in Firefox shows it:
\"subheading-font-size\"
The font size of your blog title will be the same except that it is not within <div class=\"entry\"><\/code> element so is only:
16px x 62.5% x 2.8 = 28px<\/code>
<div class=\"entry\"><\/code>
Is it necessary, or would deleting everything make more sense by not including that multiplication you mentioned?
Using vw<\/code> units might be a better option to achieve a responsive result?
What do you think? The VW units don\u2019t depend on a parent element, so there\u2019s no need to fear those \u201crecalculations,\u201d and all screens would appear the same by adjusting based on the resolution, right?
Especially as you are concerned about SEO, you could make all your sub-headings <h3><\/code>? But would that mean editing all the blogs on your website?
If you do not want to make your sub-headings <h3><\/code> then we could use CSS:
.entry h2 {font-size: 0.6em;}<\/code>
. . . . to select <h2><\/code> elements within <div class=\"entry\"><\/code> to reduce the size of sub-headings (some other value of em<\/code> could be chosen). That will not affect main blog headings as they are not within that <div><\/code> element.
That would need to go somewhere after line 349 of the style.css file so it is not ovewritten by the declaration on line 349.
Using vw<\/code> units might be a better option to achieve a responsive result?
em<\/code> units are being used so site visitors with poor eyesight can enlarge all the text by changing their browser\u2019s default font size from the usual 16px. You don\u2019t want font size to be proportional to browser window width.
to select <h2><\/code> elements within <div class=\"entry\"><\/code> to reduce the size of sub-headings (some other value of em<\/code> could be chosen). That will not affect main blog headings as they are not within that <div><\/code> element.
If I understand you correctly, then I would need to do the same with the rest of the headers to maintain proportion, right? h3, h4, h5\u2026 etc.
Or alternatively, convert the post titles to h1? But I\u2019m unsure of the SEO impact\u2026 If my calculations are correct, the size would be 16px x 4.8 = 72px as it\u2019s currently defined. Maybe it\u2019s too large? The current H1 is only applied to the blog logo.
Or alternatively, convert the post titles to h1?
I note that your blog title and its subheadings are <h2><\/code> elements. I have therefore taken another look at the RNIB<\/a>, GOV.UK<\/a> and BBC<\/a> websites as they will be taking extra care in the use of <h1> <h2><\/code> etc elements for blind users of assistive technology. On their home pages their <h1><\/code> elements contain the names of their organisations. However on other web pages the <h1><\/code> elements describe the contents of each page. I am surprised by this because a user of assistive technology reaching a page via a search engine may not be able to find out easily the name of the website they have reached.
In the circumstances to avoid having to change all subheadings, I suggest you make your blog title <h1><\/code> instead of FOTOV6.
My understanding of what is going on with your font sizes is as follows. The 62.5% makes the \u2018default\u2019 font size for your website body to be 10px. I think this has been done just to make an easier number to start with than the usual 16px browser default. So if for example some text is required at 18px it would be simply 1.8em instead of 1.125em. I guess the 1.2em has been chosen to make the default font size within each blog, excluding blog title, to be 12px (which is rather small). The <li><\/code> element on your Hasselblad blog ends up this size. Your “Posted . \u2026 ” text includes <small><\/code> so that ends up only 11px. I suggest you review all your font sizes, taking into account the multiplication involved because of the use of \u2018em\u2019 units. Make sure any changes you make do not affect your left side bar or footer.
Initially, based on the CSS, there are h2, #sidebar<\/span> h2, and .sticky h2. The first two seem to be for post header 2 and sidebar header 2, but I\u2019m unsure about the last one. Modifying h2 may not affect the sidebar ones, but while testing the appropriate size for post h2, I\u2019ve noticed it proportionally changes the title sizes. It might be the 1.2em multiplier from the parent element <\/p>\n

I\u2019ve resolved paragraph styles and font loading issues in the dev tools. Could you confirm if it looks good for you and the remaining issue is with the headers?
The <li><\/code> element on your Hasselblad blog ends up this size
I don\u2019t find the line to change the size
Your “Posted . \u2026 ” text includes <small><\/code> so that ends up only 11px
Wich one is this text?
I\u2019ve resolved paragraph styles and font loading issues in the dev tools. Could you confirm if it looks good for you and the remaining issue is with the headers?
I thought you had only the Hasselbald blog on your home page. I see you now have four blogs on your home page. As it is strongly recommended that you should have no more than one <h1><\/code> element on a web page, you should not convert post titles to <h1><\/code> as you queried in post #14<\/span>. Post titles therefore should be <h2><\/code> and subheadings should be <h3><\/code>.
Developer Tools is showing this text to be Tahoma 11px:
Posted: 25\/01\/2024 by Agusti Pardo<\/strong> in Hasselblad<\/strong><\/small>
I am surprised Lighthouse is not reporting that text and your list text as being too small for accessibility. See:
Learn about the “Document doesn’t use legible font sizes” Lighthouse audit.
I expected the <small><\/code> tag used on that line to simply make the text smaller but I see its text size and font are declared on line 472 of style.css and its colour on line 592.
I see the main text of your Hasselblad box to be Orkney 22.8px, while the main text of your nighshade and Mestre blogs is Orkney 20px and the main text of your EL TRADE blog is arial 18.6667px.
Are you expecting visitors to your website to be able to read the text in an image regarding “Comunicado publico frente oliver sinisterra . . . “?
This image become illegible on a small smartphone (here with 320px wide screen):
\"FOTOV7\"
. . . . assuming the website\u2019s responsiveness works from width of screen.
I see the main text of your Hasselblad box to be Orkney 22.8px, while the main text of your nighshade and Mestre blogs is Orkney 20px and the main text of your EL TRADE blog is arial 18.6667px.
My intention is to polish the CSS in the Hasselblad post, where I haven\u2019t used any inline styling. Once I have the correct CSS sheet for paragraphs, headers, etc., I\u2019ll gradually remove inline CSS from older posts to match the Hasselblad style. This way, I\u2019ll save a lot of code and keep it cleaner, avoiding discrepancies in fonts, sizes, headers, etc. I ask for your validation of the changes I\u2019m making to check what I can keep as valid and address anything not following the \u201ccorrect\u201d aesthetic for standardizing the style.
I thought you had only the Hasselbald blog on your home page. I see you now have four blogs on your home page.
Actually, I have about a thousand posts, but only the latest ones are displayed on the main screen. I showed you the Hasselblad post because of what I explained in the previous paragraph. The post title is an h2, the main headings within the post are also h2, and then the smaller titles are h3. That\u2019s why there\u2019s confusion when changing the size of h2.
Are you expecting visitors to your website to be able to read the text in an image regarding “Comunicado publico frente oliver sinisterra . . . “?
If you\u2019re referring to this one, clicking on the image opens the page with the document https:\/\/www.fotov60.com\/wp-content\/uploads\/2018\/04\/comunicatFARC_EP.jpg<\/a>, allowing you to zoom in. What\u2019s the issue?
This image become illegible on a small smartphone (here with 320px wide screen):
I thought I had uploaded the image for it to open the same way as in the previous paragraph. Clicking on it should open it in full size for proper examination. Thanks for the heads up. I\u2019ll correct it by re-uploading so that it behaves as I mentioned.
Developer Tools is showing this text to be Tahoma 11px
Would you change the font to Orkney, used in the rest of the text, and make it slightly larger, or would you keep it as Tahoma?
My intention is to polish the CSS in the Hasselblad post, where I haven\u2019t used any inline styling. Once I have the correct CSS sheet for paragraphs, headers, etc., I\u2019ll gradually remove inline CSS from older posts to match the Hasselblad style. This way, I\u2019ll save a lot of code and keep it cleaner, avoiding discrepancies in fonts, sizes, headers, etc.
That is helpful information.
I ask for your validation of the changes I\u2019m making to check what I can keep as valid and address anything not following the \u201ccorrect\u201d aesthetic for standardizing the style.
The aesthetic style is your choice, not mine. However I can point out where in my opinion improvements can be made. To my eyes the main issues at present remain:
The post title is an h2, the main headings within the post are also h2, and then the smaller titles are h3. That\u2019s why there\u2019s confusion when changing the size of h2.
As the post titles are <h2><\/code>, why do you not make the main headings (\u201csubheadings\u201d) <h3><\/code>? Is that too much work?
If you\u2019re referring to this one, clicking on the image opens the page with the document https:\/\/www.fotov60.com\/wp-content\/uploads\/2018\/04\/comunicatFARC_EP.jpg<\/a>, allowing you to zoom in. What\u2019s the issue?
I was not aware that you can click on the image to enlarge it. We ought to consider whether that enlargement would be satisfactory for smartphone users.
When I click on one of the six photos (Porsche etc), I get a page showing just the Hasselblad blog.
Would you change the font to Orkney, used in the rest of the text, and make it slightly larger, or would you keep it as Tahoma?
The font is your choice but, as mentioned, I am surprised Lighthouse does not say that the size is too small (not legible). You can increase the font size on CSS line 474.
In my personal opinion the font size of ordinary paragraphs (22.8px) is larger than most websites. I suggest you try editing CSS line 304 to font-size : 1.5em;<\/code> which will give 18px font size. The present rather large font size becomes an issue with small smartphones, especially as you are justifying the text. Here, emulated via Google Chrome, is how some of the text will appear on a small smartphone:
\"FOTOV8\"
We can deal with the small text of list items later.
You\u2019re right, I was working on the size for the desktop version and didn\u2019t take into account how it looks on the mobile version. Does it maintain the same size as the desktop in the mobile version?
I\u2019ve thought about the sizes could being:
H2 (post title) – 20 px
p – 18px
H1 – 32px
H2 – 20px
H3 – 18 px
H4 – 16 px
H5 – 14 px
H6 – 12 px
Is there any text element left to define its size? Do you think the relationship between them is appropriate? How should I express it in \u201cem\u201d to do it correctly?
I\u2019ve been reviewing the analysis from pagespeed.web.dev, and I\u2019ve noticed that my score has dropped significantly, from 99 to 86, due to these two elements shown in the screenshots. Are they part of the CSS that defines the text style or the design structure of the website? I ask because if they impact the text, perhaps it\u2019s time to fix them to simplify the text style, right?<\/p>\n

\"Screenshot_20240202_194522_Chrome\"<\/p>\n
<\/use><\/svg>Screenshot_20240202_194522_Chrome<\/span>1072\u00d74259 230 KB<\/span><\/use><\/svg><\/div>\n

<\/a><\/div>\n

<\/p>\n

\"Screenshot_20240202_194557_Chrome\"<\/p>\n
<\/use><\/svg>Screenshot_20240202_194557_Chrome<\/span>1080\u00d71813 252 KB<\/span><\/use><\/svg><\/div>\n

<\/a><\/div>\n

Powered by Discourse<\/a>, best viewed with JavaScript enabled<\/p>\n

source<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

Discussion continued from W3C validator reliability? – #31 by ArchibaldAs the errors do not seem to be affecting the appearancCould they be affecting the performance or SEO of the page?I have a problem with the text displayed in the article post. In the CSS, I\u2019ve included these styles to format…<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_uf_show_specific_survey":0,"_uf_disable_surveys":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-857","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.yellowfalconmedia.com\/blog\/wp-json\/wp\/v2\/posts\/857","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.yellowfalconmedia.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.yellowfalconmedia.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.yellowfalconmedia.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.yellowfalconmedia.com\/blog\/wp-json\/wp\/v2\/comments?post=857"}],"version-history":[{"count":0,"href":"https:\/\/www.yellowfalconmedia.com\/blog\/wp-json\/wp\/v2\/posts\/857\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.yellowfalconmedia.com\/blog\/wp-json\/wp\/v2\/media?parent=857"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.yellowfalconmedia.com\/blog\/wp-json\/wp\/v2\/categories?post=857"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.yellowfalconmedia.com\/blog\/wp-json\/wp\/v2\/tags?post=857"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}