Here is example it's only forking in html and not in css
How to fix this problem?
It's dificult to find information on internet because i am the only one who have this problem
In your case, the image shows you are outside of a css ruleset so there are many fewer emmet abbreviations that will work there. Your image shows what happens with a prefix of pos - it suggests things like :placeholder-shown, etc. that do appear as part of a css selector. If you are expecting the rest of the emmet abbreviations, like bg for background-color, use it IN a ruleset.
There seems to be some confusion from commenters (some since deleted) that emmet does not work in a css file - it does and has for some time.
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}
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.
I'm almost done with a project and now I'm facing a problem I don't know how to solve.
I did the whole css styling with the box-sizing: border-box (with ie6/7 polyfill) applied and it worked like a charme on every device I tested, until I picked up a blackberry. It doesn't support box-sizing (actually it does, but only from the very last version) and now all my layout is broken. Since the project is almost finished I don't want to go back and update every single stylesheet to not use that css rule. What do you think would be the best way to tackle this?
speaking about this:
http://caniuse.com/#search=box-sizing
Thank you
The first suggestion is that you could perform a server-side detection of the BlackBerry browser and if the version detetcted doesn't support the box-sizing property just send to the client an overriding stylesheet on the cascade, containing all the necessary rules (with an higher specificity, of course) to correct the wrong style.
Otherwise, if this method still need too much work to fix, you could try to serve a non-strict doctype for that specific browser only and see what box-model is used by that browser. For sure it's a bit hacky method, but maybe this change could have some good impact and "straighten" your layout.
I've just been assigned the task to refactor a huge 5000 line CSS file... but here's the worst part - I also need to make it IE6 compatible. Any CSS gurus have suggestions of tools, or possibly tips (common pitfalls) for use in my monolithic expedition? Cheers.
checkout sass... it includes the ability to convert css to sass.
http://haml.hamptoncatlin.com/docs/rdoc/classes/Sass.html
A sass file is a yaml file that can be parsed down into a css file. It allows you to use variables and alternate organization...
sass example:
!main_color = #00ff00
#main
:color = !main_color
:p
:background-color = !main_color
:color #000000
css output:
#main {
color: #00ff00; }
#main p {
background-color: #00ff00;
color: #000000; }
Some tips:
Use version control so you can roll back when needed.
Come up with a checklist of visual tests to run through after each change, in each browser. A spreadsheet of URL links and things to look for, building on them as you run across problems (think "unit tests" but not automated).
Use a CSS-specific beautifier first to get everything into the format you prefer for braces, etc.
Consider using something like SASS to "compile" your CSS as you go along.
Comment the heck out of things, especially where you're doing IE6-specific stuff.
Future-proof yourself by building a separate file with IE6-specific directives as you go along, or at least use Microsoft's way of filtering them out for other browsers.
Use the W3C Validation often.
Mechanically, I would attack it like this:
<link type="text/css" href="newhotness.css" />
<link type="text/css" href="newhotness-ie6.css" />
<link type="text/css" href="oldandbusted.css" />
Move code from the third (old) file into the other two, cleaning up as you go. That way you can validate your code without worrying about tons of errors in the old stuff, and you can track your progress, Ctrl-Tab between them more easily than between locations in a single file, etc.
(If you can't control the markup to add your CSS files, use an #import at the top of the old file.)
Start from scratch!
Assuming you can check all the major pages manually, I would be VERY tempted to wipe the entire file and start from scratch. Spot-checking for IE6 inconsistencies, you'll be doing nearly the same amount of work anyway, but it will be much, much more painful if you're modifying old, browser-specific CSS.
That 5000 lines may well be expressable in 2000 lines of modern, well-designed CSS. I think most experienced CSS developers would find it less work to write 2k lines of new CSS than modify 5k lines of horrible CSS.
http://www.codebeautifier.com/
which is based on this:
http://csstidy.sourceforge.net/
Not necessarily CSS, but here's worflow tip: use GIT.
start off by importing the files in git;
commit for every minor step, and record what you did;
whenever you find that you broke something, you can identify the exact same step broke using git bisect ( a good description );
For extra kicks, here's a talk about code coverage for CSS to help you quickly weed out unused rules.
As Triptych said, I would start from scratch. Also, consider the following:
use a CSS reset file to smooth out cross-browser inconsistencies: http://meyerweb.com/eric/thoughts/2007/05/01/reset-reloaded/
get it working perfectly in Firefox, then tweak for other browsers as needed
study the underlying HTML. How is it organized? Is it laid out with tables? all DIVs? Semantic tagging?
is the CSS used for layout or simply styling (fonts, colors, etc.)?
Once you get a feel for that, study the content. Categorize the layout and elements as much as possible, so that you identify all the common elements and can maximize the efficiency of your CSS
remember the C in CSS, Make the most commonly used font the body font, so that other elements will inherit it by default.
use relative units (ems) for font size, to allow proper scaling of text
try not to use ANY inline styles
make use of Firebug - it will let you inspect an element and see exactly what CSS is in effect and where the rules came from
don't be afraid to re-use portions of the old CSS, especially for things like dropdown menus, which can need very specific incantations to work properly
have fun! starting from scratch lets you implement best practices and learn a ton along the way. When you are done you are probably going to look back on this as a good experience.
there is a presentation here that should get you in the right headspace for tackling this task: CSS Systems
I would be tempted into creating a test suite first: automating page visits (perhaps with Selenium?), taking screenshots, then using something like ImageMagick to compare those with reference images.
Also, I second all the suggestions to use source control. If you later discover that your refactorings broke something that wasn't checked by the test suite, you can add a new test and then bisect your history to find the change that broke it. Git is good for that.
Get a code editor with good syntax highlighting. Also, goodluck I dont envy you.
My initial thought was does some like NCover exist for CSS, as it would be handy to see if all of the CSS is referenced. A quick Google on CSS code coverage found a few things- you might want to look yourself though: http://development.lombardi.com/?p=436
Install sass, run css2sass on your 5000 lines of css, proceed. After you are done with your sass file refactoring, run sass2css to regenerate the css file. Best of luck!
I'd suggest Stylizer - it is a CSS editor with an embedded live preview browser. It makes life much easier when editing CSS files and can tell you which rules affect which element on the page and more.
All of you guys saying he should start from scratch are wrong. You shouldn't. Try to identify the different parts the site uses. Put them on a sheet of paper. Find the parts that match together. Build a structure. Find parts of the application that are the same but are still styled with different rules.
Take that one part and name it. Then match all app parts that use that "pattern" with the correct HTML/CSS.
Repeat until you're done. Break up the large task in small chunks.
Identify whether the original CSS writer used standard methods like using a CSS reset. If he didn't, and everything is defined by #id without reusable classes, well, then maybe the guys saying you should start from scratch are in fact right. But my point here is that you can't just recommend that without assessing the situation.
Using the Dust-Me Selectors Firefox Plugin can be handy. It's a bit like a code coverage tool for CSS.
Tool suggestion: ReSharper by JetBrains. It will autocomplete CSS and rename selectors site wide from the CSS file editing window.