Are there are CSS compressors online which do not remove any of the CSS browser hacks.
E.g: Using: cleancss.com it makes no difference which options I set it will always remove the *display for IE display inline-block hack.
a {
border-radius:5px
display: inline-block;
*display: inline;
zoom: 1;
text-shadow: 0 2px 3px rgba(0,0,0,0.4);
-moz-border-radius:5px;-webkit-border-radius:5px;
}
CSS Compressor and Clean CSS usually work for me, although I prefer to use a different stylesheet for all previous versions of internet explorer. It is usually better to keep previous browser supporting css seprately. Or keep hacks in a seprate file and appened it to the compressed css.
In your case, however, the compressors do remove *
I do not know any online compressors which preserve the hacks, however, I can offer workarounds.
A solution would be to use hacks on selector rather than on attribute.
Here are a couple of examples :
* html #uno { color: red } /*IE6 and below*/
*+html #dos { color: red } /*IE7*/
Check here about the other hacks available : http://paulirish.com/2009/browser-specific-css-hacks/
If that does not work for you another workaround, might be a little tiresome, but before compression, add some unique value before a hack like
#uno {#HACK#display:inline;}
and then after compression using a text editor replace all #HACK# with *
This one worked for me using your test code - http://www.cssdrive.com/index.php/main/csscompressor
As did - http://iceyboard.no-ip.org/projects/css_compressor, http://www.refresh-sf.com/yui/ and http://tools.arantius.com/css-compressor
It might be worth googling your question before you actually post it on here. I did a search for "css compressor", opened the first 6 results and found those four all compressed your code without removing any of the hacks.
stackoverflow isn't supposed to be used to ask something you're too lazy to search for yourself.
Any of these four five online minifiers do their work in way you satisfied
http://www.creativyst.com/Prod/3/
http://www.cssdrive.com/compressor/compress.php
http://iceyboard.no-ip.org/projects/css_compressor
http://tools.arantius.com/css-compressor
http://www.cssdrive.com/index.php/main/csscompressor/ (thanx to #JFK)
And also a smart tool (developed and used by russian Yandex) has both online and back-end versions
http://css.github.com/csso/csso.html
Try Devilo.us, which is based on CSSTidy. You can select exactly how much it compresses and how.
http://css.github.com/csso/csso.html — this one worked for me. It is not only trim unused symbols, but also remove duplicate rules, and group selector if in help's make size smaller.
It is online version of following tool: https://github.com/css/csso
Related
This is part of a css I'm working on:
.center-part-3 { #position: relative; #top: -50%; }
I have never seen that type of hash sign usage. What is it for?
Theorically is a hack for IE7:
But here you have a comprehensive list of browser which fails or pass that hack. IE is not in the list (neither in the list which pass or fails), but add other browsers to the fail list.
As all CSS hacks, it abuses the fact that some browsers will use the rule and other will not. Here's a little reference.
I am trying to obtain a dashed table border, which has rounded edges (using border-radius). I have achieved this in all other browsers, but I know it is a bug in Firefox, and will never display properly. See the problem I have here.
I am wondering if it was possible to have Firefox alone displaying a solid line, rather than a dashed line, whilst leaving the other browsers to display a dashed one.
Essentially,
If Firefox,
border: 2px solid #000000;
-moz-border-radius:10px;
If any other browser,
border: 2px dashed #000000;
-webkit-border-radius:10px;
border-radius:10px;
I am fairly new to CSS and haven't dealt with browser specifics yet. If anyone could help (or point out problems to this method!) then I would be very grateful.
Thanks
If FireFox is bugging out, it may be worth going down the route of images for firefox.
You could have some classes:
.tr, .tl, .br, .bl {
display: none; /* Don't show for normal browsers. */
}
#-moz-document url-prefix() { /* Activate for FF. */
div { /* Probably best to tie this to a class / id. */
position: relative;
}
.tr, .tl, .br, .bl {
display: inline;
position: absolute;
}
.tr { /* top right */
background-image: url("curved_top_right.gif");
top: 0;
right: 0;
}
.tl {} /* top left - Use .tr as a ref */
.bl {} /* bottom left - Use .tr as a ref */
.br {} /* bottom right. - Use .tr as a ref */
}
Then in your Html
<div>
<div class="tr"></div>
<div class="tl"></div>
<div class="br"></div>
<div class="bl"></div>
</div>
Not ideal but might help you as FF is bugged.
You can do this a few different ways.
You could add a conditional stylesheet for firefox. This is a little overkill for just a couple styles.
You could use a CSS hack. This is not the best method since it relies on a browser bug (that could be fixed).
You could use a javascript or PHP function to parse the user-agent and append the os, browser, and version to the body or html tags as classes. Then you can write the styles with the correct class.
You could submit a bug report and pray.
Hope this helps! Good luck!
The short answer is no, that's not really possible.
The ideal solution is for Firefox to fix the problem and the issue to just go away. It looks like a fairly obvious problem, so I would assume that the Mozilla team know about it; it might be worth your time checking the Firefox issue tracker to see if they've got a ticket for it and whether it's had any work done on it. Given their rapid release cycle, there's a chance it may be fixed relatively soon, you should check this -- one thing you don't want to do is spend ages fixing your site to work around it, only to find it's a non-issue by the time you've done the work.
Having said that, the effect does appear to be deliberate by the browser: I recall that earlier versions of Firefox did show dots on rounded corners, so there may be some sensible reasoning behind it. I agree it's not ideal though. But if it's a standard feature of the browser, why not just run with it and let Firefox users have it the way Firefox wants to show it? (it doesn't look that bad, does it?)
On the flip side, of course, a question that might be asked is that if you're happy to have a solid border for Firefox users, why not just make it solid for everyone? That would seem to be the simplest answer.
Assuming you do still want to resolve it, in terms of work-arounds, I would strongly advise you to shy away from browser hacks or user agent parsing; both these solutions are brittle and could lead to problems. Obviously, in this case, the worst that is likely happen is the wrong border being shown, but nevertheless, you should be wary of both techniques.
One suggestion would be to try out border-image instead of border-radius.
border-image is a relatively new and little-used CSS feature, which allows you to construct your borders using images. (you'd never guess from the name, right?)
The beauty of border-image is that you can do pretty much anything you like with your border. If you want a specific dotted pattern, then just create an image with that pattern of dots; problem solved.
The syntax is a bit fiddly, and it works best with SVG images, but I'm sure you'll get it after a bit of experimentation.
As you can probably tell, it's a very powerful feature. The main reason it's little-used is because it's new. This means it doesn't have great browser support, but for you that really shouldn't matter because you'll be drawing borders that look relatively close to the standard border-radius effect, and you can use the standard border-radius as a fall-back. The one browser that you do want to affect (Firefox) does have support for it, so it should solve the problem.
Yes, I agree, it's a slightly complicated answer to a simple question, but it may be a way to make it work reasonably consistently across all browsers. Worth a try anyway.
When I first started writing CSS, I was writing it in an expanded form
div.class {
margin: 10px 5px 3px;
border: 1px solid #333;
font-weight: bold;
}
.class .subclass {
text-align:right;
}
but now I find myself writing css like this: (Example from code I'm actually writing now)
.object1 {}
.scrollButton{width:44px;height:135px;}
.scrollButton img {padding:51px 0 0 23px;}
.object2 {width:165px;height:94px;margin:15px 0 0 23px;padding:15px 0 0 10px;background:#fff;}
.featuredObject .symbol{line-height:30px; padding-top:6px;}
.featuredObject .value {width:90px;}
.featuredObject .valueChange {padding:5px 0 0 0;}
.featuredObject img {position:absolute;margin:32px 0 0 107px;}
and I'm beginning to worry because a lot of the time I see the first form done in examples online, while I find the second form a lot easier for me to work with. It has a lower vertical height, so I can see all the classes at a glance with less scrolling, the tabulation of the hierarchy seems more apparent, and it looks more like code I'd write with javascript or html. Is this a valid way of doing code, or to keep with standards when putting it online should I use the vertical form instead?
Well, here is what say the most :)
summary:
css-tricks.com ran a poll. By a margin of roughly 3 to 1, most people preferred multi-line over single line css styles.
I personally prefer the first style. I like things that are easy to read and I don't mind scrolling. The dense nature of the second style slows down my reading, my ability to pick out the items that I'm interested in.
There certainly are trade offs to be considered with CSS due to the file size. CSS can be compressed. I find the size of CSS files to be the least of my worries with the sites I've built so far.
Ultimately, the important thing is that whichever style you choose to use is to be consistent. That consistency will make your life simpler when you have to update your CSS or when another developer has to update your CSS.
Indicating the hierarchy using indentation is not a bad idea. However, you should be careful that you don't fool yourself. In your example, you may be assuming that .scrollButton is always within .object1. But CSS doesn't obey that rule. If you used a .scrollButton class outside of .object1, it would still get the styles.
I dont know about you but I like the vertical mode during dev as it is far more easier to read for me.
However, in prod, you wanna compress your css to reduce payload and hence, the second style makes sense. Mostly, you would be using some CSS compressor to do this.
i like to write css in multi line. because this is easier to write and read. we can find error as early as possible and a look of view is nice with indentation . mostly when a designer work with css and gave to developer to develop site than developer can understand easily.
so i think multi line css is better way to work.
I personally find both of your examples hard to read, especially the second one.
Multi-line is easier to follow, and indentation can be misleading as CSS is not necessarily applied in that way. Your indentation may lead you to believe it is.
I prefer the basic tried and true method of multi-line, with reasonable/logical order:
div.class
{
margin: 10px 5px 3px;
border: 1px solid #333;
font-weight: bold;
}
.class
{
text-align: center;
margin-left: 10px;
}
.class .subclass
{
text-align:right;
}
Takes up a little more space and requires a little scrolling to take in, but is easy to follow. Those worried about optimization can always use CSS shrinking tools for production CSS files.
In the end as long as you are very consistent with your work and across a team (if applicable) then no answer is more correct.
I prefer the second style, but be aware that it's a style. In the same way that some people prefer
function (arg)
{
body();
}
to
function(arg){
body();
}
I don't get it, myself. The argument is "it's easier to read", and my response is consistently "... for you". As a note, I get the feeling that this is why so many examples use the more-whitespace version; it has the reputation (if not confirmed property) of being easier to read.
Pick the one you like and stick with it. If you have a team to cooperate with, try to get to consensus, or barring that, write some auto-formatting scripts and stay out of each other's way. It's not like it's terribly difficult to mechanically transform one into the other.
The style you write in is your choice(I prefer multi line) but as Rajat said you want to remove any extra whitespace after dev. Anytime you can reduce file size and payload you are doing your site and your visitors a favor.
I think it also depends on your editor. I use multi line formatting and condense every definition with Vim's folding (I set up folding marks to be { and }) so I get one tag/class/id per line, expandable when needed.
Using comments to identify "sections" I get a very clean look with minimal vertical scroll while maintaining the readability of multi line on expanded definitions.
I just want to point out that Textmate has an option that allows you to easily switch between these two styles by selecting an area and pressing Ctrl-Q/Ctrl-Alt-Q to expand/collapse. As a consequence I have come to find that I prefer my CSS collapsed unless I am writing or deep debugging a specific section. But, with the ability to easily switch between he two I see that both ways are useful for different circumstances.
I prefer multiline right up until we deploy. At that point I want it minified.
Perhaps, when you have multiple selectors and one rule, like this:
#header li a, #header li span {
display:inline-block;
}
So, I prefer to do:
#header li a,
#header li span {
display:inline-block;
}
I've always liked this style:
#something1 {
color : #ffffff;
background : #000000;
}
#something2 {
color : #000000;
background : #ffffff;
}
But yo answer your question: As long as it functions the same way, there is no "proper" or "best" way to format your code. Use a style your comfortable with.
I'm trying to remove the blue "halo" outline that form elements have in Firefox on OS X. Using CSS, I can remove the halo in Safari on OS X, via:
input {
outline: none;
}
But this seems to have no effect in Firefox, nor does the -moz-outline property.
Another option, that takes care of all of the 'halo' is this:
*:focus {outline: none;}
I guess you could add an !important if you wished, but I haven't run into the need yet.
:focus {outline:none;}
::-moz-focus-inner {border:0;}
I'm going out on a limb since I don't have OSX to test it... but does removing the border work?
input {
border: 0;
}
I believe the style of all the form elements are stored in the forms.css file. In OS X, I think it is located here:
/Applications/Firefox.app/Contents/MacOS/res/forms.css
You may want to browse through that file and see if there is any obvious CSS that is affecting the appearance you are seeing. For example, on Windows the input element has -moz-appearance: textfield;, which I couldn't find any documentation on, so perhaps there is some "native" -moz-* style on those fields that is controlling the glow, something you could possibly override.
The other thing to try might be to override everything in that file by changing the input definitions to input2 or something (after making a copy of course). Then you can see if you can get the glow to stop at all by manipulating the default CSS.
Once you've determined you can make it stop (if you can), you can add styles back in a bit at a time until you find the one that causes the effect you don't want. You can probably speed up that process by eliminating styles from your testing that obviously aren't related (e.g. - line-height: normal !important; is almost certainly not responsible for a blue glow around the fields).
Maybe you have an active user style sheet in your machine creating this behaviour. Some add-ons do this (to make the focus more obvious).
Look into the firefox's chome forder (in your user files)
Alternatively try with
input {outline: none!important;}
Also
The Stylish plugin has a style for this, maybe you have it installed?
There are greasemonkey script that do this. If you have it installed, disable it
They both take precedence over the !important attribute.
So: you have several places to look into
* User stylesheets
* Stylysh
* greasemonkey
* anothes add-on
One of those must be forcing the outline
I went through the various suggestions made here, but none seemed to be able to fully address the problem. By defining a custom border style, i.e.
border: 1px solid #000;
I'm able to get rid of the focus halo, but this obviously alters the look of the input element. border-style: inset; seems to most closely resemble the "native" look, but it's still not quite right, so as far as I can tell right now, you can either suppress the halo, or have a natural looking input.
I believe this is what you are looking for:
input:focus { outline: none; }
For IE 6 we have plenty of bugs to bug us as a designer.
incorrect box model etc etc.
i have searched for fixes via JavaScript and found
[link text][1]
IE7.js
IE7 is a JavaScript library to make Microsoft Internet Explorer behave like a standards-compliant browser. It fixes many HTML and CSS issues and makes transparent PNG work correctly under IE5 and IE6.
but do we have real life saver other than javascript via css.
Ways to deal with IE6 bugs with CSS? Sure.
See: http://www.quirksmode.org/css/condcom.html
for conditional comments
There are other ways, such as adding some specific characters in some CSS properties that get ignored in some browsers but not in others.
However, in some cases, web designers should be very cautious when using these.
The alternative is to live within the IE 6 world of bugs and design your pages to look right despite them. You can serve up different css for your IE6 clients, or even different html if necessary, depending on your design. In some cases, you can use one CSS file that will mean different things to IE6 clients, but that technique is problematic with respect to IE7 and 8.
this link is also handy one
How do you deal with Internet Explorer?
I never knew this - thanks svinto
"IE6 doesn't have the incorrect box model unless you have the wrong doctype. – svinto"
There are some simple stylesheet hacks that can modify the presentation in various internet explorer versions to solve your CSS problems. For example these three:
Simplified box model hack for IE4, IE5, IE5.5:
div.values { margin: 10px; m\argin: 20px; }
star html hack for IE4, IE5, IE5.5 and IE6:
* html div.values { margin: 5px; }
star first-child+html hack for IE7:
*:first-child+html div.values { margin: 5px; }
PNG transparancy issues could be solved with solutions like this:
<div style="width:50px;height:50px;filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(src='/images/logo/logo.png');">
<img src="/images/logo/logo.png" height="50" width="50" alt="" style="filter:progid:DXImageTransform.Microsoft.Alpha(opacity=0);" />
</div>
Great info so far but one thing to note is that IE7.js doesn't fix pngs in all cases (at least last I looked). For instance, you won't be able to tile a background image with transparency.
In the case of DXImageTransform you may find that when this is applied to elements that contain links, those links are no longer 'clickable'. You can sometimes fix this by giving the parent element that has the transform applied to it static positioning and to position the child anchor element e.g.,
h2{
position:static;
zoom:1;
filter: progid:DXImageTransform.Microsoft.AlphaImageLoader(src="/images/mypng.png", sizingMethod="scale");
}
h2 a{
position:relative;
}
<h2><a href="" >a link!</a></h2>
If you have to do this sort of garbage put it in a separate stylesheet and control loading with conditional comments. If the design is of any complexity try you best not to support ie6 or <. If you can't avoid doing it, charge more ;). Sometimes that is enough to persuade someone that supporting ie6 isn't "worth their while".
why don't you try FireBug Light for IE? It's not as powerful as FireFox FireBug but can be helpful
Many bugs can be worked around in CSS using conditional comments or CSS selector hacks. But there are some bugs that CSS hacks alone cannot handle such as IE6's .multiple.class.selector.bug
There's another quick and dirty hack for IE6 styles
for e.g.
You can define the CSS as;
.divTitle
{
padding: 5px;
width: 600px;
_width: 590px;
}
All the other browsers picks up 600px as the width value & IE6 overwrites it & take 590px;
I've tested this in IE7 & FF as well.
Also you may want to check this link;
link text