I was messing around in the Ghost admin panel under Code Injection settings and succeeded in changing the text color of my HTML <code> blocks to from red to black.
Now that I've made the change, I can't figure out how to undo it.
Adding a <style> block doesn't seem to change anything, nor does a dynamic script seem to help.
Edit: I verified that it's not a caching issue, nor is it limited to a specific browser.
On the left-hand side of the Ghost admin screen is a tab titled "Code Injection". In this section, Ghost offers users the ability to inject valid HTML/CSS/JS on the top or bottom of each post.
I tried a number of possible solutions in there, but out of desperation, went back and tried using a <style> block once more. I was able to change the color by entering this value in the header, saving changes, then deleting and saving again:
<style>
code {
color: black;
}
</style>
It's possible that I entered my formatting fixes into the <footer> box or mistyped a character, but I'd be curious to know which.
Try clearing your browser cache (or holding down ctrlF5 at the same time in your browser) and then try again. Ghost makes heavy use of caching.
Related
Have found great help with R on SO--now for something completely different.
I am working in WordPress 5.8.3.
I am building a website using the Blank Canvas theme, a child-theme of Seedlet--Not sure whether that is all relevant. I am a novice with WP and all things web development. I have installed the Events Calendar plugin and have it all configured with some test events and dates so no issues there. I am customizing the theme colours using the Additional CSS prompt from the WordPress dashboard interface.
I haven't gotten permission to publish the site, so unfortunately I can't offer a live demo. I will try to be explicit.
I have found helpful resources with instructions on how to use this utility for menus, for general custom CSS, and some useful information for changing properties of footers with CSS. Now I am trying to modify hyperlink colours within the Events calendar widget. I have approached this problem the same way as all the others but this one has stumped me. I elaborate:
From this image, you can see the Events Calendar hyperlink text is yellow. I opened the inspector and determined that this object is called .tribe-events-widget .tribe-events-widget-events-list__view-more-link. I thought the following code should change the colour
.tribe-events-widget .tribe-events-widget-events-list__view-more-link {
color:#000;
}
It does not. This code makes no visible change. However, when I also change the background-color like this:
.tribe-events-widget .tribe-events-widget-events-list__view-more-link {
background-color:black;
color:#000;
}
The result is:
This led me to believe that there is no colour option for this element---HOWEVER, the inspector shows that this element has the 'color' property:
And I'm stumped. I'm not even sure when or how this color-link-accent got defined. This check-mark toggle is not a permanent solution and besides, I would very much like to understand what is going on here.
Any advice would be greatly appreciated.
It's a bit difficult to be certain of the problem as we don't have the context, however I was surprised that you saw just this:
.tribe-events-widget .tribe-events-widget-events-list__view-more-link
and didn't find an anchor (a) element within it.
I would have expected that you'd have to do:
.tribe-events-widget .tribe-events-widget-events-list__view-more-link a {
color:#000;
}
as it is quite likely the anchor element will have its own special styling which will override your setting because of the increase specificity.
If that doesn't work then use your browser dev tools inspect facility to find out more about the context of that a element - you may need to give even more hints to the browser on pinning it down.
Well, this would have helped me, so I will post the solution to my question for posterity. I learned from this question and thread about overriding cascading commands. I still don't understand where the command producing the yellow text in the first place was, but I managed to override it by appending !important in my CSS. The full CSS to turn the text from yellow to black is:
.tribe-events-widget .tribe-events-widget-events-list__view-more-link {
color:black !important;
}
Reading on, this does not necessarily mean that I was specific enough about the context although I find it hard to tell in this case. This reference has some other useful info as to when it is appropriate to use !important. It seems this is not the optimal solution.
Hope somebody else can benefit from my toiling...
I'm building a Web Extension that injects a local page and I reached a strange Chrome limitation on some websites: I can't set the iframe to be transparent:
Try this on GitHub.com (after login) or on Google:
document.body.insertAdjacentHTML(
'afterbegin',
'<iframe style="background: red" srcdoc="<style>body {background:none}">'
)
You'll see that the iframed page’s background (white) is shown instead of the element’s background (in this case made red to highlight the issue).
If you try the same code on StackOverflow or Twitter you'll find that the iframe is red.
I assume this is due to security but strangely it's even happening on this simple website that lacks any security header: https://sjmulder.nl/en/textonly.html
Firefox and Safari are not affected.
For anyone looking for a quick copy-paste answer: include a color-scheme meta header in the injected iframe. It must match the color-scheme header of the web page, if one exists. Do not add the meta header if a website does not have one. As this requires programmatic effort to figure out if such header exists a what the content value is, those steps are omitted, but once the scheme is known, the injection code would look something like this:
document.body.insertAdjacentHTML(
'afterbegin',
'<iframe style="background: red" srcdoc="' +
'<meta name=\'color-scheme\' content=\'light dark\'>' +
'<style>body {background:none}">')
Next a more detailed answer, and how I discovered it.
The screenshots show macOS in dark mode. If you go to OS settings and toggle the appearance between light and dark, this should alternate the white color and red color behind the iframe. Try and see if this happens.
After some experimentation, I discovered iff a website has a meta header for color-scheme:
<meta name="color-scheme" content="light dark">
as is the case with Github.com and sjmulder.nl, an iframe without matching header is only able to handle light mode correctly, and renders a white background if user device is set to prefer dark mode. I suspect this is because "major browsers default to light mode if not otherwise configured".
You can experiment with this and switch the color mode header on a test website to "light" (only) and "dark" (only) without specifying anything in the injected iframe; or define it in the iframe and not on the website, then switch the device color mode preference to see the effect. The conclusion I reached was the headers must match for iframe background color to get applied correctly.
I reached a strange Chrome limitation on some websites
When a website has not defined a color-scheme meta header and the injected iframe has not defined one either, there is no mismatch, and there is no issue, which is why this problems only presents on some websites. I also tried other browsers (Edge, Opera) and they have this same issue, at least on macOS. But it can be fixed in an extension by first checking if there exists a meta header on the page, and if yes, applying that same header to the injected iframe.
Read #neea’s answer for a broader explanation, but here's a quick fix that works anywhere: Add the CSS color-scheme: normal to the iframe, either via stylesheet or inline:
<iframe style="border: 0; color-scheme: normal" src="your-url.html">
Only do this if the iframed page will display correctly on both dark and white backgrounds. You might also need to set color-scheme: normal in your iframed page via meta tag, but this should not be necessary.
Why Chrome does this
Light schemes generally show black text and white background and dark schemes are the opposite. Chrome uses the color-scheme property to understand what schemes a website supports. The lack of it means it only supports the light scheme.
If the main page is being shown in a dark schemes and the iframed page isn't, with a transparent background you would get the iframed page’s black text on the main page’s black background.
This is a safety mechanism to ensure that the iframed content is still readable. If you drop it, you will need to manually ensure that the iframed page is readable on a dark background too.
Live demo
You can see that neither iframe has a background in both dark mode and regular mode.
Page only has one scheme, iframe never shows a white background: live link
Page only 2 schemes, iframe never shows a white background: live link
Following what #neea has said, which is true, I want to propose another code fix, since the color-theme fix doesn't do anything for me.
Since you use the iframe for a chrome extension, you simply need to have the iframe injected with a content script and then get the value of the page of the meta tag, which can be done easily with document.querySelector('meta[name="color-scheme"]')?.content
Personally, in my project I used react and react-frame-component, and I got it by inserting this into the head (I also use TS):
<meta
key="1"
content={
(document.querySelector('meta[name="color-scheme"]') as any)
?.content ?? 'light'
}
name="color-scheme"
/>,
I verify if the site has that tag, then I take and if not, it defaults to light mode.
This needs to be injected into your iframe HEAD. Then it will work for sites such as google dark mode or github.
Element.insertAdjacentHTML()
The insertAdjacentHTML() method of the Element interface parses the specified text as HTML or XML and inserts the resulting nodes into the DOM tree at a specified position. It does not reparse the element it is being used on, and thus it does not corrupt the existing elements inside that element. This avoids the extra step of serialization, making it much faster than direct innerHTML manipulation.
It has something to do with how chrome parses HTML and the order it uses.
After spending a while creating an online portfolio, then uploading it, I noticed an issue with one of my sections. On the "Advertisement" section, I noticed it was not displaying the information, just the title. So, I kept on re-pushing the stylesheet.css, even editing it, and it would still look the same. The HTML, CSS, and JS is working how I wrote it. But it is just the section that is not showing. After browsing online and on stackoverflow for an answer, I believe it has to do with Firefox. When using Firebug, I noticed the section's background has been removed, causing the entire section to "disappear." It works just fine on Chrome. I'm not worried about IE, I know that browser has some issues in itself. Anyway, would anyone on here have an idea to resolve this issue, if I can? Or even, what could be causing this issue?
Here is my website to see for yourselves. www.voelkerdesigner.com
Cheers!
It is the opposite for me your entire site works in firefox for me but not in chrome, looking through your code, its being caused by your naming conventions. Namely #advertise
I use the adguard extension in chrome and below is the css it plugs into my html pages to hide ads, so im guessing your using an adblocker in firefox
#adsense_top, #adsensewide, #adspace, #adspace_top, #adspot-300x250-pos-1, #adspot-300x250-pos-2, #adswidget1-quick-adsense, #adswidget2-quick-adsense, #adtext, #adtop, #adv-masthead, #adv-top, #advert1, #advert2, #advertbox3, #advertise, #advertisement1, #advertisetop, #advertising-container, #advertising_wrapper {
display: none!important;
}
Might as well post a random answer on this... As i wont visit posted links by new users.. i'm just gonna guess that your background image might not be 100%...
In general i use background-image instead of background.. Short hand can be a little pain and breaks in some browsers if not perfect.
so i would compare against the following example
background-image:url('images/mybg.jpg');
background-image:url('http://somesite.com/images/mybg.jpg');
Basically alot of people do not use the url and just go straight for a file name or dont quote it.. And have seen that be the problem in the past, so do use the url('') method.
Otherwise if it still fails to work and you know the image is absolute, you would then have some other css that is either over riding your elements background or is preventing it from loading.
Another trick is using your console / inspect element to manually inject the background-image and see if that works... So once the page has loaded in chrome, inspect the element as normal.. And double click on your css property listing as you can add your own styles this way and if it fails, then its not the markup but something else.
I'm using CMS Made Simple. I'm trying to include conditional Smarty code in my css stylesheet.
[[if $raduno eq '1']]
[[assign var='bgcolor' value='#bc3516']] /* red */
[[else]]
[[assign var='bgcolor' value='#f3c127']] /* yellow */
[[/if]]
body {
background-color: [[$bgcolor]];
...
}
The code seems to be working (I get a red vs. yellow background depending on the value of raduno). However, caching of css stylesheets seems to interfere with this approach. The background color selected on the first page visited after clearing the CMSMS server cache is the one I also get on all subsequently visited pages, regardless of the value of variable raduno.
Is it possible to cache the stylesheet depending on the value of a variable? (If so, automatically or manually?)
The problem is currently resolved by having two separate stylesheets. However, this makes maintainance difficult. Also, disabling the cache is not an option here --- the template using the two stylesheets is used for the whole site.
I am using CMSMS version 1.10.3. I realize that upgrading might help, but I haven't found any indications that this is the case in the changelogs. (And my version is installed on opensourcecms.com!)
No, the only way to do this would be to avoid caching the stylesheets, which would not be a good idea. The simplest workaround would be to use inline css and Smarty, or do the swap with jquery.
I've added a jpg file to the App_localResources folder and in the document properites specified the photo in the Background propery. In the designer it shows up as the background but when i run the page i still get the white page background.
There's no distinctly ASP.Net way of doing this.
The canonical HTML way is to include this CSS:
body { background-image: url('background.jpg'); }
If you defined the body tag with runat="server" you could add the style inline using the Attributes property, but this wouldn't be a good idea. Layout details like this should go in the Stylesheet.
Guessing that perhaps you have a stylesheet which might be overriding the background?
I would check if the built in web server was still running and stop it, then re-run your application.
* Right click on the tray icon and select "Stop".
The page is being cached, you should see your changes now.
I used fiddler to trace the calls on the image. App_LocalResources\*.jpg return an 403 error. The App_LocalResources folder is really for use for localization. If I move the image into an image folder it works fine.
Also rather than setting the Background property, use the Style property and the background property there.
Sometimes you need to clear the cache of the browser after making changes to backgrounds and colors in order for it to apply when you run the site the next time.
Take a look here:
http://www.wikihow.com/Clear-Your-Browser%27s-Cache