Once in a while, a css rule will be ignored, despite being correctly defined in the loaded stylesheet, and correctly targeted at a class patently present in the markup. Has anyone come across this, and can anyone explain what is going on?
You will not be able to reproduce the issue, but consider the following, pasted from markup/scss:
.test-footer {
display: none;
background: red !important;
}
.test-footer {
display: none;
}
<footer class="test-footer"></footer>
The topmost rules did nothing (I added the red !important line just to be sure it wasn't being overridden). Then, without changing anything else, I added the second, identical rule, which was honoured without issue.
I have experienced this a few times now – not so frequently that it has entered my offhand list of things to look for when css misbehaves, but often enough over the last year that I have taken notice.
I am using Coda 2, and working on a mac running OSX El Capitan. Also, I am using the Coda sass plugin to compile.
The behaviour was consistent across browsers, and editing any other part of the stylesheet produced the expected results. As stated above, I checked, and the correct css was there all along – one part of it was simply ignored.
My solution should not work, so why does it? Come to that, the issue should not arise in the first place, so why did it?
Update:
I enabled hidden characters, to see if they might be the culprit, like Ruud Helderman suggested below, but I found nothing. In the end I had to let it lie. I solved my problem, after all, even though the "solution" was a magical fluke, or rather the problem was, and the question was asked as much out of intellectual curiosity as anything else. I am leaving the question unanswered for now, thinking that when and if it occurs again, I will update with any findings.
My only experience that comes anywhere near what you describe, is a syntax error in the stylesheet causing all subsequent rules to be ignored. Rules preceding the faulty rule would still be effective.
Another possibility might be the presence of an invisible character (e.g. U+200B); try to configure your text editor to reveal non-printable characters.
Ok, so this came back in a big way – there was much griping about my perceived failure to pull changes from git, because my colleague's styling changes appeared to be overwritten when I pushed changes to the server. I found that his changes were actually present in the compiled css: they were simply ignored by the browser. I still found nothing amiss in the css – no hidden characters, nothing.
But in this case there were differences in how the scss was written, and also in how we compiled. Specifically, he uses linebreaks weirdly, which shouldn't affect the output, but did. He also uses Coda, by the way, so this makes no sense at all. But the "solution" turned out to be changing the sass output style to "compressed", which is annoying in development, and shouldn't be necessary, as the compiled css was fine all along, but it made the problem go away, and hopefully, this is the end of it.
Related
I try to avoid using !important in CSS as much as possible. However, when working in WordPress I have to use it occasionally to fight styles of plugins.
I use VSCode for much of this work, and in almost every way its perfect. However, if I go to use !important, I start by typing !impo - which VSCode provides an "Emmet Abbreviation" for it that suggests !important;
However, it's not updating my typing to !important - its appending !important. So if I type "!impo" and hit tab, the result is "impo !important;" (it also removes the initial ! which is bizarre)
Has anyone run into this issue and has a real solution? Autocomplete really helps my workflow and speed, but this particular one is a nuisance. I always have to either fully type it out or autocomplete it and delete the incorrect stuff and its very frustrating.
I am passing my .css file through the W3C CSS Validation package on Atom and it gives me a "Parse Error" message virtually to all variables created for the sake of an exercise. Here below there is the beginning of the :root pseudo-class (but all the remaining variable declarations are as just as faulty)
I already tried to re-write them from scratch, replace them or change the values only to check the behaviour, but nothing changes it.
:root {
--primary-color: #781820;
--secondary-color: #ABABAB;
--tertiary-color: #cead00;
--backup-color: #FAFAFA;
...
Other than fixing the errors, I'd like to understand where they lie to better understand the process.
As stated, this is a non-issue. CSS is moving and changing too fast for the Jigsaw W3C CSS validator to keep up, and it can no longer be relied on for checking anything other than the most mature feature sets such as those of CSS2, and of the earliest CSS3 specs.
It's a shame that it can't even be used reliably to check for careless errors now (which is what it's always been intended for) because the real errors are constantly getting occluded by so many of these fake ones. For example, it may not spot a real typo because it was thrown off a few lines up by one of these features it doesn't support.
The most reliable validator these days is to test in browsers and assume that if it works consistently across the board, then it's valid. Or, when in doubt, ask a question here and hope someone familiar with the specs will answer. If anyone asks you if you've tried validating your CSS, point them to me.
I have a website, where we are using a tool to minimize and compress css code. It is called JCH, it is a plugin for Joomla, I think you can use it on Drupal too. I have an issue this css code:
#sp-user3 .help-menu .nav.menu :not(.user-menu){
display: inline-flex;
}
It is being converted to:
#sp-user3 .help-menu .nav.menu:not(.user-menu){display:inline-flex}
As you can see ".nav.menu :not" is converted to ".nav.menu:not" which causes the css rule to not be applied as intended.
This can be an error on the tool. How can i rewrite it or add a character to avoid that confusion? any ideas are welcome.
This is indeed a bug, and this is not the first time I encountered it.
The StackSnippet editor on this site used to have the very same bug in its Tidy button. See my bug report. It was fixed soon after.
So you can file a bug report with JCH and then wait for it to be fixed as well.
Meanwhile, you can insert a * before the : in the CSS as a workaround.
:not() is a shorthand for *:not() anyway, so you won't be changing the meaning of the selector, just writing out in full what was implied.
It's a definitely tool issue, web minifiers like Minify generating correct code.
#sp-user3 .help-menu .nav.menu :not(.user-menu){display:inline-flex}
This is what I see on the inspector:
There's like a left highlight in two rules, which are the ones Firefox is making up,
if I look on the computed styles I see this:
And finally this is how the original CSS looks like:
So Firefox it's changing the position and width rules somehow.
Anyone can explain me why is this happening and how to avoid Firefox changing those rules?
(In Chrome, Safari works fine)
The "left highlight" is used to indicate a style rule that has been modified within the Developer Toolbar since the page loaded. Reloading the page and/or restarting the browser should repair the rules from your stylesheet.
If you're still encountering the issue after this "quick fix", my next advice is to search your stylesheet(s) for position: absolute, disable them one at a time, and re-test. It's very unlikely Firefox is changing your style rules on its own.
You might also find it easier to postpone minifying your CSS while you're debugging. That way you'll get more useful line numbers to reference vs. having every rule cited as being on master.css:1.
Finally, you might find it advantageous to use shallow selectors in your CSS rather than deeply nested selectors like the one you've shown. This will help avoid specificity conflicts, which was likely the original cause of the issue you're encountering.
I have this weird scenario where I am moving code between two servers. In the original server everything looked ok, however in the second server the CSS breaks. When I looked into the code, it seems the css styles/classes and the html counterparts both have different casing and those too vary for the same class, so for example, html has class="main_menu" and css has .Main_Menu.
So obviously it should break, however in the original server it seems somehow the casing was ignored and for that reason everything worked properly. So any idea how that was achieved?
CSS selectors are already case-insensitive.
What you have to watch out for are HTML class names, as they are case sensitive.
See this question for a more detailed explanation.
There are two ways I will tell you to fix this, but both are, in essence, just slapping a band-aid on it and calling it good.
Change each HTML class to include the new CSS selectors
Run the entire stylesheet and HTML rules through a toLowercase() method of some sort.
Both of these will fix your problem, but neither are a very good solution.
The moral of the story is to use one case and stick with it. There is no point in going back and forth.