sIFR text getting stretched vertically in IE9 - sifr

I've got a site that's using sIFR, and some of the replaced text is being stretched vertically in IE9. It's only happening in places where the text wraps 2 lines, and it fixes itself when I hover my cursor over it. The sIFR text is a link, but I'm not sure if that has any correlation.
I've tried various settings changes like fitExactly, forceClear, and forceSingleLine (though I want it to be able to wrap), and those didn't work. I've tried changing the font-size, line-height, and all other dimensions to px instead of em. innerHTML isn't being used anywhere on the page. It's frustrating that it works after being hovered on, but not before.
And I know you're probably thinking "use cufon or #font-face, dummy" but I'm stuck with sIFR for now. The client wants what the client wants...

I've found a solution,
if you try to hover with mouse cursor the text will display correct so..
I write few line of code to put in sifr-config.js
forcing flash reset "onReplacemment" callback only when IE9 is detected
you must use Jquery for browser detection or use another javascript way
see the link below:
http://www.voo-doo.net/robotphobia/2011/05/fix-sifr-ie9

Related

mobile safari: change background color of picker view (select)

Mobile Safari uses a UIPickerView for <select> elements - I'd like to change the background color of it with CSS. As you can see in the screen shot below, it's very hard to read. What you are looking at is the State <select> form element. Changing the text color or background color of the <select> element itself doesn't fix the problem.
I thought it was related to a parent element's or its own background color - but I went up the line and changed every ancestor element's background color to white and the problem persisted. Is there a prefixed style or trick to making this GUI legible? Or maybe it's just a bug.
EDIT: The gray behind the UIPickerView is filled in by mobile Safari, since the select is almost at the bottom of the page. Mobile Safari vertically centers the select above the UIPickerView and fills in the extra space below the page with the gray. The question is, how does it determine to use that dark gray? I've tried changing the body text color, and background-color of every other element on the page to no avail.
Unfortunately, there isn't a way to do it. iOS Safari takes full control of styling select lists' internal contents. Here's a reference for verification: little link.
One way to achieve this this would be to simulate the dropdown/select menu using JavaScript.
It's not very preferable, but if you absolutely require to change the default styling, then I'm afraid it's the only way to go; here's a demo that should give you an idea on how to do the simulation: another little link.

Rotate/Resize Controls behave unexpectedly when JQueryUI widgets are used with Fabric.js

I just discovered Fabric.js and though the documentation is a lacking a bit, it seems like it will handle everything I need for an HTML-based Dream Board tool I'm building. It appears that it doesn't play well with JQueryUI, though.
When I set any of my objects to be JQueryUI widgets, button, dialog box, etc...the control handles seem to be non responsive on the top half of my canvas items, and even on the bottom, the hit areas for resizing/rotating are greatly reduced, which makes the items hard to manipulate. Has anyone run into this? Is this a known issue? I checked github and have tried to search SO to no avail.
Thank you!
http://seismicdevelopment.com/test/no-jquery-uis.html - No JQuery UI Widgets...behaves how I'd expect.
http://seismicdevelopment.com/test/with-jquery-uis.html - Click 'Add Image', you'll get an image, but compared to the other page, you'll notice that the corners of the image aren't as interactive...you can move the image ok, but rotating and scaling is ver hit-or-miss.
The problem must be in offsets. jQueryUI is probably modifying height of those buttons, which moves canvas slightly down, comparing to how it was during initialization.
I explained this — and why it happens in Fabric — in more detail here.

Why doesn't the input[type=range] work after CSS3 transform?

Must use the JSFiddle on iOS to see issue :)
Developing an iOS web app, and have multi panels which are translated -480px on click (by adding a class with JQuery).
When I use -webkit-transform: translate: (480px,0); on the first navigation button, everything is fine except the input[type=range] becomes unresponsive.
I originally had this: http://jsfiddle.net/b4ung/2/
And later I added -webkit-perspective: 1; to the body. This fixed on Safari but not on iOS: http://jsfiddle.net/RLywz/2/embedded/result/
Can someone please tell me how to get the range function to work on iOS, and why it doesn't register after the translation?
Just for further note, if I change the transform to "left: -480px" the range works, but then becomes blocky when animating.
Any light would be tops, as its quite annoying (and if its a bug can someone file it 'cause I'm not a developer)
Edited to make the problem more clear, and show updated JSFiddle
I had the same problem, and I was able to hack it by setting the panel's css property to translate(0,0) when it needs to have the range working.
In order to have the animation/position right, I wrapped the element with a div and set the x position as needed and shifted the panel's translate property when the range doesn't need to be active. Hope it works in your structure.

sIFR v2 overlaping slimbox (and possibly other lightbox tools)

Just installed sIFR into the site I am building (a personal portfolio site). When using it on pages with slimbox popups, sIFR overlaps the slimbox and makes it dificult to see the image. I tried applying a high z-index to the items I didn't want overlapped, but that didn't solve anything. Here is a screenshot of what it looks like (since my site is not online yet):
http://users.sephiroth.ws/DemonicGoblin/sifr.png
Is there a way to hide the sIFR when a slimbox link is clicked, or a way to adjust the z-index for a way to it not to be always on top? This happens on the latest version of all major browsers (I couldn't test Safari or Chrome though, even though I doubt it will differ)
I ahvent been able to find any information regarding this subject, so if it has been fixed in the sIFR beta it would be nice to know. Thanks.
In sIFR 2 you need to set the sWmode parameter to "opaque". This should allow HTML elements to be displayed on top of the Flash movie.
In sIFR 3, the parameter is wmode, though you can also use opaque: true.
Thank you so much - just saved my day.
I saw that lightbox break - so did I nearly:)!!!
But what a straight forward answer and solution thanks!! again
The file in mention is:
sifr.js
and put a code like:
sIFR.replaceElement(named({sSelector:"h1", sFlashSrc: "http://localhost/ddddddd/templates/template/i_font_swf/carbon_std_swf.swf", sCase: "upper", sColor: "#86ca29", sWmode:"opaque", sBgColor:"#fff"}));
I just write it cause took me some time to remember where this setting initially was - when I did the sIFR long ago.

fitExactly not working in r-436

I just recently upgraded to 436 from 419, and have found that fitExactly will no longer have any effect.
You can see an example here:
(With 419)
(With 436)
The javascript config is in the page head.
I checked the versions in between, and the latest it works with is 419.
I could adjust the width in the Javascript configuration, but then there would be a gap left on the side of the dropcap I'm using it on, and the fact that I'm integrating it with a Wordpress theme that automatically applies sifr (other than the one in the example), meaning that each can't be adjusted by changing the width or font size.
I would much prefer to use 436, especially due to there being less page shifting, so, is there a remedy?
Thanks for your time.
If you compare the width and height of the Flash movie on both pages, you'll see that it's the same. In other words, it looks like fitExactly works fine. I wouldn't know though why Flash is clipping the rendered text.
Just to test, could you open the r436 JavaScript file, search for '419' and replace by '436', and then use the r419 Flash movie? Perhaps that provides further clues.

Resources