I have been searching but have not come to an answer.
Is there a way to detect the event which OpenLayers enters FullScreen/exits FullScreen? In short, i need to toggle classes of some divs. I tried adding events to the buttons, but then it doesn't work if they press escape instead.
Thanks.
The comment suggesting using 'screenfull' is a good option for now. screenfull is just a wrapper that smooths out the cross browser implementation issues of the fairly new 'Fullscreen API'. Until the browsers have fully implemented the standards for these events, that little wrapper is a good way forward.
If you are just wanting to style things differently, there is a CSS pseudo selector for that - :fullscreen. No JavaScript required! You can read the documentation for it on MDN and there is also a great example. Take special note of the need for the vendor prefixes and the fact that some browsers say full-screen rather than the standard fullscreen. The various mix of selectors you'll need seem to currently be:
:-moz-full-screen - Gecko based browsers
:-ms-fullscreen - IE/Edge
:-webkit-full-screen - WebKit based browsers
:fullscreen - Standards compliant browsers
I have a graph made out of simple <div>s and I need to allow users to zoom in and out. It seems that the css zoom rule that fixes so many things in IE doesn't work well or sometimes at all in other browsers. Is there some kind of mechanism or library that I can easily allow visitors to zoom in and out of a <div> that contains many <div>s? I tried -moz-scale for firefox and all kinds of strange things happen as you zoom, z-indexes get out of what, things don't align so well, etc.
I'm happy to make zooming a feature where you're required to use a modern browser, but at least the latest versions of firefox, chrome and IE need to be supported. If there's an html5 feature, that's fine.
For Zooming I have used CSS3 Transforms (scale(1.2) for example). It works pretty well and is supported on IE9, Mozilla and Webkit.
With this project at work, we have had to make a iPad HTML5. Using Backbone and jQuery Mobile, we thought we were on to a winner, but jQuery Mobile seems to be causing more problems than it should be. Using such things as page transitions with jQuery Mobile is painfully slow, choppy and glitchy (I do understand it's still in Alpha).
For our needs, we do want a smooth way of transitions between pages. I set about doing some experiments to see if I could get them any better for bespoke solution. I feel I'm quite close with this, but the animations still seem choppy and glitchy. I wonder if there is any other way to approach this? Or if there is a nugget of information that will help getting this rock solid?
I'm using translateX()/translateY() CSS3 (hardware accelerated) transforms to ensure it gets the best performance, but it still seems unreliable with it's performance. Sometimes it's ok, sometimes it's not.
I have uploaded an example... Please note, this is only tested in Chrome/Safari (which it looks fine in) and Mobile Safari on the iPad 1st generation (which it looks choppy in). If you happen to have an iPad handy, please take a look at this example...
http://littlejim.co.uk/code/ipad/jquery-plugin-page-transitions/
It's made as a basic plugin, because once I have this nailed I want to develop it more.
Can anyone help with this? I just wonder why it's still choppy on the iPad?
UPDATE: I tried using translate3d() as well as the translateX and translateY(), made no difference.
Only 3 dimensional transforms are hardware accelerated on the iPad. You should use translate3d and provide a 3rd parameter, set to zero.
http://googlecode.blogspot.com/2010/08/css3-transitions-and-transforms-in.html
Oftentimes in the web development community, you hear people complaining about developing for IE6. However, if you are developing using a robust JavaScript framework like jQuery, is developing for IE6 any different than developing for IE7?
It can display alpha-channel PNGs correctly.
The calculations for box dimensions are not that far away from the standards.
Rendering and JavaScript performance actually allow you to do something fancy without freezing the users machine every now and then.
Some security issues have been addressed.
In relation to the other browsers, it shows no improvement at all because the others have made much bigger progress in the same time. It's still the worst of the major browsers and a pain in the b*tt for developers.
IE7 supports png transparency, which is a massive help in maintaining graphic resources for the site.
I'll add a few points which haven't been listed:
CSS width strictly adhered to: IE7 in standards compliance now mode strictly interprets width styles in CSS. In IE6, if you have a child element that has a width which is greater than the parent element, it would often ignore the width declaration of the parent and expand to fit the child, often requiring hacks of overflow: hidden to make sure the parent didn't expand.
This is mostly a good thing, but unfortunately introduces a number of other quirks, e.g. <table style="width: 100%"> in a scrolled DIV with CSS overflow set to overflow: auto or scroll will expand the table to the width of the scrolled DIV including the width of the vertical scrollbar so some of the table will be cut off by the scroll bar on the right.
Cleartype with DirectX filters disabled: IE7 disables cleartype (font smoothing on LCD monitors) for elements which have DirectX filters such as alpha transparency and gradients. This is good in some ways, as cleartype made elements with filters, especially bolded ones very blurry/fuzzy, but it's bad because it now renders the text blocky and aliased on LCDs.
IE7 I think also now supports alpha: 1.0 as well as filter: alpha(opacity=100)
SELECT z-index bug fixed: IE7 fixed a bug where the SELECT elements have infinite z-index and are always above other elements unless you put an IFRAME in between of the SELECT and the element you want to display above it. This is a problem for menus etc.
CSS pseudo-classes improvements: :hover and some other similar CSS states are now supported outside of hyperlinks.
Performance not necessarily improved: IE7 introduced many bugs in it's VML engine, and in IE8 VML is now 10x slower than in IE7 when in standards compliance mode, so it's not altogether good. In addition, I have test cases which show that finding offsetLeft and offsetTop in mouse events in standards compliance mode in IE7 can also be around 10x slower in my web app.
IE in quirks mode though it's about the same performance for VML and offsetLeft/Top throughout IE6, 7+8. My experience in IE7 standards compliance mode is it's actually much slower than standards compliance mode in IE6, though it is definitely much more compliant.
I think it's a bit of a double-edged sword though, as raw JavaScript performance did improve, so things like working with array methods and for loops did improve even though I think the rendering engine and many of the associated DOM methods became much slower in standards compliance mode in IE7+.
IMO, there is a world of difference between IE6 and IE7.
IE7 supports built-in XMLHTTP whereas in IE6 it requires an ActiveX control.
IE7 supports a couple of additional pseudo classes
IE7 fixed some of the problems with z-order and zoom.
IE7 fixed "a few" of the box model issues.
IE7 added support for > child selector
IE7 added support for adjacent (+) selectors
PNG transparency support
I think most of the improvements to IE7 was performance(javascript) based and trying to get closer to standards compliance for CSS.
Off the top of my head, these were some of the major improvements as I recall:
Fixed the double margins bug
Fixed numerous issues with the box model and positioning inheritance
Inclusion of Developer Toolbar into browser(not a bug fix, but big one for me)
As noted by others, proper PNG handling
It was a much better browser when comparing it to IE6, when you compare it to other browsers out today, not so much.
Hardly; in terms of IE7's gain in standards compliance, it's negligible. All of the versions of Internet Explorer up until today, including IE8, have horrible breaks in JavaScript, CSS and DOM implementation. Most of the hacks you use for IE6 still apply for later versions. However, on the bright side, IE9 is shaping up to be quite good, and big progress has been made (I've never thought I'd actually say that).
The gaps and differences in implementation between the spec, and other browsers like Firefox and Chrome are much smaller.
I'd recommend Mark Wilton-Jones's article on IE's numerous flaws for more info.
Javascript & CSS frameworks minimise the amount of damaged caused by IE6, but there is still a number of bugs & inconsistencies between IE6 and other browsers.
IE7 is better than IE6, but only just.
Personally, the most annoying thing about IE6 is its lack of PNG transparency. This results in requiring use of AlphaImageLoader for images. The implications of this is introduces its own bugs/inabilities. For instance transparent backgrounds using AlphaImageLoader can't repeat.
Also, there are bugs such as the double margin bug, lack of support for min-height and min-width, adding extra line breaks to floated elements, missing css selectors.
What are cons to use sIFR, in terms of , development time, accessibility, speed and mobile devices?
Some cons Which i know.
Rendering speed of pages will be slow
because of it use JavaScript and
FLASH both
sIFR text will not be shown in Iphone
safari and blackberry. and if it will
be shown in other mobile browsers
then browsing will be more slow.
JavaScript and Flash player both
needed in user's browser
If we try to select sIFR text along
with normal text or two sifr text than selection
highlight will not be shown for sIFR
text.
Sifr has differene style mecanism so
we will need to look after style in
sifr-config.js, sifr.css and our own
project's css. some time for some
cross browser problems we will have
to see in all files.
We cannot put sifr js at bottom if we
will do then sifr text will be load
after other elemts
Some pros Which i know.
cross browser compatibility for
desktop browsers
text can be selected, copy and paste
graceful degradation (if JS will be disable then simple text will be shown, and even if CSS is we can see normal text)
screen reader compatible
sifr text is scalable also
My question are:
How much site will be slow if i use
sIFR in compare to simple text?
Is there any Free or open source, easy to implement, lighter solution With all features of sifr + iphone and blackberry compatibility but without Flash needed.?
sIFR is slowly becoming an outdated and overly complicated technique. Shaun Inman the designer who invented it now relies on Cufon instead. See this post where he even says:
"Fast-forward three years. Cufón is sIFR’s heir apparent."
http://shauninman.com/archive/2009/04/17/pxr_cufon_pxfon
But let's talk about sIFR. The pros:
Fairly reliable cross-browser.
Works with any modern JS enabled browser with flash 7/8 installed.
Cons:
It can be a PAIN to setup. It's not that easy to maintain but it's not a nightmare.
Text does not resize properly if the user adjusts their browsers text size.
It breaks in fluid layouts.
It won't work on mobile browsers that don't support flash (and even then I don't know if the mobile version of flash is capable of supporting sIFR
It's latent / slow loading. The browser has to perform a lot of calculations to properly replace HTML elements with flash movies and calculate the text dimensions for the flash movie to render.
Bottom line is it's very limited and fast becoming out of date. My advice would be to look into Cufon:
http://cufon.shoqolate.com/generate/
Or rely on a service like TypeKit and only support nice fonts in modern browsers:
http://typekit.com/
Remember it doesn't need to look the same in every browser. Just provide acceptable solutions for each. In all due respect waiting for sIFR to take place on a page loading in IE6 is much more annoying than just seeing helvetica instead of the font your designer fell in love with.
Disclaimer I am a designer and have worked as a designer for several agencies during my career!
the main con of sIFR is cufon it's faster, smaller and flash free. BUT you can't select the replaced text anymore.
sIFR is the best solution as far as I know, but I would avoid using it on mobile devices though.
Maybe you can make some mix of Cufon and sIFR, where you use Cufon for the mobile part and sIFR for the other browsers.