In the 2-frame 'rows=' frameset I have, if a user change of the zoom level to less than the 125% value that I coded for, they will see "dead space" between the frames.
This question: How to detect page zoom level in all modern browsers? shows how to detect the browser's zoom level.
Is it possible to adjust the browser's zoom level using Javascript so I can keep users from changing the zoom outside of the desired levels?
Or have I simply forgotten a default coding consideration of some kind? (I've seen CSS's 'zoom' style, where presumably default zoom levels can be set.)
I am also seeing document.body.style.zoom, so seems we could do something like:
if (zoomLevelChange)
{document.body.style.zoom= [some calculation]; }
See How to detect page zoom level in all modern browsers?
Can you edit your question to only be about "adjusting", since the other one has detection covered?
Related
I want to use After Disaster font on my website, but I can't achieve the same vertical position of displayed text in different browsers. Even more - it is dependent on system too. You may test this:
http://jsfiddle.net/z7rby/1/
On Linux Google Chrome displays text about one pixel higher than Firefox and Opera. On Windows Google Chrome displays it in the middle of background. What can I do with that?
There is no way to solve this problem. You have to accept that fonts will be rendered slightly differently on different systems, and find another way to achieve your visual goals.
You can control your layout via positioning CSS e.g. width, height but not font rendering.
If that level of control is not "good enough" then you can write browser-dependent CSS (tutorials exist online) to compensate for differences.
But please remember the goal in all computing is "good enough": Perfection is not cost-effective!
Once you have achieved a level where further improvements require a certain effort, but there are more important things to spend that effort on, that is the point when you have finished.
I'm working on a web project that has some accessibility features mandated by the client, including a "font size changer" to allow the font size to be increased for visually impaired users.
Despite my arguments that a better experience will be had by using the built-in zoom features in the browser, the client has insisted that their users will not know to use these built-in features, so we must provide a text size changing widget.
What I'd like to do, if possible, is cause these page elements to invoke the browser's own zoom functionality (Ctrl + + in firefox, for example). If the browser doesn't support this method of zooming, then I might fall back to increasing the font size with css.
How can I best implement this kind of feature? Is it even possible? Is there some solution that I've overlooked?
There is no way as far as I know to use the browser's built in function. However it can be done with CSS3 or javascript. for a CSS3 example look here: http://www.css3.com/css-zoom/
I am writing a Xlib app where I want the window to be centered. I have used XMoveWindow with (desktopWidth - width) / 2, (desktopHeight - height) / 2 and it is roughly in the right place.
However the problem is that width and height are the client area, not the total area. Is there any way for me to get the total area of the window?
I need to use Xlib because I am using Glx and OpenGL. I don't want to use SDL, nor have a bulky graphics library.
There are various ways to go about this, depending on why you are doing it. The first two are "officially supported" by most window managers and described in specs, and then it descends into fragile hacks.
Semantic
The specs encourage you to use _NET_WM_WINDOW_TYPE rather than setting the position, if it makes sense to do so. See http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#id2507144
For example, a DIALOG type (or a window with the WM_TRANSIENT_FOR hint set) will usually be centered on its parent window or on the screen, and the _NET_WM_WINDOW_TYPE_SPLASH (splashscreen) type will usually be centered on the screen. "Usually" here means "sensible window managers probably center it, and people using weird window managers are not your problem, let them suffer."
(Another hint along the same lines, though not what you want here, is _NET_WM_STATE_FULLSCREEN, which avoids manually sizing/positioning in order to be fullscreen.)
If semantic hints work, the window manager code to handle the positioning is hopefully smarter than anything one can easily code by hand, for example it might deal with multihead setups. Setting the proper semantic type may also allow the WM to be smart in other ways, beyond positioning.
Gravity
If there's no semantic hint in the specs that helps you, then you can center by hand. It's important to note that window managers are allowed to ignore a manual position request and some of them will. Some may only honor the request if you set the USPosition flag in WM_NORMAL_HINTS (this flag is supposed to be set only if the user explicitly requested the position, for example with a -geometry command line option). Others may ignore the request always. But, you can probably ignore WMs that do this; the user chose to use that WM.
The way you compensate for the window decorations (the titlebar, etc.) is to use the win_gravity field of WM_NORMAL_HINTS, which is originally in the ICCCM (see http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.2.3) but better-specified in an implementation note in the EWMH: http://standards.freedesktop.org/wm-spec/latest/ar01s09.html#id2570420
For WM_NORMAL_HINTS see http://tronche.com/gui/x/xlib/ICC/client-to-window-manager/wm-normal-hints.html#XSizeHints (note: the type of the property is WM_SIZE_HINTS and the name of the property is WM_NORMAL_HINTS, so there are two different atom names involved).
To center, you would set the win_gravity to Center, which allows you to position the center of the window (including its decorations) instead of the top-left corner.
win_gravity is not often used and is likely to be buggy in some window managers because nobody bothered to code/test it, but it should work in the more mainstream ones.
Update, possible confusion point: There are other "gravities" in the X protocol, specifically the CreateWindow request lets you set a "bit_gravity" and "win_gravity"; these are different from the XSizeHints.win_gravity. The CreateWindow gravities describe how the contents (pixels/subwindows) of a window are handled when the window is resized.
Hacks based on guessing decoration size
It's a fragile hack, but... you can try to figure out the decoration size and then incorporate that into your positioning.
To get the size of the window decorations, one way is the _NET_FRAME_EXTENTS hint, see http://standards.freedesktop.org/wm-spec/latest/ar01s05.html#id2569862
For older-school window managers (but not the fancy new compositing ones, though those hopefully support _NET_FRAME_EXTENTS) the window decorations are an X window, so you can get your parent window and look at its size.
The problem with both of these approaches is that you have to map the window before the decorations are added, so you have to map; wait to get the MapNotify event; then get the decoration size; then move the window. This will unfortunately cause user-visible flicker (the window will initially appear and then move). I don't think there's a way to get the window decoration size without mapping first.
Descending further into the realm of awful hacks, you could assume that for windows after the first one you map, the decorations will match previously-mapped windows. (Not that this is a sound assumption: different kinds of windows may have different decorations.)
Implementation note: keep in mind that the decoration window can be destroyed at any time, which would cause an X error in any outstanding Xlib requests you have that mention that window and by default exit your program. To avoid this, set the X error handler when touching windows that don't belong to your client.
Override redirect
Using override redirect is a kind of bazooka with bad side effects, and not at all a good idea if your goal is just to center a window.
If you set the override redirect flag when creating a window, then the window manager won't manage its size, position, stacking order, decorations, or map state (the window manager's redirection of ConfigureRequest and MapRequest is overridden).
This is a really bad idea for anything the user would think of as a window. It's usually used for tooltips and popup menus. If you set override redirect on a window, then all the normal window management UI will be broken, the stacking order will end up basically random (the window will tend to get stuck on top or on bottom, or worse get in an infinite-loop restack fight with another client).
But, the override-redirected window won't have decorations or be touched by the WM, so you can surefire center it with no interference.
(If you just want no decorations, use a semantic type like SPLASH or use the "MWM" hints, don't use override redirect.)
Summary
The short answer is set the semantic hint if any is applicable, and otherwise use XSizeHints.win_gravity=Center.
You can kind of see why people use toolkits and SDL ;-) lots of weird historical baggage and corner cases in the client-to-window-manager interaction generally, setting window positions is just the beginning of the excitement!
win_gravity is not often used and is likely to be buggy in some window managers because nobody bothered to code/test it, but it should work in the more mainstream ones.
Apparently Unity haven't implemented this. Testing shows that XCB_GRAVITY_STATIC is not respected and by taking a quick look at Unity source code I could not find code implementing this part of the specification.
I'm trying to track down a z-index problem. I'm looking at the page in IE9's DOM Inspector, and I just can't figure it out.
I have one element with a z-index of 10000, and another with a z-index of 7000, and yet the z-index 10000 is drawing below the z-index 7000. Clearly somewhere in the hierarchy, something is setting a stacking context, but I've been browsing up and down the hierarchy and I haven't been able to find it.
Nothing other than these two elements, so far as I can see, has a z-index set. And nothing as a opacity value set. and I'm seeing this in FF5 and IE9, so it's not the old IE<7 stacking context bug.
Do any of the browsers have a tool that will tell me which element is setting a stacking context?
Thanks.
If you use Chrome https://github.com/gwwar/z-context is a simple extension to see:
If the current element creates a stacking context, and why
What its parent stacking context is
The z-index value
and important, like aprohl5 said: The z-index property can affect the stack order only if the position is explicitly set to fixed, absolute, or relative.
This is a nice way to mantain order with Sass https://www.smashingmagazine.com/2014/06/sassy-z-index-management-for-complex-layouts/
For Chrome: the chrome 3d 'layer' tool does most of what you'd want I believe (similar to the other answer which is for MS Edge)
Find it in dev tools > overflow menu / 3 dots (hidden by default) > 'more tools' > 'layers'
https://www.youtube.com/watch?v=6je49J67TQk
The current of MS Edge (using the Chromium engine with a build of "Beta", "Dev", or "Canary") now features: "Debug z-index stacking content with 3D View in the Microsoft Edge DevTools"
"a new feature to help debug z-index stacking context. The general 3D View shows a representation of the DOM (Document Object Model) depth using color and stacking, and the z-Index view helps you isolate the different stacking contexts of your page."
Press F12 (Windows), and then select the "3D tab" in the lower pane (may have to click "...") to view a visual representation.
More information:
https://blogs.windows.com/msedgedev/2020/01/23/debug-z-index-3d-view-edge-devtools/
For Google Chrome and Firefox, I've created an open source extension that not only tells you if the element creates a z-index and why, but also shows a tree-like view of all stacking contexts in the page, and the stacking contexts that they're competing with regarding to the z-index value. You can see all these informations directly in the browser devtools, check out the github page for more info.
CSS stacking context inspector for Chrome
CSS stacking context inspector for Firefox
in newer versions of firefox you have 3D view by pressing Ctrl+Shift+I then clicking the 3D or 3D box icon to access
For z-index to work, you have to explicitly set the position to fixed, absolute, or relative.
Here's a great explanation: http://coding.smashingmagazine.com/2009/09/15/the-z-index-css-property-a-comprehensive-look/
In my case I made the div width 500px,
but it automatically zoomed out when browsed in a mobilephone
How's the magic done exactly,is it device specific?
You might want to try something like this in the head of the html page:
<meta name="viewport" content="width=device-width, initial-scale=1.0"/>
For more info see here:
http://davidbcalhoun.com/2010/viewport-metatag
Edit: the answer below no longer reflects current normal practice. There is now a fairly well established standard called the meta viewport which controls how the page is scaled on mobile. In the absence of this, sites are deemed "not mobile friendly" and mobile browsers show the page at typical desktop width, zoomed out to show full width.
It is browser specific.
It's even a configurable option in most mobile browsers (eg Android, Nokia S60, Opera Mini). I prefer to have it turned off, so that pages open with normal 100% zoom (and if it's cut off, I just scroll).
Some people prefer to see the whole page width at once even if the text is too small to read, then double-tap to zoom up after that.
The browser typically calculates the total width of the page first. In this calculation any flexible-width element is taken to be the minimum width which can fit all its children. If this is less or equal to the width of the browser window no scaling is done, but if it's greater, the browser sets this as the virtual page width and, if the user has turned this option on, scales everything down (like zooming out in a modern desktop browser) so that that minimum width of the page occupies the width of the browser window.
The browser do whatever it wants to. Since mobile phones have a small screen probably this browser zoomed out to be more pleasant to look the page.