Is there any disadvantage in this example?
.class {
max-height: 500px;
max-height: 50vh;
}
I want to do this because if vh is not supported in some browser, that browser will apply max-height: 500px; and ignore the line of vh.
This is absolutely fine. They are cascading, so the last (supported) style with the same level of importance always wins. It is a common case to override some CSS Rules with another class, so the browser has multiple instances of the same property to choose. So why shouldn't this be allowed in the same class? I can see no disadvantages, except for the extra line of code, but if you have to support old browsers, you need a fallback.
I'm assuming you know that 500px will not always be the same width/height as 50vw/vh, so yeah, a disadvantage would be, that it may looks different in older browsers. But from a syntactic view, there is nothing wrong.
I think there is a link which can help you.
How to write css fallbacks for vh vw
If browsers encounter a property or a value that they don't understand, they ignore it and move on.
It's okay to provide a fallback for browsers that doesn't support vh or vw.
h1 {
font-size: 36px; /* Some tweener fallback that doesn't look awful */
font-size: 5.4vw;
}
There is nothing wrong in it, if Modernizr have this check already use it to check for unsupported browsers.
The metrics which you are using depends upon your window and object size. Consider both while using px and vh at the same time.
No,
The vh will have priority (cause it's the last max-height in your css file) but only if it's supported in the current browser.
But vh is supported in a lot of browser (93.19%) :
https://caniuse.com/#search=vh
So for me it's okay and I never hear about a bad use of multiple same properties in one class
Yes. There is a disadvantage. 50vh depend on viewport of the device and its equal to the 50% of viewport where as the 500px is the pixel value of device both are not equal at the same time.
secondly, if the browser support both the last one is executed i.e. 50vh.
I hope you get my point. For any query please comment. All the best.
Related
I'm encountering a very niche issue CSS issue on Safari.
I have the following CSS rule:
min-height: calc(100vh - 115.5px - 25px*2);
This works on Chrome, but Safari doesn't seem to like the combination of calc and vh. (It works if I replace vh with %, for example--but I do need to calculate based on vh or some appropriate alternative.)
Is there some way around this to make this work? Alternatively, is there another way to refer to vh that is calc-friendly on Safari?
before you use vw or vh, you should define:
html {
width: 100%;
height: 100%;
}
body {
width: 100%;
height: 100%;
}
and make sure you use spaces between + and - as you did.
Safari seems to be kind of buggy with viewport units in general, especially if you go back a version or two. The last time I tried to use vh/vw, I ran into similar issues and ended up making use of the v-unit javascript micro-lib, and it worked out very well.
CSS is rapidly catching up to javascript for things like layout calculations, but when it gets complex, supplementing your css with some light scripting often works better than CSS alone.
This is a known bug - also reported on caniuse (under Known Issues).
See this SO answer for a workaround.
when i use numbers with decimal in my css specs like this:
#UploadWrapper.OneRow #UploadList #UploadUl li div.imageDiv, #UploadWrapper.TwoRows #UploadList #UploadUl li div.imageDiv{
width: 58.8px;
height: 44px;
}
it seems, that Firefox uses the right number do calc the position but rounds the amount to thisplay it ... because it can only display it to native pixels.
Webkit browsers just takes the integer of the number (58) ...
How can i:
1. Force the Webkit browser to behave like FF? ... or ...
2. Sepecify an other width, that only takes effect in webkit browsers? I already tried
-webkit-width: but it didn't work ...
Thanks for any advice!
I don't think you can do this elegantly. In generally it's best to see pixels as atomic units that can't be divided.
Solutions:
Find another way of positioning your elements. i.e. Use percentages or make the last column 1px shorter (or whatever your design needs to allow whole numbers to be used)
Use JS browser sniffing to add a class of "webkit" or similar to the body element and then use this to apply different style rules.
I'd suggest not using the second solution as it's probably unnecessary complicated.
What should i keep for body, {font-size: 100.01%; } or { font-size: 100%; }?
what is {font-size: 100.01%; }? and is it really good to mention font-size in html{} even
If I'm using body {font-size: 62.5%;}
Edit : 3 May 2010
Today i found info about 100.01% at here - http://www.communitymx.com/content/article.cfm?cid=FAF76&print=true
This odd 100.01% value for the font
size compensates for several browser
bugs. First, setting a default body
font size in percent (instead of em)
eliminates an IE/Win problem with
growing or shrinking fonts out of
proportion if they are later set in
ems in other elements. Additionally,
some versions of Opera will draw a
default font-size of 100% too small
compared to other browsers. Safari, on
the other hand, has a problem with a
font-size of 101%. The current "best"
suggestion is to use the 100.01% value
for this property.
Is it good to keep body { font-size:100.01%} in place of {font-size:100%}
The declaration body (or html) { font-size: 100.01% } compensates rounding errors, in particular in older versions of Opera and Safari. Both would otherwise display fonts that are too small.
A relative font-size (%, em) is always interpreted relative to the font size of the parent element. So it's not a bad idea to implement kind of a initial reset in the top element, which you can achieve with body {font-size: 100%}.
Never seen 100.01% before, but it seems like some sort of browser hack that will force some browsers to ignore or calculate size correct if you use this "fix".
I wouldn't use it myself though, as errors tends to be fixed and there are often more nice ways of dealing with the same option.
html {
font-size: 100.01%;
}
100.01%, not a hack or a kludge, has been around for many years. Google "100.01%" and read up. It is as valid as 100% and does cover some territory 100% doesn't.
An initial font-size should always be declared. Set a base font-size on an outer container -- either <html> or <body> -- for it is from that container which all relative and inherited font-size values will derive. Using 100% or 100.01% makes the starting font-size equal to the user's browser preference.
Setting that base font-size to the user's browser preference gives your visitors maximum readability. Read that again, please, about the USER's preference. Your visitor will have set their browser font-size for their own best legibility and reading comfort. Your design, magnificent and fragile though it may be, is only a second-string player. Content is king, assuming you have some. But if that content is un-readably tiny, you lose. The visitor surfs on. Your design, then, has failed your needs and your expectations. Therefore, the design really wasn't all that great, was it?
Where am i doing wrong?
This is the normal print preview:
But I want to see this picture (without dragging margin arrows)
This is the css codes and preview:
Yes. It is possible to alter your margins in a page printout. The rule would look like:
#page {
margin: 0;
}
This will not work in Firefox as of now. If you check their developer reference on the #page CSS support, you can see what browsers do support #page.
The best you can do is set #page margins. Keep in mind, however, that you can and most likely will be overruled if you set margins to 0.
Thanks ! works well on chrome
#page {
margin: 0;
}
I don't think it is actually possible to do this, because you'd be overruling the defaults on the user's computer. As far as I know, a web application doesn't have the access rights to alter something like printer settings without some kind of ActiveX script in IE.
I had a similar problem a while back, and ended up having to generate a PDF on the fly using TCPDF. In the end that worked out better, because you have greater control over the layout.
I'm prevented from upgrading a computer from Windows XP to something more recent, so basically I'm stuck with IE8.
I found that on IE8, page margins will always be a minimum of 6.01mm left and right, and 5mm top and bottom. No matter what I do, even using #top-left right and centre rules inside the #page rule, it will still default to the values above.
It may be easier to create the stylesheet to take into consideration this limitation on the print size.
It may also help to put the IE hack \9 in front of the CSS class property value, duplicating the property may also help in some cases, (but won't affect the margins of the page), such as:
.aDiv {
margin: 10mm;
margin: 15mm\9; //this \9 hack will set that value only on IE8.
}
I know there are other hacks similar to this, such as \0 but I admit don't fully understand them. \9 works for me in IE8 in some situations.
What is the definitive way to mimic the CSS property min-width in Internet Explorer 6? Is it better not to try?
foo { min-width: 100px } // for everyone
* html foo { width: 100px } // just for IE
(or serve a separate stylesheet to IE using conditional comments)
You could use an expression (as suggested by HBoss), but if you are worried about performance then the best way to do this is to add a shim inside the element you want to apply a min-width to.
<div id="container">
The "shim" div will hold the container div open to at least 500px!
You should be able to put it anywhere in the container div.
<div class="shim"> </div>
</div>
#container .shim {
width: 500px;
height: 0;
line-height: 0;
}
This requires a little non-semantic markup but is a truly cross-browser solution and doesn't require the overhead of using an expression.
This article on CSS Play, by Stu Nicholls, shows the different methods for achieving min-width in IE, in all modes (Quirks, etc) and even for IE/Mac.
I've fiddled with every answer given here in the past month. And after playing with Pretaul's method (Min-width in MSIE 6), it seems to be the best alternative to min-width. No hacks or anything, just straight up compliant CSS code which takes 30 seconds to implement.
From Googling around, expressions seem to be the most popular. For me anyways, ittended to randomly lock up my browser (both IE and FF).
I dunno, I had some success with:
min-width: 193px;
width:auto !important;
_width: 193px; /* IE6 hack */
A combination of dustin diaz' min-height fast hack & How do I specify in HTML or CSS the absolute minimum width of a table cell
do your css tag as _Width: 500px or whatever.
This works pretty well...
div.container {
min-width: 760px;
width:expression(document.body.clientWidth < 760? "760px": "auto" );
}
Min-height fast hack works for me (also works for width)
The shim example is fine for forcing the browser to show a horizontal scroll bar when the container gets to a certain size but you'll notice that the content in the container will still be resized as the window gets smaller. I imagine that this is not the overall goal when trying to achieve minimum width in IE 6.
Incomplete min-width technique http://www.mediafire.com/imgbnc.php/260264acec99b5aba3e77c1c4cdc54e94g.jpg
Furthermore, the use of expressions and other crazy CSS hacks just isn't good practice. They are unsafe and unclean. This article explains the caveats of CSS hacks and why they should be avoided altogether.
I personally consider scaryjeff's post to be the best advice for achieving true min-width in IE6 and as an experienced CSS layout developer I've yet to find a better solution that is as applicable to problems of this kind.
This article on CSS Play, by Stu Nicholls, shows the different methods for achieving min-width in IE, in all modes (Quirks, etc) and even for IE/Mac.
I've provided an answer to a similar question that details the use of this technique to correctly achieve min-width. It can be viewed here:
CSS: Two 50% fluid columns not respecting min width
The technique is simple, valid CSS that can be used in almost any situation. Applied to the shim example above it results in what I consider to be correct min-width functionality.
Correct min-width technique http://www.mediafire.com/imgbnc.php/a67b2820bfbd6a5b588bea23c4c0462f4g.jpg
Single line button
button{
background-color:#069;
float:left;
min-width:200px;
width:auto !important;
width:200px;
white-space: nowrap}
Use conditional comments to reference and MSIE 6 specific style sheet, then create CSS as below.
Compliant browsers will use:
min-width: 660px;
Then MSIE 6 will use:
width: expression((document.body.clientWidth < 659)? "660px" : "auto");