I use sIFR so text looks good on Windows machines. Since Macs have great text rendering, I want to disable sIFR when a Mac is detected so I have more flexibility animating fades. I'm trying to understand this post on the sIFR wiki, it suggests how this might be done, but the code in the sifr.js is dense and I'm not at all sure where or what to add or remove.
http://wiki.novemberborn.net/sifr/How+to+use
"If you want to enable/disable sIFR for a specific browser, you can use the UA object as described below and you'll have to edit the following code in sifr.js:
if(typeof sIFR == "function" && !sIFR.UA.bIsIEMac){
sIFR.setup();
};
In this example sIFR is disabled for IE/Mac. Remove the && !sIFR.UA.bIsIEMac part to enable it again. You can also add other browsers here."
Can anyone help me implement this? (I assume that the above example is meant to be just a fictional example since IE hasn't run on Macs in ages and ages...)
Thanks for looking!
If you're using sIFR 3, you should try something like this instead.
Add following line of code in sifr-config.js before sIFR.activate() command.
sIFR.ua.supported = sIFR.ua.supported && !sIFR.UA.bIsIEMac;
sIFR.activate(yourfont.swf);
I had a similar problem where I had to deactivate sIFR for IE9 and this trick worked for me.
or try this this
sIFR.ua.supported = sIFR.ua.supported && (!sIFR.ua.ie || !sIFR.UA.bIsIEMac);
sIFR.activate(yourfont.swf);
Related
Something that drives me nuts in the developper tools of Chrome (106) and Firefox (105) is the fact that whenever some text logged to the console via console.log(text) happens to contain a hyperlink, this link is not only turned clickable (I can live with it even when I usually prefer to have just plain text) but is abbreviated, if it is a long link. So when I want to control what precise link is in some variable, I cannot just write e.g. console.log(img.src), because some of the interesting information of the link is hidden.
You can try yourself with
var href = 'https://stackoverflow.com/search?q=%5Bgoogle-chrome-devtools%5D+%5Bconsole.log%5D+%5Bfirefox-developer-tools%5D+%5Bhyperlink%5D+automatic+detection&someMoreStuffTomakeTheLinkLonger';
console.log(href);
In both, Firefox and Chrome, the output for me contains some '...', e.g. in Firefox I obtain as output:
https://stackoverflow.com/search?q=%5Bgoogle-chrome-devtools…link%5D+automatic+detection&someMoreStuffTomakeTheLinkLonger
thus hiding the part after "-devtools". (Chrome hides a slightly different part). The console is mostly a debugging tool. I log things because I want to see them, not hide them. I always need to either hover with the mouse and wait for the tooltip (doesn't allow me to copy fractions of the link) or to right click copy the link and paste it somewhere where I can see it completely. Or take a substring to remove the "https://" in the front. But note that the variable isn't necessarily a single hyperlink, but can be any text containing several such hyperlinks. I didn't find a way to force console.log to just print plain text all content. Did anybody meet this problem as well and find a workaround?
I made this a community wiki answer, because the main insight is not from myself but from the comments. Feel free to improve.
The console.log() function allows several arguments, which allows also a formatted output similar to printf in some languages. The possibilities of formatting can be found in the documentation of console.log() on MDN. In any case, this formatted output provides a solution at least for Chrome, as #wOxxOm pointed out in the comments:
console.log('%O', href) // works in Chrome
This is rather surprising, because %O is described at MDN as
"Outputs a JavaScript object. Clicking the object name opens more information about it in the inspector".
It seems there is no 'clicking' in Chrome when the object is a string.
There is also %s for string output, but this just gives the standard behavior of replacing links in both browsers. And for Firefox none of the above two formatting options works. There one really has to replace the protocol "https://" by something that is not recognized as link. A space behind ':' seems enough, so "https: //". It turns out, that one can also insert a formatting string "https:%c//", which can even be empty, and thus yield an output which is the complete link and can be copied as well:
console.log(href.replace(/(https?:)/, "$1%c"), ""); // works in Firefox
In particular the FF solution is cumbersome, and there might also be several links within one console-output. So it is useful to define one's own log-function (or if one prefers, redefine console.log, but note the remark at the end)
function isChrome() {...} // use your favorite Chrome detection here
function isFirefox() {...} // use your favorite Firefox detection here
function plainLog() {
const msg = arguments[0];
if (isChrome() && arguments.length == 1 && typeof msg == "string") {
return console.log("%O", msg);
}
if (isFirefox() && arguments.length == 1 && typeof msg == "string") {
const emptyStyle = ""; // serves only as a separator, such that FF doesn't recognize the link anymore
const reg = /(https?:)\/\//g;
const emptyStyles = []; // we need to insert one empty Style for every found link
const matches = msg.matchAll(reg);
for (let match of matches) {
emptyStyles.push(emptyStyle);
}
return console.log(msg.replace(reg, '$1%c//'), ...emptyStyles);
}
return console.log(...arguments);
}
For browser detection isChrome() and isFirefox() see e.g. here on SO.
One can of course extend the redefinition also to the other console functions (console.info, console.warn, etc.)
The downside of the redefinition of console.log is that usually every output of the console shows also the last entry of the call stack as a practical link to the source of the logging. But due to the redefintion, this link is now always to the same place, namely the file and line number where plainLog() is defined and calls console.log(), instead of the place where the new log command plainLog() was called. This new problem is described on SO here, but the solution (see comment) is again a bit involved and also not completely satisfying to serve as a replacement for the built-in console.log . So if links appear only rarely in the logging, it's probably better to switch to the redefined plainLog() only for these links.
I want to get a value (content) from the CSS of a pseudo element (::before) while inside a test made using WDIO and Appium for an Android hybrid app because the designer has stored the current responsive-design state there. So my tests would know which layout (elements) to expect.
Multiple answers to related questions (1; 2; 3) indicated that using .getComputedStyle() might be the only solution. But this does not seem to work in my tests. The error is window is not defined for window.getComputedStyle(...) or document is not defined if I use document.defaultView.getComputedStyle(...). Also selectors themselves can't address pseudo-elements it seems.
Example of one of my many attempts:
document.defaultView.getComputedStyle($('body'),'::before').getPropertyValue('content')
Question: Do I need to somehow import window or document to my test? Is there some other way to get window or document from inside the test?
Ultimately: how can I get the content value of ::before of the <body> of a hybrid Android app?
Thanks to Jeremy Schneider (#YmerejRedienhcs) & Erwin Heitzman (#erwinheitzman) for help!
One solution is to use the execute function:
let contentMode = browser.execute(() => {
let style = document.defaultView.getComputedStyle(document.querySelector('body'),'::before');
return style.getPropertyValue('content')
});
Alternatively maybe something could also be done with getHTML.
When we print pages from our web site, which is based on Bootstrap 3, they are printing on some browsers showing the mobile version. I have Googled to try and find a good solution, but not really found anything that works.
Using the same CSS for the screen and adding the "print-hidden" class to specific DIV's our pages look fine using Safari on a Mac, but using Chrome on the Mac or Firexof and Chrome on the PC the print preview shows the mobile version.
Is there an easy way to tell the browser that the viewport width is a regular screen not a phone (XS), or do we have to incorporate a lot of complicated grid changes etc?
Adding a print media query worked for me. This is what I finally stumbled onto.
#media print {
#page {
size: 330mm 427mm;
margin: 14mm;
}
.container {
width: 1170px;
}
}
The 330mm and 427mm dimensions were just what seem to fit for my 1170px breakpoint. (They're also the 8.5/11 ration.)
EDIT: As #tony-payne said, this likely only works for Chrome. In my use case, that was fine. Just added a script with a warning about printing if not in Chrome.
<script>
(function() {
var isChromium = !!window.chrome;
var beforePrint = function() {
alert("Printing is optimized for the Chrome browser.");
};
if (window.matchMedia) {
var mediaQueryList = window.matchMedia('print');
mediaQueryList.addListener(function(mql) {
if (mql.matches && !isChromium) {
beforePrint();
}
});
}
window.onbeforeprint = beforePrint;
}());
</script>
Something that worked for me...
in bootstrap grid.scss find:
#include make-grid(xs);
then add below:
#media print {
#include make-grid(sm);
}
This is a known issue that's mentioned in the official docs:
Printer viewports
Even in some modern browsers, printing can be quirky. In particular, as of Chrome v32 and regardless of margin settings, Chrome uses a viewport width significantly narrower than the physical paper size when resolving media queries while printing a webpage. This can result in Bootstrap's extra-small grid being unexpectedly activated when printing. See #12078 for some details. Suggested workarounds:
Embrace the extra-small grid and make sure your page looks acceptable under it.
Customize the values of the #screen-* Less variables so that your printer paper is considered larger than extra-small.
Add custom media queries to change the grid size breakpoints for print media only.
Okay, if I could offer a bounty for this I would - I offer virtual karma.
As mentioned in the title I have an .NET/MVC4/Jquery Mobile/Knockout website. On the index page there is a button
<button data-bind="click: getResults" data-theme="f">Search</button>
which calls a javascript function
$.mobile.navigate("/results?option1=a&option2=b", { transition: amw.transitions.slide });
This works great on all browsers and devices except Chrome/iPhone. As far as I can tell the version of Chrome or iOS does not matter. The resulting URL in the address bar is
iPhone/Chrome: http://www.mywebsite.com/#/results?option1=a&option2=b
Other Devices: http://www.mywebsite.com/results?option1=a&option2=b
I have put alerts throughout jQuery mobile to try and figure out what is going on (if someone knows a way to debug chrome on iOS let me know) and I cannot see where the extra # is being added.
This may not seem like a big deal but the url ends up being passed on to a downstream service that really does not like the extra #.
I can put in a hack at the call to the service to strip out the # but I would really like to figure out what is happening.
The only suspect line I can find in jQuery mobile (1.3.0) is line #2298
// if the hash is included in the data make sure the shape
// is consistent for comparison
if( data.hash && data.hash.indexOf( "#" ) === -1) {
data.hash = "#" + data.hash;
}
But I am not sure what this does or why it would occour only on Chrome/iPhone.
so StackOverflow people - what is going on?
Thanks.
I'm using sIFR 2.0.6 with the sifr.js file from 2.0.7 to resolve this issue: http://novemberborn.net/sifr/2.0.7.
In all browsers, before overwriting the sifr.js file, the sIFR displayed with initial caps. With the new sifr.js file in place, the text is all uppercased.
This is the only code I am customizing:
if(typeof sIFR == "function"){
sIFR();
sIFR.replaceElement(".sifr-container",
named({sFlashSrc: "frutiger.swf",
sColor: "#042e66", sCase: "lower",
sWmode: "transparent",
background-color: "transparent"})); };
sCase doesn't appear to be doing the trick. How else can I control the uppercasing?
Thanks!
Veda
You can't have background-color like that in the replacement syntax. You sure that's correct?
Try inspecting the Flash movie's embed element to see if the text is uppercase or normal case when going into the Flash movie. You might want to try recreating the Flash movie as well.