My content wrapper will be centered in the body. the problem i have is that i have a certain div that will be partially reaching into the body and out of the wrapper using z-index. this works fine when using a certain solution. if an user is maximizing its desktop solution the frame of the content wrapper wont be visible anymore. even then the certain div is no more visible. so is there a way to limit the max. zoom?
here is an example: link
when you will zoom in you can see that the red div is from a certain point no more visible. this i would like to avoid if possible. thanks a lot.
Various browsers allow you to define viewport metatags that define the allowable zoom limits (for example Web Kit-based browsers). If you know what your target browsers are, you may want to investigate this.
Related
How to make a website get treated like in image when window resizing? I don't know if this could be done with the viewport or not. I have looked at some answers and most of them say that it not possible or not a standard. Yet on this very site you can see when zooming in that elements do not get resized or at least the element to window size ratio is always the same. but when you go to a website like https://www.lynda.com/ you can see the elements resizing when zooming in and there is never a scrollbar for the width unlike stackoverflow. So how can someone site's be like stackoverflow in that regard? because lynda.com way seems to be the default.
Thanks in advance ....
If I got it correctly, you are interested in these concepts:
Fixed layout/design: SO like layout, elements do not react if viewport is changes
Response layout/design: Lynda like layout, elements change or even disappear, if viewport becomes small enough
A nice, short and illustrative presentation can be found here, where you can also find out about other design modes.
I've found a TON of posts and questions on mobile width/height. The top two answers are to use media queries, or to use vh/calc(). The other issue I've seen numerously is the mis-understanding of width/height(100%) vs width/height(auto) with the use of margins/padding/borders. What I've run into seems to be unique, but with the flood of mobile issues, I have a feeling somewhere out there is an answer to this already. If you've seen this, please point us to the correct question/answer.
I've created a black glass along with an element to use as an image previewer. The glass and image have width("100%") and height("100%") without any padding, margin, or border. On a computer, it looks perfect. On a mobile device, the dimensions can get thrown off and the background shows through.
If I remove the height("100%") on images that are taller than wide, it resizes to the entire element. If an image is wider than tall, removing the width("100%") causes it to grow appropriately again too. However, this doesn't solve my issue because without a width or height cap at 100%, larger images will overflow.
I first noticed this issue on my cellphone (android) and have had no issue repeating it on Chrome's emulator. I have uploaded a quick recording of what I am seeing to screencast.
It's been suggested that a css rule is leaking from a parent element. Chrome supports the style 'all: initial;' to reset the css. I also manually reset my css with this method. Resetting the styles did not change the issue.
Once again, thank you for taking the time to look at my issue!
I have a layout with multiple images, both portrait and landscape. I would like to make each image take up as much space as possible within the browser window, whilst remaining entirely visible.
Is there a simple way to do this? I've tried searching but everything coming up is for making a single full screen DIV or image, rather than the multiple images I'd like to use.
You can use the background-size property, which has a value cover, that does exactly this. For older IE browsers which don't support this, a jQuery CSS hooks fix has been made available.
You just have to layout your DIVs using proportional CSS width values, and then assign each one a covering background image.
I think perhaps you are looking for something like this: http://masonry.desandro.com/demos/images.html
I'm wondering if anyone knows a way that you can prevent browser zooming of specific page elements.
This is for the mobile version of a site I'm developing. I have a fixed menu bar that runs full width of the site and remains at the top of the page at all times to provide navigation. I've optimised the button/text sizes to work for touch screens and don't really want it to be affected if a user zooms the page content text.
The only thing I've come across is the following CSS, but this doesn't seem to work when I've tried it:
-webkit-text-size-adjust: none;
I'm do not wish to disable resizing of the whole page via the Viewport meta tag, I just want to target the menu bar html elements.
The zoom mechanism varies across browsers and is not standardized, nor is it scriptable. Any solution would be pretty convoluted in order to work across browsers. There is no easy way to do this.
I wrote a modal dialog based on a similar question, you can find it here.
In essence, the logic is about getting the page scale ratio based on window.innerWidth and maximum page width, applying it as a CSS transform to the element and then repositioning it on screen. If there is interest, I will rewrite it into a library that just takes a position: fixed element as an input and does all this magic to it when the user zooms the page.
I came to know that, if we dont give width and height attr. in image tag there will be a performance isssue.
I have a div element for which i'm setting width and height in percentages. Also the same div is having a background image of fixed size say 140px * 140px.
Here, will there be a perfromance issuse?.
markup example:
<div style="width:50%;background:url('imgofsize140*140') no-repeat"> </div>
Thanks
This isn't a one-size-fit-all case - Therefore we have to look at it case by case.
There are a lot of variables that we must keep in mind - User's internet connection speed, image size, computer capabilities, etc.
I found a few questions on SO that are somewhat relevant to this question. I will include them as I see it beneficial. I am NOT claiming to be absolutely correct.
BGIMG vs IMG
Performance Argument
AFAIK, browsers cache images the same whether they're in a DIV or an
IMG. In any case, I think this one of those cases where specific
performance is defined as an implementation detail internal to each
rendering engine (and possibly the browsers built around them). As
such, it's both out of our control as designers/developers and subject
to change from browser to browser and version to version. In other
words, I wouldn't spend too much time worrying about it.
Context
Technical differences yes, most notably you can set the width/height
of an IMG tag and it will stretch the image, which can be useful in
some situations.
The main thing you've got to keep in mind though is the context of the
image within the HTML document. If the image is content, say an image
in a gallery, I'd use a IMG tag. If it is just part of the interface I
might use a div instead.
- By Paul
And the response to that is just as important.
That said, you bring up an excellent point about the semantic
difference: an IMG is usually the better choice when the image is a
material part of the page's content, while a CSS technique is usually
preferred when the image is just decorative or for formatting.
This is not performance related directly - More about semantics and accessibility. By - Mr. W.
Then one more for Performance OFF of SO which I feel is directly related to your question.
Page Load Test
The version with background images actually gave me a “Document
Complete” after .0225 seconds – while the fully loaded page load time
was roughly the same as the inline image version. Could using all
background images speed up firing of $.document(ready)? It turns out
background-images are only downloaded after the element (containing
div, span etc) is available. This prevents blocking from all the round
trips required to get images.
results: inline image test page
results: background image test page
I wouldn't think there would be a performance issue in the same way as not specifying height and width on a img tag, since that forces the browser to repaint the whole page and that's where the performance issue is.
http://code.google.com/speed/page-speed/docs/rendering.html#SpecifyImageDimensions
tl;dr
You will not get a performance penalty (which is really small in the other case as well).
Some more details:
You shouldn't care (unless you work for Google) about the performance "penalty" you'd get from not specifing a width & height, but more about the layout flickering you might get.
Not specifing a width and height will make the browser display an initial box, as it doesn't know beforehand how much space the image will take, and after the image is loaded it will do a reflow - which means it will have to recalculate the layout of some elements which will be affected by the size change. But, this is actually going to happen very fast (and you're probably triggering reflows in lots of other places).
There is no reflow necessary for the background image.
I don't think this will effect perfomance.
If you combine your background images into one image and position it as and when you need to that will help speed up performance as you're only loading the one image rather than multiple images.
The background image will be displayed as 140x140 unless the div width has smaller size than 140px.
You might also want to check the result in older browsers such as InternetExplorer 6-7-8 just to ensure if there is any other performance issue.
Depends on the browser. I learned today that Chrome currently redraws the canvas as you scroll with an absolute position bg image. Firefox handles it just fine. This should be fixed in a future Chrome release.
On the contrary, specifying the img height and will cause the performance issue.
Because by specifying them, you tell the browser to resize the img first, then render the image. For example, storing thumbnail image is much better than resize the image on the fly.
If your image is already the specified size you want their is no need to specify the Height and Width in the attributes. Also, there will be no performance issue in using the background image.