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.
Related
I use em as units for my fonts in combination with body {font-size:12px} (an absolute number, can be 20px or 14px...)
That works fine, but if I have multiple nested things,
like
h4{
font-size:2em;
}
h4 span{
1.6em;
}
.parent_elementofthespan span.superspan{
font-size:1.3em;
}
.basecamp3rdpartyclass h4.span{
font-size:1.9!important;
...
Now, things get pretty complicated in calculating the actual absolute font-size of .parent_elementofthespan span.superspan for example.
Is there any chance of "seeing" the absolute font-size within a tool or something besides calculating it manually?
In Chrome Dev tools
F12 > Elements > Computed > font-size
A value in pixels will be displayed.
You should use rem unit wherever possible.
rem is relative to :root font size (html element in HTML but it could be <svg> or in other cases) so no hard calculations!
In a nutshell, it's em without the cascade and 95% of the time it's what you need in your CSS.
Its compatibility is IE9+.
CSSViewer (a Firefox/Chrome extension) is way faster for checking font sizes (and other typographical properties like font weights and line heights, also color) on elements one after another than DevTools/Inspect.
Chrome extension
The original Firefox extension (has worked flawlessly for years BUT last update was 9 years ago: it may not work on Firefox 57+ coming in a few days :( RIP)
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.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
What is the performance impact of CSS’s universal selector?
Ive read that using the * CSS selector isnt ideal as it takes longer to process. However how much is this really an issue? How much longer will it take a page to be displayed if I have the following in my CSS?
#div1 *,
#div2 * {
float: none !important;
width: auto !important;
height: auto !important;
text-align: left;
position: static !important;
}
It seems to me that the connection speed and number of large assets like images is going to make far more of a difference. The work im doing is for mobile optimization but the page size (due to various libraries) is around 750KB and there is nothing I can do about this.
As a side note im aware that using !important isnt ideal too but the messy code ive inherited means its required in this case.
Read this article.
The key to optimizing CSS selectors is to focus on the rightmost
selector, also called the key selector (coincidence?). Here’s a much
more expensive selector: A.class0007 * {}. Although this selector
might look simpler, it’s more expensive for the browser to match.
Because the browser moves right to left, it starts by checking all the
elements that match the key selector, “*“. This means the browser must
try to match this selector against all elements in the page.
I recently came across this CSS selector while trying to find a way to easily space out major blog elements such as paragraphs and images. An example of its use would be something like this:
.post *+* {margin-top: 15px;}
/* or... */
.post > *+* {margin-top: 15px;}
/* if you don't want the margin to apply to nested elements */
At first glance, it seemed pretty useful. So my question is: What downsides are there to using these selectors?
Specifically:
What's the browser support like for this?
Are there any cases you wouldn't want an even margin spacing between elements in an article and if not, is it easier to declare this first and then overwrite or simply declare each element individually?
Does this have performance issues since you're selecting everything twice?
What's the browser support like for this?
Basically, IE7+ and any other modern browser.
There may be corner cases for each browser depending on what elements are actually being selected or queried with the sibling combinator +, but I wouldn't worry about those as much as the fact that the margin is being applied to just about any element that's a sibling for no practical reason.
Are there any cases you wouldn't want an even margin spacing between elements in an article and if not, is it easier to declare this first and then overwrite or simply declare each element individually?
It does seem pretty useful at first glance, but if you think about it, it'll probably be a much better idea to be more specific about what to apply the margin to. This is one rule that I can imagine will be overridden many, many times throughout the rest of the stylesheet by other specific selectors, making it quite redundant and even undesired in many cases. I can't think of any real-world use for a rule like your example.
Bear in mind that, in this specific case, vertical margins will collapse, so you only need to define vertical margins for a set of elements without having to resort to applying margin-top exclusively to all of an element's following siblings.
Does this have performance issues since you're selecting everything twice?
Actually, it's not selecting everything twice. The browser only looks at each element once, then determines whether each element follows another one under the same parent element. It doesn't care what kind of element it follows, as long as it follows another. It doesn't go around selecting every element again then compare to see if they're siblings of each other.
Now, people say that using the universal selector * in conjunction with just about any combinator causes rendering performance catastrophes, so people say that this kind of stuff should be avoided at all costs. But this stuff is hardly important at all (honestly, a selector like * + * is only a few microseconds slower than p + p), so you really don't need to worry about it. Consider the utility of the CSS rule itself first, then decide whether you really need the rule based on that.
Now with all that said (it's getting pretty late here), I would probably have rewritten the example like this, based on what I said above regarding collapsing margins:
.post > * { margin: 15px 0; }
It's probably only worth replacing the * with p if you know that the only children you want to space out are paragraphs:
.post > p { margin: 15px 0; }
Or any paragraphs within .post for that matter (e.g. within blockquotes):
.post p { margin: 15px 0; }
(* being used with the descendant selector is fair game, I'll admit; the child combinator, on the other hand, is limited to only one level of nesting, so for anyone obsessing about performance, this won't hurt at all.)
It's called the "Sibling Selector".
According to SitePoint, it's supported in all recent browsers and in IE8+. IE7 has a few limitations explained on the SitePoint page, but will mostly work as well.
It's defined in the CSS2 spec.
About the performance: a lot of CSS is overriding other selectors. That's part of the cascading nature of it. Also, performance varies so much between render engines that it's not practical to worry about performance when it comes to CSS.
You should also consider IE7 bug related to ignoring adjacent-sibling combinator (as well as :first-child pseudoclass) if HTML comment is in place of where IE7 expects to see an element. There is a workaround that removes comments as DOM nodes after page is loaded in IE7.
It's better to see a bug for yourself in Firefox: http://jsfiddle.net/kizu/btdVd/
The picture, showing the bug:
And the bug filled in 2007 on bugzilla.
The bug appears when you're adding ::first-letter pseudo-element with display: inline-block, and then change the font-size of this first-letter.
More letters in a word after the first: more extra space added (or subtracted — if the font-size is lesser than block's).
Adding float: left to the first-letter inverts the bug: with bigger font-size the width of inline-block shrinks.
So, the question: is there any CSS-only workaround for this bug? It's somewhat killing me.
I've found that triggering reflow on the whole page (or any block with a problem) fixes the problem, so I've found a way to trigger it on every such block with one-time CSS animation: http://jsfiddle.net/kizu/btdVd/23/
Still, while this fix have no downsides in rendering, it have some other ones:
it would work only for Fx5+ (that supports animations);
it still flashes the original bug for a few ms, so it's maybe somewhat blinky.
So, it's not an ideal solution, but would somewhat help when Fx4- would be outdated. Of course, you can trigger such fix onload with JS, but it's not that nice.
I don't think there's a good solution.
I have come up with a flaky solution for you though:
.test:first-letter {
font-size: 2em;
letter-spacing: -0.225em;
}
Add the letter-spacing style to the :first-letter selector in your Fiddle, and you'll find the blocks go back to roughly the right size.
Explanation:
Basically, the bug is being caused by the whole block taking its size from the font specified in the first-letter.
What I'm doing here with the letter-spacing is trying to adjust the size of this font, without affecting it's physical appearance. Adjusting the letter spacing in this way in normal text would result in the letters overlapping each other by .225 of a character width on either side.
I was initially hoping that a value of -0.25 would be sufficient -- ie a quarter of a character on each side would reduce the width of each character by half, which would be what we want because the first letter is font-size:2em, so it's twice as big.
However, the calculation isn't quite as clean as that, because the first and last characters in the string would only be overlapped on one side each, and because the first letter does in fact want to be double width, even if the rest of the characters don't.
All of this means that the exact letter-spacing value required to counter-act the bug will vary depending on how long the text, as well as the font sizes of the original text and the first letter. This is why I had to experiment a bit with the value of the letter spacing to get it working, and also explains why I couldn't get quite a perfect fit on all the text rows in your Fiddle. I would have needed a slightly different value for each block.
The value of -0.225 seems to be about the closest I can get to it being right for all your examples, but in practice you'll need to adjust it to suit your site.
Don't forget also that this is a Firefox bug, and therefore you'll need to write it in as a browser-specific hack of some sort. And be careful to keep an eye on the Firefox bug report you linked; when it does get fixed, you'll need to work out a way to keep your hack in place for users of old versions, but remove it for users with the fix.
[EDIT]
The only other working solution I've come up with is simply not to use the features which trigger the bug. ie drop the :first-letter selector, and use a separate <span> for the first letter of your text if you want to style it differently.
This is the obvious answer really, and would of course solve the problem (and would also mean that your styled first letter works in older browsers), but it would not be ideal from a semantic perspective, and more importantly doesn't actually answer the question, which is why I didn't offer it as a solution in my original answer.
I have been trying to find alternative work around for the bug as well, but the options are limited, and nothing I've tried has given as good results as my initial suggestion.
I tried a hack of making the :first-letter invisible, and using :before to display the big leading capital letter. However, this didn't work for me. I didn't linger on it too long so you may be able to get it working, but there is a problem with it in that you'd have to define the leading letter in your CSS, which wouldn't be ideal.
Another possible solution is to use the CSS font-stretch: condensed; property on the :first-letter. This would reduce the width of the first letter back to 1em, and thus resolve the width issue of the rest of the text. The down sides of this, however, are that firstly it would make the leading letter look squashed, which is probably not what you want, and secondly this style only works for fonts which support the condensed property. It turns out that this isn't well supported by the standard fonts, so may not be workable for you.
In the end, the original letter-spacing solution is still the only way I've found to really work around the bug.
This bug still exists, but some of the fixes don't work anymore. Even after triggering a reflow with an animation, the inline-block returned to the same size for me. I couldn't use the letter-spacing trick because I am already using it on the first letter, that is what is causing the problem for me. I solved the problem by adding this to the CSS for the affected selector:
-moz-padding-end: *number of pixels to compensate*;
At the moment, moz-padding-end seems to be specific to Firefox, and it can add or remove width to the end of the inline-block. Because this is a Firefox specific bug, that did the trick for me.
I know this thread is quite old now, but apparently this bug has not been fixed yet.
Using animation does work but there is a noticeable FOUT (Flash Of Unstyled Text). I was able to work around the problem by wrapping the first-letter in a span. This does work around both the sizing issue and the FOUT, it does add extra elements to the markup, so it depends on the needs of your site/application if this is the best fit.
.test {
background: rgba(0,0,0,0.15); /* For visualisation */
display: inline-block;
}
.test:first-letter {
font-size: 2em;
}
.test2:first-letter {
float: left;
}
.test3:first-letter {
font-size: .5em;
}
<h1>Inline-block with bigger first-letter</h1>
<span class="test">Broken</span>
<br><br>
<span class="test"><span>F</span>ixed</span>
<h1>+ floating to first-letter</h1>
<span class="test test2">Broken</span>
<br><br>
<span class="test test2"><span>F</span>ixed</span>
<h1>small size for first-letter</h1>
<span class="test test3">Broken</span>
<br><br>
<span class="test test3"><span>F</span>ixed</span>
<h1>small size, floating first-letter</h1>
<span class="test test2 test3">Broken</span>
<br><br>
<span class="test test2 test3"><span>F</span>ixed</span>
As of 2023, this is still happening in Firefox.
This is my solution using SASS, but you can see how to make it bare CSS:
txt-brand {
display:inline-block;
}
///Firefox only ///
#-moz-document url-prefix() {
margin-right: .1em;
white-space: nowrap;
&::after {
content: '\00a0';
}
}
}
.txt-brand::first-letter {
letter-spacing: -.11em;
}