Is it possible to trigger Browser's zoom-in and zoom-out function through JavaScript?
I want to add Zoom-In(+) and Zoom-Out(-) buttons in my website, and by clicking on the button want to call browser's zoom-in (which can be called by pressing ctrl and +) / zoom-out (ctrl and -) function.
I do not believe there is a standards based way to do this. Certain browsers may offer their own API to do this but I am doubtful.
That being said I have accomplished this effect in the past through some CSS trickery. Essentially in your CSS define every measurement (width, height, margin, padding, font-size, etc.) in em instead of px. This essentially makes the size of everything dependent on the default font size of the document. Then to zoom you change the font-size of the body tag to make things smaller or larger. If you do this carefully the effect will look the same as if the user zoomed using their browser.
To make life easier when doing this I like to use a CSS reset stylesheet that sets 1em to be 10px. That way if you want a div to be 200px wide you just set it to be 20em. You can accomplish this by setting the body font-size to 62.5% in your CSS reset stylesheet. Since most browsers have a default font size of 16px and therefore 1em=16px, 10px is 62.5%.
I hope this helps, it is a lot of work to do it right, but using em instead of px has helped me in countless ways when working with HTML and CSS.
Think this was already answered with
window.parent.document.body.style.zoom = 1.5;
"Zoom" a browser window/view with JavaScript?
I don't believe you can. On IE you could simulate it with the zoom CSS property, but that's non-standard and so support outside IE will vary.
Related
I've been struggling with a layout that automatically(without JS) adjusts when the user alters the browser's default font size. Even in extension APIs there is not an event indicating that the user changed the default font size.
To get around this, upon blur of the window, the width of an off-screen element is recorded and, upon focus, the size of the element is compared to the size recorded. If there is a change, then the layout functions are run again. This generated the desired layout, but there was a remaining issue of it taking time for the browser to recognize that there was a change. By this, I mean the code was fine but, unless a setTimeout of 500ms was used to delay the running of the code that queried the elements' geometry, the layout would be incorrect. An offsetHeight queried upon focus would differ from that queried 500ms later.
I thought perhaps it was because I was doing all of this in JS and ought to have the browser perform it. Thus, I started learning about calc in CSS and using it in media queries, which led me to this question concerning the determination of rem in a media query. The issue mentioned appeared to be that the browser always uses 16px to determine rem rather than the adjustment placed in the root or html element for font size such as the common 62.5%. I thought I could get around the issue by using calc within the media query.
I tried the following in testing on my larger screen that is 1920px wide; and if use 191.9rem, the styles in the media query get applied, and do not for 192.0rem. So, it seems accurate to the pixel.
#media ( width > calc( 192.0rem * 0.625 ) )
However, when the browser's default font size is changed, it doesn't adjust as expected. For example, since the screen is 1920px wide, at a base font of 16px, the media query style should not be applied. But, if reduce the base font to less than 16px, the media-query styles should be applied because a rem is less than 10px, including the 62.5% adjustment, but they are not.
But, if leave the base font at less than 16px and then refresh the screen, the media-query styles are applied as they should be. Thus, it appears that the issue of a necessary delay for the browser to reflect the new geometry still applies. The browser isn't always using 16px but the media query processes before the geometry is fully updated, which is the same problem I had before using JS and why the 500ms delay was needed.
I attempted to illustrate this through the snippet but I don't know what width it will be displayed at in your browser so, it may not work properly for everyone. Plus, the snippet container doesn't appear to change with the default font size either. Nonetheless, the idea is there. The div.affected should change color from yellow to blue when the browser default font size is decreased to below 16px; but it won't upon change but only after reloading the page.
The snippet works for me. At default font size of 16px both boxes are blue. Change default font size to 10px and immediately come back to this page and both boxes will still be blue. Refresh the page and run the snippet again and the div.affected will be yellow. The converse works also. I want div.affected to change when the font-size is changed. I added the text so you can see that it isn't because the snippet itself isn't responding to changes in font size by observing the size of the 'A'.
Since the text size updated upon change of font size and without reload, perhaps this is part of a better answer, that is, instead of querying the size of an off-screen proxy element upon focus, query the font size of text. Maybe the 500ms can be reduced to zero for determining whether a change has taken place and, if so, then wait 500ms before querying to reset the layout. I'll test that out, if don't receive a better idea shortly. Tried it and it still requires a delay if use getComputedStyle to query font size.
My question is, is there a way to do this better and get around the delay, either in JS or CSS and media queries with or without use of calc?
I have it working in JS with a delay, but the the page has to be displayed but not visible and then wait 500ms before performing the calculation and making the page visible again. I'm looking for a way that doesn't require a delay because CSS media queries appear to have the same issue and unless use JS to add a class after a delay, media queries won't work at all.
Thank you for considering my rather confusing question.
div { width: 100px; height: 100px; background-color: rgb(73,110,147); margin: 10px;text-align: center; }
div.unaffected { font-size: 48px; }
div.affected { font-size: 3.0rem }
#media ( width > calc( 79.5rem* 0.625 ) ) { div.affected { background-color: yellow; } }
<div class="unaffected">U</div>
<div class="affected">A</div>
I'm making an adaptive website, And when the user has some odd font size configuration (For visual issues and so) The design breaks in a terrible way... Obviously I don't wanna forget the accesibility... So: Is there a way to know when the user is trying to force the font size, disable that and give him different styles?
Normally your font size settings on a page override those set in browser settings, except if you use % or em when setting font-size, in which case they may be relative to the size set in browset settings (depending on exactly how you set the sizes).
This means that if you have, say body { font-size: 9px } in your CSS and a visually impaired user has selected the largest size in normal Chrome settings (corresponding to 24px), the user setting is overridden and the illegible size is used. This is one reason why browser font size settings as such are not often changed by users: their effect is rather limited, when used alone.
However, if the user has set the browser to ignore font sizes specified on web pages (this is possible e.g. in IE via Accessibility settings), then the font size in browser settings is used, no matter what you do. (Font size within the page might still vary, e.g. due to using small markup or heading elements, as per browser defaults for some elements, but any CSS settings on the page for font size would effectively be disabled.)
Similar considerations also apply minimum font size settings, which are rather common and might be set even by browser’s factory settings. They take effect after normal CSS cascade has resulted in some size—if that size is smaller than the minimum set, the minimum is used instead.
There are indirect ways to try to find out what the font size actually used by a browser is, e.g. by getting the height of an element using the clientHeight property. If you do that for an element with line-height: 1, you normally get the actual font size used. But you cannot disable it; it’s pretty much the essence of browser settings that override settings on web pages that web pages cannot override them.
You can get the default font size with getComputedStyle by reading the property of the root html element (unless you have a css rule which modifies its font-size).
// get default font size in px
var computedStyle = window.getComputedStyle(document.getElementsByTagName("html")[0], null);
var defaultFontSize = parseFloat(computedStyle.getPropertyValue('font-size'));
For most browsers the default value should be 16px.
To override a value from the user's style sheet, add !important to the rule specifying the font size, for example:
body {
font-size: 16px !important;
}
Note however that in general this should be avoided. See also this SO question:
when to use !important property in css?
I was looking around for a way to arrange content differently depending on screen size when I noticed this site. Quite a nice looking site too. As I change my browser's size, the column configuration changes? When I reduce to the very minimum size or visit it on a phone, the large image on top disappears completely, leaving only the small icons. I've turned off javascript, and this still happens. Also, it works in my ie8, so I'm guessing it's not an HTML5 thang. How is it being done?
Thanks!
This effect is not being done by Javascript, instead it is being done by CSS #media queries. Chris Coyier of CSS Tricks has a great intro to #media queries
Simply, it allows you to specify the scope of a stylesheet based on some boolean expression (such as checking if the window width is a specific width used in that example you saw) and then apply specific styles thus making it responsive design
my site is aimed purely at the laptop market (dont ask why or argue!), all my users (or 95%+) we on a screen width of 1200+,
netbooks are now taking off, with a resolution of 1024 wide.
my site still looks great on a netbook if you zoom out once (ctrl-minus), but i don't want to rely on users knowing about ctrl-minus.
what are my options besides redesign? I'm keen not to have zoom buttons on my page.
is there a javascript zoomer outer?!!!
While this doesn't sort out your zoom, you could try a little trick based on CSS & relative sizing.
If you have an image or a container that is 100px wide, try setting it to 10em wide (or faff with the em amount until you find the appropriate value). Eventually, if you do this to every single dimension specified upon your site, you'd be able to actively shrink the page by changing the default font-size. E.g. from 1em, to 0.91em.
People often use the relative sizing to allow people the flexibility of being able to shrink and grow font sizes as they want. It's not as commonly used on images (because they are by requirement, fixed in size). This needn't be the case though, and in this instance, might offer you a way out of a "full site redesign" and giving the effect of "zooming".
This might solve the problem without redesign, but may be tricky and would require a bit of testing. The way stylesheets cascade, shrinking the font a little more, element by element, might cause a few issues.
detect screen resolution via JS
apply appropriate CSS
ctrl + - is the browser feature and you should never rely on that.
try this article http://www.alistapart.com/articles/alternate/
or try to google "javascript switch css"
this is a bad idea for many reasons. zooming is client specific so you will run into cross browser compatibilities if even possible at all. your best bet is to use css and set a min and/or max width. you don't need to redesign but (assuming proper html structure and usage of external css) changing some width values should do the trick.
When setting up a rollover effect in HTML, are there any benefits (or pitfalls) to doing it in CSS vs. JavaScript? Are there any performance or code maintainability issues I should be aware of with either approach?
CSS is fine for rollovers. They're implemented basically using the :hover pseudo-selector. Here's a really simple implementation:
a{
background-image: url(non-hovered-state.png);
}
a:hover{
background-image: url(hovered-state.png);
}
There are a few things you need to be aware of though:
IE6 only supports :hover on <a> tags
Images specified in CSS but not used on the page won't be loaded immediately (meaning the rollover state can take a second to appear first time)
The <a>-tags-only restriction is usually no problem, as you tend to want rollovers clickable. The latter however is a bit more of an issue. There is a technique called CSS Sprites that can prevent this problem, you can find an example of the technique in use to make no-preload rollovers.
It's pretty simple, the core principle is that you create an image larger than the element, set the image as a background image, and position it using background-position so only the bit you want is visible. This means that to show the hovered state, you just need to reposition the background - no extra files need to be loaded at all. Here's a quick-and-dirty example (this example assumes you have an element 20px high, and a background image containing both the hovered and non-hovered states - one on top of the other (so the image is 40px high)):
a{
background-image: url(rollover-sprites.png);
background-position: 0 0; /* Added for clarity */
height: 20px;
}
a:hover{
background-position: 0 -20px; /* move the image up 20px to show the hovered state below */
}
Note that using this 'sprites' technique means that you will be unable to use alpha-transparent PNGs with IE6 (as the only way IE6 has to render alpha-transparent PNGs properly uses a special image filter which don't support background-position)
It will still work in CSS if the browser happens to have Javascript disabled.
Because it's an aspect of presentation, I'd say it's more standards based to do it with CSS. It used to be done in Javascript, simply because we couldn't do it with CSS (old browsers suck, and I don't think :hover was even added until CSS 2).
Implementing a rollover with CSS uses the :hover pseudo-class to define the style of the target element when it is hovered over. This works great in many browsers but not in IE6 where it only works well with the anchor tag (i.e. a:hover). I used CSS hover to implement a tabbed navigation bar but had to use IE behaviors to get it working in IE6.
Yep, the best way to do this is css sprites. An annoying problem occurs in IE6, when browser make a request every time an element is hovered. To fix this, take a look here.
I'd stay on the CSS side of the house, but I've done very little Javascript.
CSS seems to be easier to standardize across browsers than Javascript, though that may be changing with the advent of Chrome's V8 and Firefox's upcoming new rendering tool.
Isn't there a mnemonic for remembering the sequence of declarations in CSS?