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
Related
I am building a responsive web site using Twitter Bootstrap. I can display/hide/modify/rearrange content using media queries and different CSS for each breakpoint. That works fine. But what about triggering different javascript for each breakpoint? What's the most reliable way to do this?
In this particular case I am using the masonry plugin. I want masonry to layout the items on small, medium or large devices, however on extra small devices I don't want it to. (My own native list layout will be fine).
It seems like the most modern way to do this uses the window.matchMedia() method. This also lets me add a listener so that I can add/remove masonry if the window size changes. The downside is that, according to Mozilla Developer Network, support for matchMedia is not great. I could use a polyfill to get around this, but it sounds a bit complex.
Another way to do it would be to test document.documentElement.clientWidth (or .screenWidth), and synchronize my javascript logic with the breakpoints for the media queries. I would use the window.onresize event to load/unload/re-layout as required.
A third way to do it might be to run some javascript on the resize event, testing the value of an attribute which is controlled by css and a media query. For example, if a particular element is hidden on extra small screens, I could look at the visibility property of that element to determine when I was on an extra small screen.
I am leaning towards the second of these three options, but I'm keen to know if there is a 'generally accepted' method of accomplishing this, and also if there are other options which I have missed.
I would go with window.matchMedia as it is supported by most current browsers (http://caniuse.com/#feat=matchmedia) and for those that do not support it you can use this polyfill: https://github.com/paulirish/matchMedia.js
Using matchMedia might reduce the complexity of your specific viewport/resize logic, as you can reuse the definition of the breakpoints you already use in your css. If you are using SASS you can even define your breakpoints once and share them between you SASS and your JavaScript: http://viget.com/extend/sharing-data-between-sass-and-javascript-with-json
Listening for the resize-event can get quite expensive/slow if you are not throttling/debouncing. If you are sticking to the resize-event have a look at https://github.com/louisremi/jquery-smartresize.
There is a jsPerf comparing the performance of matchMedia to the resize-event: https://jsperf.com/matchmedia-vs-resize/3 For me matchMedia was way faster than the resize (tested in Chrome 41 and Firefox 36)
Check out Awesome Media Queries in JavaScript: enquire.js is a lightweight, pure javascript library (with no dependencies) for programmatically responding to media queries.
http://wicky.nillia.ms/enquire.js/
https://github.com/WickyNilliams/enquire.js/
I'm working on a site where I've created a simple CSS3 hover effect, where if a link is hovered, it changes the opacity and looks like a rollover effect. It seems to be working perfectly on all browsers (even older ones, such as Firefox 2). Just wanted some input if this is a problem and I should consider javascript instead? Or is using CSS a good (semantically correct) way of going about a rollover?
Generally, if an effect can be achieved using CSS alone, it's usually better to use CSS then to use JavaScript to achieve it.
Sure, you can use JavaScript and/or libraries like jQuery, but why? If the browser is capable of doing it natively, not only will it work better, it will look better and smoother.
Generally, people using newer browsers get benefits from the new technology.
People who do not update their systems tend to not care about how things look, so as long as the site is functional and the effect is not very important, I'd say don't bother to make all browsers behave exactly the same. It's a waste of time and effort.
For anchor elements, the :hover pseudo-class is widely supported, and is a good way to go. I believe the only in-use browser that doesn't support it is IE 6. The opacity property is less widely supported, so your effect may not look the way you want in some browsers. If you need to use the :hover pseudoclass on elements other than a, I think you'll lose IE 7 as well.
See http://www.w3schools.com/css/css_pseudo_classes.asp for some background information on :hover and other pseudo-classes.
is there any way to use custom border by css or can make by JavaScript or jquery.
i want to use a different style of border.
like we use
border-style:dashed;
with CSS3 you can use border-image, which is what you are looking for. for more information click here - but note, that this is only supported by very few good browsers (firefox, safari - maybe opera - but no IE (until some day IE9 comes...)).
EDIT:
if you could give some more information how the border should look like, we could try to do some cross-browser-solution - but the best way is to use border-image... and some not-too-ugly-standard-border-fallback for that dumb piece of software called "IE".
CSS3 can do this, but IE won't support it until IE9.
Check out this link: CSS3 border images.
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.