The latest compiled css for Bootstrap V3.3.0 (and at least the previous version) contains some unusual syntax for the line-height in a few places. Can anyone explain it? Needless to say, it causes Resharper to spit the dummy...
input[type="month"] {
line-height: 34px;
line-height: 1.42857143 \0; <<<-- here. the '\0' is what bothers me
}
You will find it around line 2408 in the css.
Also noteworthy is the repeat definition, with and without units. What browser 'feature' does this rectify?
See this issue on GitHub and this question on SO
Its a CSS hack specific to IE, it will only apply to IE10 and under. \9 would apply to IE9 and under etc... All other browsers will ignore it and keep 34px line-height.
Related
I'm having trouble adjusting PhantomJS to create a PNG file that matches the original browser presentation.
Here is the entire sample html file. It's a sankey diagram creating using rCharts and d3-sankey. (You'll need to save the file to your hard drive and view it from there.)
I'm running on Windows and using rasterize.js:
>> phantomjs.exe rasterize.js test.html test.png
ISSUE: Below is a snip of one of the text strings when viewed in a browser:
And here is a snip of the same string from the PNG created by PhantomJS:
How do I make the text-shadow go away? I've played around with various CSS attributes (text-shadow) and webkit-specific attributes (e.g., -webkit-text-rendering), but can't seem to make it go away.
Is this a setting in PhantomJS? in the underlying webkit? or somewhere else?
rCharts has an undocumented function called take_screenshot that uses CasperJS (which in turn uses PhantomJS to take screenshots of rCharts created visualizations on a given html page.
For example, I forked the example you provided, renamed it as a html file, which you can view here.
I ran rCharts::take_screenshot('http://rcharts.io/viewer/?7063641'), which results in the following screenshot. The take_screenshot function uses system commands, and work well on a Mac. I have not tested it on Windows, so YMMV.
NOTE: You will need to install the dev branch for this feature.
OK - I found the issue. It is related to browser display differences. SANKEY.CSS sets the text shadow:
.node text {
pointer-events: none;
text-shadow: 0 1px 0 #fff;
}
The text-shadow is ignored in Firefox (my default browser) and is properly rendered using Chrome (thanks #ramnath for cluing me into the browser differences!). PhantomJS uses webkit to render pages (which works properly) while Firefox uses gecko (which obviously doesn't implement text-shadow properly.) Fiddling with text-shadow in my original post didn't affect any changes - because Firefox wasn't rendering any changes and I was experimenting in the browser.
SO, the fix is to override .node text-shadow in my main HTML file. After the change, all is rendering as I prefer in the PhantomJS-created PNG.
.node text {
pointer-events: none;
text-shadow: 0 0px 0 #fff;
}
Lesson: to properly test HTML for rendering in PhantomJS on Windows, use Chrome to preview. Both use webkit as the underlying rendering engine.
I am getting following error while trying to run an html5 file on opera 12 browser :
-webkit-transition is an unknown property
-webkit-transition: opacity 0.5s ease-in-out 0s;
-----------------------^ Linked-in stylesheet mycsspage.css:21
How to resolve this?
Thanks
Sneha
If a property starts with -webkit- it means you're using some experimental code that will normally only work in WebKit-based browsers (Safari, Chrome) and cause errors or warnings everywhere else.
In noticing this error and asking the question you've done the right thing though - now you can learn a few simple things about how CSS is developed and how to use experimental and upcoming features safely.
First: why is this code "experimental"? It's because the experienced web developers and computer specialists who sit down together to plan new features for CSS are still trying to figure out how it should work exactly. Over time they try different keywords and syntaxes (discussing details like 'should it say "ease-in-out" or "in-out"?'). While doing so they also want some testing in the real world and feedback from real developers, so they encourage web browsers like Chrome and Opera to support stuff that's unfinished - but with a prefix. The prefix -webkit- then means "this is a temporary implementation, we're not sure that any other browser will ever understand the "ease-in-out" instruction because we haven't finished deciding this, but you can test it as long as you understand it's temporary and you may have to go back and fix your code later, if we change our mind".
To do this correctly, you need to do a bit of research on whether this CSS feature is still experimental. You're trying to use CSS transitions, so you might for example take a look at this:
http://caniuse.com/#feat=css-transitions
Here you see a table of browsers and versions. You see which versions require a prefix like -webkit- , -ms- , -moz- or -o- (for Safari/Chrome, Internet Explorer, Firefox and Opera respectively).
In this case, the most recent versions of Internet Explorer, Firefox and Opera support this CSS instruction without a prefix, which basically means "we think we're done discussing this now, pretty sure it's going to be like this forever. If you write just 'transition' now you won't have to come back and fix your code because we changed our mind."
On the other hand, WebKit-based browsers still require a -webkit- prefix. So what you should do is to make sure you add this instruction twice - once with a -webkit- prefix, followed by one line without the prefix. Like this:
-webkit-transition: opacity 0.5s ease-in-out 0s;
transition: opacity 0.5s ease-in-out 0s;
If you feel very thorough and want to support older Firefox and Opera versions you could also add the -moz- and -o- lines.
If you make sure the code looks like that, you can now ignore the warnings. You've dealt with the problem it was warning you against.
My site is displaying all fonts in Times New Roman even though that declaration is nowhere in my CSS.
This only happens in Safari 5.0.5 on OS X only. When inspecting a text element, it says "font-family: Times New Roman".
The fonts are displayed correctly in 5.1
What could be the problem, and how can this be fixed?
If you have no fonts declared in your CSS, The browser may try to apply its default font.
To avoid that, you may do something like:
html{
font-family:Arial, Helvetica, Verdana;
}
However, If you do have font-family declared for your element, it may be some widget or external CSS that overwrites your CSS, Try to get rid of these for a quicker debugging.
Hey there,
this time I have a quite rare issue that's occurring only in Safari 5.0.2. When using CSS3's box-shadow parameter, Safari's performance is that bad, you can't even scroll down properly or interact as expected with the site.
I have a <div class="blox"></div> which has an average size (960x320 pixels), and these are its relevant CSS settings:
-moz-border-radius: 4px; /* FF1+ */
-webkit-border-radius: 4px; /* Saf3-4 */
border-radius: 4px; /* Opera 10.5, IE9, Saf5, Chrome */
-moz-box-shadow: inset 0px 0px 140px #dfe1e2; /* FF3.5+ */
-webkit-box-shadow: inset 0px 0px 140px #dfe1e2; /* Saf3.0+, Chrome */
box-shadow: inset 0px 0px 140px #dfe1e2; /* Opera 10.5, IE9 */
I tried setting the CSS3 box-shadow with jQuery (.css()) but the outcome was the same (lag). Oh and, the border-radius does not cause this (I've discarded it by testing it several times).
So, is there any solution to this? Honestly, I am shocked that a WebKit browser such as Safari even presents these sorts of issues. I know there must be a way, since several websites use inset&outset shadows and run just fine in Safari. I found a post here in StackOverflow which mentioned the box-image as a solution.. however, that post was quite old.
I really, really appreciate your time and any support given.
Thank you so much in advance!
Chris
This is a known issue. Follow issue 22102 in the WebKit bug tracker (“-webkit-box-shadow causes awful scroll/resize/redraw performance”) to get notified when it’s fixed.
Note that the box shadow in your example has a very large radius, which makes it worse. This explains why it might seem to work on other sites — they’re just using smaller radii.
Why are you shocked? Webkit might be fast in implementing new stuff, but it does so in extremely buggy ways most of the time.
Anyway, it looks like you're trying to fake a gradient with box-shadow. Better consider using a CSS3 gradient (Moz syntax | Webkit syntax | Opera support coming soon and will follow the moz syntax with an -o- prefix) or an image background.
Also, there is no box-image CSS property. They might have meant border-image.
What is the equivalent of
-webkit-transition: opacity 0.6s linear;
in -moz?
I tried replacing -webkit with -moz, but nothing happened. I even tried extending it to -moz-transition-property/duration, but with no success.
Try it in Firefox 3.7 (Gecko 1.9).
There isn’t one. CSS animation properties like transition were pretty much invented by Apple (although I think they’ve submitted them for inclusion on CSS3), and they’ve only been implemented in WebKit so far.
There is some support in the nightly builds of Firefox though: http://blog.mozbox.org/post/2009/10/12/Some-new-demos