I appear to have uncovered a dilemma, and I wonder if anyone else knows about it. It would appear that significant use of webkit effects to replace JQUERY functions for CSS3 enabled browsers appears to crash mobile safari to the desktop.
Has anyone else encountered this problem / a solution for it. Or is it caused by someone else.
I'm encountering a similar problem. In my case, applying -webkit- tranforms or transitions on hundred's of dom elements causes mobile safari to crash on ios5. interestingly enough, when I test on an old iphone 3g, (ios3) mobile safari does not crash.
I know this has something to do with the -webkit- prefix, because I'm using SASS for the css, and commenting out the webkit line on my 'browser-prefix' mixin, which is responsible for adding the webkit prefix to all the css declarations, fixes the problem.
I've tried to override the webkit prefixs by setting all the -webkit- values to 'none' within media queries, but it seems that the crash happens even before the values get overridden.
I'm also certain that it has to do with the amount of DOM elements on the page, since this page with lots of elements crashes, http://dev.moovylist.com/jasiu
whereas this page with the same css, but less elements, does not crash.
http://dev.moovylist.com/suzy
My only solution thus far is to load a seperate webkitless stylesheet for the iphone, so that the iphone never sees the webkit prefixes.
Related
I'm part of a web development team that is building websites using the Angular (1.x) framework. After a recent update to from Chrome 52 to Chrome 53, we've noticed one of our sites to become unresponsive.
The site in question is: https://www.slimnaarantwerpen.be/nl
The tab will become unresponsive when you resize the page (scale down, then scale back up) or when you toggle some of the map layers. (For example: Taxi) The Dev-tools are also unresponsive, so I'm unable to debug this issue...
This behaviour only occurs on Chrome 53.x.x on OSX. I've tested the above on Chrome 53.x.x on Windows and everything runs smoothly. Safari and Firefox also don't cause issues.
I can also confirm that this site runs correctly on Chrome 52.x.x, as I've run the site on that browser before updating to Chrome 53.x.x. I also used several testing laptops using 52 to confirm it's working, only to update them to 53 and notice the issue...
Does anyone have an idea if this is a common Chrome 53 issue? I read that changed some things under the hood to improve performance. What's the best way to contact Google regarding this issue?
The problem was that an element inside an ng-if had overflow: scroll in combination with height: 100% applied to it. Apparently, Chrome 53 (OSX) does not like that...
Removing either and changing the styling resolved this issue.
I hope they fix this soon, but in the meantime I hope this answer can help anyone who has a similar problem. :-)
EDIT: This issue also seems to be OSX 10.11-specific, as this does not happen on OSX 10.10.x
I am using Sencha Touch 2.4.1, with the example app generated by "sencha app generate", I got the production css file with size over 800k, it is too big for mobile users even with 3G intenet, even though it can be cached after the first visit.
How can I reduce the css file size?
Try these links and follow the steps first:
http://www.sencha.com/blog/4-tricks-for-smaller-css-in-touch-22/
http://www.ladysign-apps.com/developer/category/css/#.VGL8SYfTYUU
http://druckit.wordpress.com/2013/08/12/sencha-touch-2-theming-apps-for-multiple-devices/
Google Chrome Audits is also useful as Tony mentioned, as when you run it it can show how much CSS is unused. You have to be careful with that one though as there may be some rules there that are specific to compatibility with other devices, and it does not seem to be that accurate with Sencha apps as my app is clearly using styles it mentions are not used.
I would suggest also downloading the Sencha Touch app inspector for Chrome, there may also be some features in there. There is an option in that that can tell you if you are over-nesting items (the side tab on the right hand side).
You can go even further by downloading the free tool ImageOptim (if you are on a Mac, there are probably similar tools for windows). It reduces PNGs and JPGs down quite significantly, without compression as it removes unnecessary metadata etc. I even tried it on the app icons and loading screens that Sencha provides and it reduced the sizes of each by around 18%.
:-)
You could always use a css minifier such as http://cssminifier.com/
I would think that would save you some valuable space :)
I'm looking into the file upload on IOS6 and know that this is possible with the usual link:
<input type="file" accept="image/*" capture="camera">
Altho, the most tutorials and issues I can find are mostly about the upload function. In my case I need to be able to take a picture inside mobile safari with the build-in camera.
I have set up a page to test this (no code, only the link I posted above), and when I take a picture the app (camera app) crashes without actually saving my picture. Is this normal behaviour? Do I need to add some code to upload the picture first? Altho this last thing doesn't make sence to me, since you need to add an already saved picture to a file upload link.
Any help in this would be greatly appreciated :)
You should not need anything more in the code to avoid crash. It should work the same as choosing a picture from the library. I have tested this on an iPhone 4S with iOS7 and my Safari crashes too. It does not crash every time if I take a picture with the front facing camera (smaller picture?). It also works if I only load the picture from the photo library.
This is a bug in iOS I think. I managed to go around it by restarting my phone. Sadly there is not much we can do on the web side of things, except inform the user that the feature may be buggy.
Probably the best recommendation, until Apple provides a fix in a future update, would be to caution your user to close down the rest of their Safari tabs. (This lowers the memory usage and prevents Safari from crashing when doing the 'Take Photo' path through file upload).
I have heard that EXTJS is a browser independent javascript library. How does extjs make itself browser independent? When I open up the library classes, I do not see any code like :
if (IE)//do this;
else if (FF) // do something else;
Is my understanding correct that extjs is browser independent?
In addition to sha's point, I'm aware that ExtJS uses conditional checks for browser features and selects whether to use things like images, or css for particular visual effects.
Two examples of this would be that it manages to produce rounded corners on it's widgets in IE6 via images, but in anything which supports it, it will use 'border-radius' in CSS.
This is also true with gradients in widgets, which are rendered as images in older browsers, but use CSS3 gradients where supported.
As a rule, from what I've seen, ExtJS uses 'feature detection' to work out what your current browser supports and responds appropriately. A further example of this would be it's charting classes, which render as SVG if supported, or VML on older browsers.
There are some classes in ExtJS you can use to perform feature detection if you wish to do anything specific outside of it's in built in actions too. I'd imagine it uses these under the hood to make decisions about what to render.
That aside, it should be noted that every now and again, you can notice odd discrepancies between browser versions, usually annoying little visual effects, like a scrollbar being present in one browser an not in another, this could however just be a symptom of other code, but I know we've seen a few little quirks from time to time when testing accross IE8, IE9 and Chrome for example.
It is browser independent. As far as I know they have some different CSS definitions for different browsers. If you want to see is there any difference in the JS code you will have to look deeper - probably at some ExtJs core files.
We've been using it so far on IE, FF, Chrome, Safari, Mobile Safari etc.
let's assume I have a so called 2.0 app, compatible from IE6 upwards. The app uses quite complex CSS and is driven by heaps of JS. It works, very well it does.
Now let's assume there is a client who own a strangely coded site, archaic in ways, and forces IE7 emulation through this wonder of a tag:
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />
Now, he desires to use my app, which is injected in his code using a simple external script call. It works, but not so under the IE7 emulation - obscure bugs from Hell start appearing, not even overflow hidden works properly. By itself the app does work in IE7, but as it turns out, the IE7 emulation is not the same as IE7 and has it's own set of fancy issues.
Turns out the client is unable to strip the emulation meta tag, so I'm left with I don't really know. Does anyone know of ANY WAY I could overpower the rendering mode set in the page header or would there be some other suggestions?
My utmost thanks for anything usable.
Perhaps you could make a wrapper for your app. An iframe that contains an empty page to make the script call. The content of the iframe should not be affected as the meta won't be present in the empty page.