I'm trying to set the minimum height of some element to the minimum width of another. That minimum width of some element is given using some calc formula in less, and that formula might change later on. I tried setting the min-height to the min-width using JQuery, but it simply inserted the calc equation that didn't give the same output because 20% of the width is not 20% of the height. I was looking at css width: calc(100% -100px); alternative using jquery, but the solutions for that equation requre knowing what the formula was in the jquery, and I want to write my code such that it works no matter how much you change the calc formula in the less.
Example: http://jsfiddle.net/n6DAu/2116/
$(element).width() returns the width in pixels
$(element).css('min-width') returns the equation
Seems to be browser-specific to me. Chrome reports min-width as the calculation, and in the developer tools DOM inspector, it's also reported as the calculation.
Firebug, on the other hand, reports it as the value in pixels, both in the javascript and in the DOM inspector (using your fiddle). Firefox's built in dom inspector also reports it as the pixel size, not the calculation.
I didn't bother testing in IE.
So my answer would be - Possibly - you can't do it. (or at least you can't do it in a generic reliably cross-browser way) The value of min-width is going to change anyway, based on the enclosing element, so it may be something you'd just have to calculate on the fly, since you can find out how wide the enclosing element is at any given point in time.
Related
When using the picture tag with srcset, I can define different image sources for different viewport widths.
What I want however, is to define different images sources for the actual space (width-based) the image occupies after the browser has rendered the page.
For example:
Viewport width is 1920px Website uses container size of 1200px
Container is split into two columns of 600px each
Column 2 contains an image with 100% width - which will result in a width of 600px
The srcset for the image supplies 400x300px, 800x600px and 1200x900px
The browser should now automatically know to pick 800x600px
As long as it's clear that the image will always be in that spot, I could use srcset based on the viewport width.
Unfortunately, my site design is so, that content editors can freely add columns/rows and even nest them. Also at some point columns collapse and become always full-width. So when rendering the HTML, I cannot predict how much of the viewport width an image will get.
Therfor I would love to have the browser check how much pixels the image actually has when it's rendered to the user - and choose the appropiate image.
I have searched quite a bit, but couldn't find anything about that.
Is that even possible?
Or is the only solution a Javascript one?
No, sadly this is not possible yet. There has been much talk about element queries, basically media queries that apply to the element's size, instead of the windows size. But they are apparently really complicated to integrate. There is also no syntax for it yet. The classic problem that is often brought up (in pseudo-syntax), is something like this:
.child {
width: 500px;
}
.container:min-width(450px) > .child {
width: 400px;
}
so we set .child to 500px width, BUT then we say if the child's parent is more than 450px, the .child should have a width of 400px, thus .container would be less than 450px again, and .child is set again to 500px and so on and on. This causes what is called a "circularity problem".
There are also other problems, such as with dynamic layouts and the browser not really knowing how much space an element will take up beforehand. This could lead to huge performance issues, as the browser would simply have to calculate too much.
There are however JS libraries that try to implement this (e.g. EQCSS, CSS-Element-Queries or EQJS), but for your case a selfmade JS would probably be better. I'd recommend checking out how those libraries handle it though.
More info:
https://www.xanthir.com/b4PR0
https://webdesign.tutsplus.com/articles/the-current-state-of-element-queries--cms-29690
JS Libraries:
https://elementqueries.com/
http://marcj.github.io/css-element-queries/
https://github.com/snugug/eq.js
I am trying to get the minimum height of the div scroll thumb in javascript,
It looks like there is a minimum height that the browsers do not pass.
in chrome it is 16 px.
i need a formula to get it for all browsers
i am able to get the height if greater or equal to the minimum
Can you help?
https://i.stack.imgur.com/A0NhD.png
Note that it's really dependent on the browser and often the browser uses native OS widgets, and DPI settings. On mobile devices the scrollbar is usually hidden entirely.
Whichever "solution" you'll find, you shouldn't trust it to work everywhere. Even if you'd cover all cases now, it most likely breaks tomorrow.
In my HTML i have a <div> (call it the panel) with fixed width that contains some text; that text is set to font-size: 25px; line-height: 25px; in the accompanying CSS. It so happens that the text ends up as 36 lines.
Given that all margins, paddings and borders are zero, you'd expect the height of the panel to be 36 * 25px = 900px, and that is in fact what i find in Firefox, using the DOM's getBoundingClientRect() method.
However, in Google Chrome i get different figures; it would appear the panel is only 892.7999877929688px high while lines are 24.799999660915798px high. Dividing those two numbers still gives 36 though. It looks like there is a scaling ratio between nominal pixels as set in the CSS and real pixels as reported by getBoundingClientRect(); in my case, this is 1.0080645299120465 nominal per real pixels.
One more piece of evidence comes from Chromium running inside an nwjs app where i initially observed the discrepancy. During my tests, it showed consistently a different ratio from the one in Chrome. Now, at some point during my tests, the pixels reported by Chromium suddenly jumped to the integer values as reported in Firefox; i'm not sure what i did to make this happen.
It could be expected that the fractional ratios are in some way linked to page zoom; after all, at very small sizes, Chrome and Chromium reflow the text (and sometimes do it wrong). And indeed, varying the zoom in Chrome leads to different ratios, and making Chrome zoom in to the max will make the ratio flat out at 1. Still, my Chromium app is not zoomed in to the max and still has a fractional ratio. an integer pixels ratio in the test but a fractional value in the real app.
For all i presently know, all i can do to obtain the ratio so i can make sound, consistent box size measuring with JavaScript is to set up a box of known size and measure it.
I'm still wondering what the source of the observed behavior is. Are there any reports of it? Is it an intentional or an emergent behavior of the renderer? Was it ever discussed by the devs? Is there an API to obtain the ratio?
I've put some code on a gist at https://gist.github.com/loveencounterflow/d8c20b9021d2ab3f573a to simplify testing.
Some fonts cant be rendered at the exact size u ask for, and fonts had properties that affect indirectly to the real size reported. If you want same behavior everywere, maybe u have to import your own font to achieve similar rendering cross browsing. I had a similar problem while working on IE and Chrome.
My understanding is that CTRL-mousewheel zooms are an accessibility feature, built into the browser in question (I am currently testing in Chrome and Opera, both if which use the CTRL- zoom).
This won't ever really be needed for accessibility, however, as the app will not be for the general public. And CTRL-wheel zoom has a nice benefit out-of-box as compared with standard mousewheel zoom over elements: It seems that Angular ui-sortables work perfectly at any zoom/scale.
Unfortunately, from other answers I've found on SO, there is no way, when using CTRL-wheel, to zoom selectively : the browser can only zoom everything. For me, this includes position:fixed overlays scaling at the same time as the main viewport, which is no good.
So I set up some code for scrolling as per whichever element the mouse cursor is over, eg. scale the main viewport using the mousewheel, only if the mouse if over that viewport element.
The problem is that ui-sortable does not behave correctly, when using it for only a single element. I've used scale with transform-origin set at 50% 50% but still, when I drag the ui-sortables at any scale other than 1:1, they appear way off to the left. Any ideas on how to begin to tackle this?
This isn't a problem in Angular's sortable adaptation, rather it's an issue in the underlying jQuery-ui 1.9.2 positioning functions around line 4000 (_generatePosition or maybe one of the others). I believe that as the browser does not modify the actual dimension values during scale or zoom, and the formulae provided in that library do not account for scaling (that I can see), there is no easy fix, since jQuery ui.sortable needs scale-accurate values to calculate correct displacements. (I tried modifying the formula to account for this, but without success.)
The simplest workaround for the present is to manually change the width() / height() of your individual list elements, as seen here. This may require being selective about just what you scale using width() / height(), and what you change using scale (which is generally easier).
Does $('#idOfLememt').outerHeight(); yield same result for all browsers? Any thing different for IE7?
Just go to http://api.jquery.com/outerHeight/ with the different browsers you want to test and see for yourself (on Mac OS X so can't check IE for you). It looks like the DOM in the demo has all possible styles that would affect this included.
Most of the time you can rely on jQuery to do it's thing and give you consistent results across browsers, that's one of it's main reasons for being after all.
Edit: Of course this won't be the case if the browser messes up with something else, for example if your container isn't fixed height and IE renders something inside your container with a different height for whatever reason then the result would be different. You are however pretty much guaranteed to always get the same result as the amount of pixels used on screen.
Like SLaks said it should work fine.
There is one downfall you might run into though if you aren't explicitly setting margins and padding in your CSS. outerHeight() will include padding and border always and if includeMargin is true than it will also include margins. With some padding/margin discrepancies across browsers... ahem... IE... you may get different calculations unless you've explicitly set the border, padding and margin on the element in question.
It should work fine. (Unless you have other layout issues)