I have an element with the class .ui-menu .ui-menu that has the style of margin-left:25px;. I have removed this, so that it is margin-left: 0px;. However, when I refresh the page, it's still displaying this style, and the 'inspect element' window tells me that according to the css file it's reading .ui-menu .ui-menu still has a rule set for margin-left: 25px;.
I have tried using F5, Shift + F5, Shift + Ctrl + F5… I've manually cleared all cache, shut the computer down and restarted it. I'm about to uninstall Firefox completely and reinstall it to see if THAT even works. I've also tried renaming the CSS file, and re-linking to it with its new name… and then Firefox stops reading the CSS file entirely, because it's not updating the headers or footers to see that it's been changed so everything goes unstyled!
I don't have this issue in GC, Opera, Safari, not even in IE. Am I doing something wrong?
As to your questions:
I'm using Firefox instead of other browsers because I can't control what browser people who visit my site are using. As far as website design goes, this is a pretty basic understanding.
I've run the site through validation here: http://jigsaw.w3.org/css-validator/validator?uri=http%3A%2F%2Fthesciencefacility.icyboards.net%2Findex.php&profile=css3&usermedium=all&warning=1&vextwarning=&lang=en
Most of the issues here are just cross-browser stuff, plus some embarrassing color issues. if you can find something here I can't, please mention it!
The site is not self-hosted. It's a forum service through IcyBoards, if you're at all familiar with it.
Related
First, I've seen the duplicates
What is #shadow-root, and why does it put display none on my font awesome classes?
and
HTML / CSS - DIV Element hidden when it shouldn't be?
however both of these suggest the issue is with adblock and I have totally disabled adblock.
I am more concerned with where the #shadow-root is coming from, since I certainly did not put it there.
I have read that there is an option in chrome to disable it (and interestingly enough I have it disabled...), but this means that anyone using my website will need to do the same, and I'd rather just do away with it entirely as it provides zero usefulness in my application.
I have also googled and read many of articles about the shadow dom and none of them give any insight on why it would appear seemingly for no reason.
From what I have seen in inspector/view page source, the entire contents of my app are being rendered into this shadow dom and thereby not receiving any of my styles.
I am using rails, react, redux, react-redux, react-router
Chrome developer tool screen
Page Source screen
Notice that the source has nothing in the div that react should be rendering to.
Additional info:
displays unstyled page on chrome in normal and incognito
does not work at all in safari
A lot of chrome plugins automatically create this shadow root in your inspector. For example, ever since I downloaded Vimium, I've had a shadowroot div at the bottom of any page I've opened in chrome. It's nothing to worry about.
I was having the same issue and found that it was Adblock Plus that was adding #shadow-root. Thanks to the resources above I was able to assertain what the issue
For me it was also an Adblocker (uBlock) and it was actually hiding part of the webpage I was making which showed imported tweets. Turning the adblocker off for my site fixed it.
I'm using Bootstrap glyphicons. They are working nicely, but with Chrome browser, the glyphicons blink when the page loads
For example:
Open this link on Bootstrap:
http://getbootstrap.com/components/#glyphicons-glyphs
Once loaded, Press F5 or refresh.
You will see the glyphicons blink.
How can I fix it so they don't blink?
Here's a screenshot:
Note: This only happens in Chrome, not FF or IE.
Generally, this is a problem with having a flash of unstyled content (FOUC).
Specifically, this is what Paul Irish calls a flash of unstyled text (FOUT):
In Firefox, basically the text is in a default webfont until the custom font is ready
Webkit takes a very different approach, and very intentionally. They believe it’s better to keep the text invisible until the font is ready. This way, there is no moment where the text flashes into its newly upgraded self
In other words, this issue isn't so easily overcome.
You can attempt to minimize the impact by:
Using gzip to shrink the file so it downloads quicker
Using caching so the client can use an existing copy rather than grabbing a new one.
The heavy handed approach would be to wait to display the page to the user until everything was rendered, but I would strongly recommend against this. User are very impatient for initial load times but are considerably more forgiving when it comes to rendering additional content.
The glyphicons blink/flicker on page reloads, but the bigger problem for me (I'm using Bootstrap 3) is that the page flickers as elements resize around the glyphicons. Adding this to my CSS stopped the resizing for me:
.glyphicon {
width: 14px;
height: 14px;
}
Thanks to my source: https://www.garysieling.com/blog/preventing-icon-flicker-using-glyphicons
I had exactly the same problem but solved it by adding .woff and .woff2 as new MIME-types font/x-woff in IIS.
This stopped the glyph-icons from blinking immediately as Chrome now caches the font-file correctly.
To see if this may apply to you, open the debug-console in Chrome (F12) on the site it blinks and you will find an error related to the glyph-font-files where the browser interprets them as the wrong MIME type.
Ok off the bat I appreciate this is a weird one but just throwing it out there as I'm out of clues.
Almost got sign off from a client when they brought it to my attention the navigation on the site was messing up when resizing in the browser.
It only occurred to me after they sent me a screen shot what was happening, take a look:
My browser (Firefox v29)
His browser (Firefox v29)
For some reason he is seeing something rendering with font-varient:small-caps; which is not even set in my css. I've even tried setting font-varient: normal; just in case.
Has anyone else come across this? It's really bugging me out because I can't possibly recreate the problem in order to fix it.
Thanks
Ask your client to clear the browser's cache and history and reload the page with Ctrl + R key combination.
It seems to be an CSS style cache problem, the rule for the font in his case is
text-transform:capitalize and in your case is font-variant:normal.
Also make sure that your client do not use custom CSS style in Firefox, which overrides the page's one. Some browser plug-ins allow such custom CSS style overwrite, for better accessibility.
Maybe it's related to default browser settings - he might change it manually in Firefox settings or maybe some accessibillity software did it.
For some reason, on this page, in Chrome 17, CSS3 transitions aren't working the first 3 links in the footer/nav: http://jacob.bearce.me/index2.htm. The links are exactly the same, no added classes, and I went through step by step to figure out what it was, it's changing the HREF property that breaks them. For some strange reason, services.htm works, but projects.htm does not. I have absolutely no idea why.
UPDATE: Tested in Firefox, Opera and Safari it seems to be only a Chrome issue. It makes no sense. It's not even a webkit issue (unless Chrome's got a newer version than Safari).
Sorry if this response is slightly late, however, I'm currently on Google Chrome 16.0.912.63 beta-m and I have the exact same problem as you do. In fact, on your website, out of the 4 links below, it is only the home link that doesn't seem to be working too well with CSS3 transitions (on my side).
On a website I'm currently working on, the transitions seems to only work on some links and not others. I can't really see any trend to understand what causes it. Strangely though, when I visit your website or mine through Incognito, everything works well. It doesn't work even with my extensions disabled.
It looks to be bug with Chrome. I've figured out that it's definitely an issue with :visited links, but can't fix it no matter what. In incognito mode you don't see the issue because Chrome isn't logging what links you've visited. From what I've seen, it looks like it's an issue in Chrome 16 or higher. Hopefully they'll fix this in the next release, but for now, we'll just have to ignore it.
I've ran into a snag I've been working on for a couple days and can't seem to come up with an answer online. The site template I'm working on now is located at "http://citylakersbaseball.org/2.0" - I've got a div named "sponsors" that shows up fine in Chrome and the built in Live View of Dreamweaver CS5 - however, in Firefox 3.6 & 4beta it completely vanishes. I can see it in the view source, yet firebug has it grayed out. Maybe it's a DOM issue? (for which I don't know much about). Rendering engine issue?
I ran the source (index,htm) and CSS (style.css/nav.css) through the HTML validator - HTML is fine, and the CSS didn't spit back anything I would think could effect the div's display, especially since Webkit has no issues with it.
Any thoughts would be appreciated. Thanks in advance!
Your ad-blocking Firefox plugin is detecting and removing the div from the DOM. I experienced the same behaviour in Chrome and Firefox (which have ad-blocking plugins/extensions), but not in Safari or IE (which don't); and, indeed, the div appears if I disable Adblock Plus. One of the more basic rules Adblock Plus and the like follow is to look for HTML elements with class="sponsors" or id="sponsors" and remove them.