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
Chrome used to improperly exclude the scroll bar in its media queries. This means that with 1000px of visible space and a 17px scroll bar, other browsers would report 1017px as a width so far as Media Query is concerned, but webkit browsers (such as Chrome and Safari) did not do this.
These browsers could hit a specific size where a scroll bar would appear in one resolution, then change resolutions to another where it would appear, then it would go back to when it didn't... the solution caused an ugly blank space to appear where the scroll bar should, but it did not. It came out looking like a glitch, and the DOM resize events did not fire properly so it was not something you could react to properly in JS.
However, now in Chrome 29, this appears to have changed. Now they are going off of how the specification works and including the scroll bar in their media query calculations... just like Firefox and Internet Explorer (and how the specification says they should have all along). This fixes the bugs, but causes another problem in that the JS to try to detect the Chrome/Safari issue now will have false positives, because it is not a concern with newer versions of Chrome and I assume eventually Opera and Safari as well.
In light of all of this, I cannot find any information anywhere on when this was fixed in either Chrome or Webkit. I hate having to resort to browser version testing in my JS to work around these flaws, but I am just guessing blindly on Chrome 29+ for the moment as a temporary patch and would love an authoritative answer... I have tested in Safari 6.0.5, but the old method is still being used...
Does anybody know in what version of Chrome and/or Webkit this was fixed?
Chrome is no longer using the webkit engine as of Chrome v. 28 it now uses the Blink Rendering Engine. So no need to be detecting this for chrome unless you need it for previous versions.
For more on Blink: Blink Documnetation
For more on the Release: Next Web Article on Webkit/Blink Switch
I'm trying to make a canvas where the client can sign his name. It works well in Chrome v6:
but on Android 1.5 instead of drawing the browser scrolls the page and draws nothing:
I borrows the code from Opera's website.
Can I disable the scrolling or how can I make this work?
Thank you!
EDIT
using the events touchstart, touchmove and touchend:
on a LG GW620R using a stylus:
on a Motorola Milestone:
on a Samsung Galaxy:
EDIT 2
works better whitout using the finger nail
#Sirber There might be touchstart and touchend events just like in mobile Safari, have a look at that avenue too. And maybe if you adjust the viewport meta tag there won't be any scrolling, still won't draw but at least it won't scroll.
Good luck,
Mathieu
You're comparing the bleeding-edge in-development Chrome version to a stable 1.5 year old release of a parallel Webkit-based browser... of course there's better support for new HTML5 features in the much-newer experimental browser :) How does it render in a recent Android release (say, 2.2)? How about iOS?
There are definitely nontrivial differences between HTML5 browser support among Android releases (not to mention non-standard browser releases by HTC in SenseUI and the like). Check out the WebKit comparison chart at Quirksmode.
As far as viewport settings and disabling scrolling, Android's Webkit listens to most of the same settings that iPhone Safari does, and Apple has pretty good documentation on the settings you can use to tweak that.
You also may find this quirksmode post about supported events in mobile Safari helpful.
Canvas with iOS is really better (performances). Android browsers are far behind (doesn't work with opera-mini).
If you want to see the difference, just try with http://webdemo.visionobjects.com/ .
I'm just doing a quadratic smoothing for an handwriting input method with the HTML5 canvas-element.
tested with iPad1 & Motorola Xoom
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.
How to put transition on a web page? I have tried, but it doesn't worked on internet explorer. how to add transition during opening page? transitions effects like fades,dissolves etc. same as in ppt's
If you are talking about CSS3 transitions/animations (CSS3Please.com demo here), be aware that IE is lacking in support for these almost entirely - it is unclear but unlikely that the new IE9 will have CSS3 transitions.
This is a good article written about CSS3 transitions/animations this week:
http://www.onextrapixel.com/2010/11/17/a-comprehensive-guide-to-css-3-transitions/.
Decide whether transitions are necessary for IE based on the demographics/browser preferences of your user base, and also knowing that IE users are far less likely to expect such transitions (because fewer developers make the effort). Unless it is truly critical that your site looks gorgeous in IE it's usually acceptable to make IE functional, while implementing transitions for the more advanced browsers.