I'm having trouble with the text underneath the images on the website I'm building:
1) The "Back to home page" changes from the font it's set at (Georgia, 0.9em) to the default in Firefox. It does not do this in Safari (http://ink-12.web5test.terc.edu/img/modelofinteractionfull.cfm).
2) The footer appeared fine before I added images (http://ink-12.web5test.terc.edu/index.cfm). After I added images (inside div class=.submenu), again, the font I set (Georgia, 0.9em) changed to the default in Firefox (http://ink-12.web5test.terc.edu/aboutus/index.cfm).
Another issue that appear after I inserted the images:
1) The footer's vertical bars (|) disappeared between the links, in both Firefox and Safari. You can see that the bars are actually still there when you highlight the text, but for some reason, they do not appear in white anymore so they aren't visible (http://ink-12.web5test.terc.edu/aboutus/index.cfm). But you can see how it's supposed to look on the home page (http://ink-12.web5test.terc.edu/index.cfm).
I wanted to copy my code below, but I'm having trouble understanding how to properly format it on this site, so I'll work on that. In the meantime, any thoughts?? Thanks so much in advance for your help!
For example, regarding question 1, the only CSS rule that sets the font family is
h1,h2,p,p2,li{ /*group codes for many styles*/
font-family:"georgia";
}
It does not affect the link, since it is not inside any of those elements. Similar considerations apply to question 2. And the vertical bars are there, they are just black on black.
Use a markup validator like http://validator.w3.org to find he HTML syntax errors, fix them, and then deal with the CSS syntax errors with http://jigsaw.w3.org/css-validator/ and then analyze the logical problems. Using Firefox with Firebug is a good idea, since then you can click on any element and see which, if any, CSS rules are being applied to it.
I'm not sure if this will help you, but I suggest making sure that "Georgia" is capitalized when you declare it. I might be wrong but suspect that some browsers may not be picking up the name because it doesn't match the font's name perfectly.
Comparing the pipes (the vertical bar characters '|') between your examples shows a small flaw in the CSS. The pipes are not inside of the <a> tags so even if you set all your <a>s to white the pipes will never change. In one example ( http://ink-12.web5test.terc.edu/index.cfm ) the pipes are contained by a <p2> tag, which wasn't a valid HTML tag last I checked but that's besides the point. The <p2> has its color set to white which makes the pipes inside of it white. In the other example ( http://ink-12.web5test.terc.edu/aboutus/index.cfm ) the pipes are contained by a <div> which has its color set to black which makes the pipes black, but the <a>s are set to white. Since your background is also black the pipes disappear.
For the "|" issue add the following
skeleton.css line #161
.footerlinks {
padding-top: 0.5em;
color: #fff;
}
For the link issue it looks to me that the font is becoming bold when you hover. You just need to define your hover state ...
fonts.css line #4
a:hover {
font-weight: normal;
}
Sorry, it was such a simple fix! I"m very new to coding (as I'm sure you could tell by the ridiculous amount of markup I had in my style sheets). I didn't know that links could have all their own font-family, and thought that if you kept it between a heading or paragraph tag, that it would just take that on. But I get it now, thank you!
Related
I've the following problem, I'm trying to change the color of the text of a "< li>" element, in joomla menu. I give the menu a link to css selector called blueMenu, this is my CSS regarding the class:
.blueColor {
color: blue;
}
However this doesn't change the color of the text, on the other hand if I change "color" with "background-color" the background of the text becoms blue. Any idea what may causing the problem?
You dont give much information, but it might be that the li has a child element inside that its overwriting the li styling, make sure you using the style on the last child.
You can also force it with !important;
.blueColor {
color: blue!important;
}
This really much depends on your template.
As already said, reasons can be inline-styles, or may more "distinct" declarations.
If you just specify the class like you did in .blueColor this will be treated with a lower priority as e.g. li.blueColor or to get even more clear both with be treated with a lower priority as e.h. #someId.andClass .subElementClass li.blueColor a.thisIsWhatIsReallyBlue
This is more about CSS specifications than a Joomla-Problem though.
You might check the style that is really applied by just launching your Development-Tools of your webbrowser (for Chrome simply press F12 or right-click on the element and inspect the element directly)
The CSS-Section on the right side might tell you about what really makes the item become blue ;)
Oh, and just a note:
As already mentioned you can use !important to "force" the styles to be applied, but if this is not absolutely necessary, i'd suggest to find the way to override this style on a clean way, since !important, if used to often, might result in a complete mess of your stylesheet.
regards
I'm not familiar with joomla but it may be inserting an inline style to whatever element you're trying to style. Right click on the element and use inspect element (firefox) or just inspect (chrome) to see if any styles were applied.
It'll look like <div class="" style="color: blue;">
I have tables in which I want to represent negative numbers as red text. The problem is that in the print preview the color is not applied to the first letter.
I have CSS rules in a media print block. I have tried to put the number in a span and applied the redText class to both the span and the td itself. I have tried to apply the color to the class element and every subsequent element.
#media print {
.redText, .redText * {
color: #f44336 !important;
}
}
The html is:
<td class="textRight band0Bchange_ue_04 redText">
<span class="redText">-1,566</span>
</td>
This is the HTML in the regular view where the color is rendered correctly. I am not sure whether is possible to inspect the elements in the print preview.
Edit: The issue is caused by the Material Design library. I have put the relevant html and css into a jsFiddle. This works well. Once I add material.min.css the print breaks with the behaviour as described above.
https://jsfiddle.net/goldrydigital/8fzby8aq/2/
I have added a print preview on the jsfiddle.
https://jsfiddle.net/goldrydigital/8fzby8aq/6/
Here the problem doesn't display. The problem is only visible when I use the actual print function on Firefox.
Please check, may be possible you have written first letter CSS for print or main style sheet.
.redText::first-letter {
color: #000000;
}
I tried in codepen also it is working fine as you provided the code in question section.
Santosh provides a good answer which helped me to solve this issue. Here just to confirm the bit in the mdl css library which causes the issue. Apparently black prints faster this way.
Maybe you have put your span at wrong location...
In your output -364 do not have any comma or dot still it is leaving the first digit and rest all are red colored.
I suggest you, check the HTML tags.
The ::selection { } CSS element selector is supposed to replace the default blue-colored text selection with our own choice of text and background color.
However, this seems not always the case, as I often see websites which has the remaining blue color. It's not completely replaced with our owh choice of color.
======EDIT======
I guess it's easier to see by our own eyes rather than through screenshot.
See this page for example: bleachindonesia.com/2012/05/27/bleach-day
On that page, if you try to select all (Ctrl+A), you would see the text will be blocked/selected with gray color. Yes, because the page CSS employs ::selection, ::-moz-selection { background:#59574b;color:#fdfcf5; }.
However, as you can see with the screenshot below, it leaves some default, blue-colored selection on some part.
http://i.stack.imgur.com/A0aUJ.png
Notice the color difference, and at the same time, the unselected part. There are some parts on the site that gets selected with the default blue-colored ::selection, but at the same time there are also some other parts that doesn't get selected.
Meanwhile, there is also this page: 24ways.org/2005/swooshy-curly-quotes-without-images
Again, try to select all (Ctrl+A) the page. You could see all selection is perfectly maroon-colored. There is no default blue-colored selection. There is only parts that doesn't get selected, but there is no the default blue-colored selection. As pictured by the screenshot below:
http://i.stack.imgur.com/4o6ll.png
The page CSS? ::selection { background-color: rgba(179, 45, 71, .75); color: #fff; }. The only difference with the first page that it uses RGBA and not hex code. I don't think it makes any difference there--it's essentially the same code.
Now what makes me wonder.
Why is on the first page the default blue-colored select persists, but it doesn't persist on the second page? And, how to make it as perfect as the second page?
Frankly, it's very difficult to tell if this is buggy behavior, although I'd surmise that it looks very much like it. ::selection suffered from a lack of proper definition (and thus a lack of proper implementation and testing), so I bet even browser vendors have had trouble figuring out what's wrong.
Worth mentioning is that this rule, from the first site:
::selection, ::-moz-selection { background:#59574b;color:#fdfcf5; }
Seems very much benign, except it incorrectly combines ::selection and ::-moz-selection such that it will never work in Firefox, because it doesn't recognize ::selection and drops the whole rule. 24ways.org doesn't display the selection color properly in Firefox either, not because of combined selectors but because there is no ::-moz-selection selector in the first place.
As to why Chrome and Safari leave blue areas of highlight in certain areas in the first site, I really don't know. However, I think Jared Farrish makes a good point:
This replicates the problem in Chrome (at least): jsfiddle.net/RfPgt It seems to be when an element is nested within another element which itself has selectable elements.
I found what is causing this. It is <br> so if you have <br> in your text try deleting it
I read this question some time ago to find a solution for the same problem but I did not find it. Now, even if the question is old, I want to share the solution that I found.
Just use the universal selector:
*::selection { background:red; }
I am doing this site for a friend http://www.kidsmartnyc.com/ and there is an enormous white space in IE8 below the middle image that is not visible in any other browser or any other version of IE. Please help, I have tried everything:)
Change your css, you defined #page1 h1 { height:250px;} .. change this...
I'm seeing a couple of things:
Like Jordy said, you set a height on your #page1 h1 tag. That's usually not necessary. The reason you're not seeing it is because the h1 tag is empty, like this:
<h1></h1>
Below that in the code, you just have a couple of tags that are also creating more space. Take those out and you should be fine.
This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 10 years ago.
This is my site: http://portable-ebook-reader.net
The search bar at the top is made up of two background images. One is for where you'd type in the search phrase, the second is the actual button to search.
My problem is that in Chrome the search button image is 2px too HIGH. But it looks perfect in IE and FF. And if I modify the CSS (margin-top: 2px) then Chrome looks good but IE and FF are messed up.
Any ideas? I've been searching for hours without any luck.
Thanks!
To use CSS that will only apply to Webkit browsers (Chrome and Safari):
#media screen and (-webkit-min-device-pixel-ratio:0) {
#searchsubmit { height: 20px; }
#s { margin-top: 5px; }
}
An ugly hack but it can work for those frustrating rendering problems.
You could check to see if navigator.appVersion contains the word "Chrome" and set the relative positioning of that button down a couple pixels via javascript.
if (navigator.appVersion.indexOf("Chrome/") != -1) {
// modify button
}
Get it looking right for FF first. Then get it looking right for both FF and Chrome. Only after you have it looking right in FF and Chrome, should you start concerning yourself with how it looks in IE. After you achieve this, then start adjusting for IE, if necessary, using * before your style rules, example: *margin-top:2px; adjusts the top margin for IE7 and IE6 exclusively.
After looking at your code, it's difficult to say exactly what may be causing the problem without being able to test different solutions on my system. But here are some things you can try to change in your styles.css file (located in your 'chronicle' folder within your 'themes' folder) that may correct the issue:
apply the same height value to both your #s and #searchsubmit rule-sets
remove font: 14px "century gothic", Arial, Helvetica, sans-serif; from #searchsubmit
after you do the above, if it still doesn't look right in both FF and Chrome, set the first and second padding values for your #s rule-set to 0 (i.e. change 8px to 0px) and then add a margin-top: declaration to both #s and #searchsubmit and give both the same value, for example margin-top:8px;
if you're still having issues, try copying this line: font: normal 100% "Tahoma", Arial, Helvetica, sans-serif; from your #s rule-set and add it to your #searchsubmit rule-set so that it appears in both rule-sets.
There's so many different possibilities that could be causing the problem, which is why you may want to try one of the aforementioned hacks if you can't figure out the source of the problem.
Try changing your doctype to strict - whatever works in one should mostly work the same in all three major browsers. Mostly.
Just as a reference, a list of all possible browser specific CSS hacks. Although I discourage the use of those hacks, it may suit a quick fix for your problem.
I found this trick a couple of weeks ago and it seems to work identically in all browsers.
Create a single graphic that contains both your search bar and search button. Make it the background of your form through CSS styling. Then adjust both your text input and submit button (likely through classes or IDs) to have {border:0; background:transparent} and then simply adjust the height and width of the form elements to fit the layout of your form background. I formerly used <input type="image" ... /> but could never get the alignment quite right no matter how I styled or padded it. This method works right pretty much after your first adjustment of the form elements' margin, padding and absolute positioning if need by (you might want to leave the borders visible during testing just so you can place it properly).
I also find it handy to put a {cursor:pointer;} over my search submit button and sometimes even other form inputs to give a visual clue that this is a submittable form and people are encouraged to click.
Have a look at http://rafael.adm.br/css_browser_selector/
little js file that adds classes to your body tag like .webkit, .chrome etc which you can thus use in your stylesheet.