Im working on a new website, http://blgz.co/, and for some weird reason, all my images are being squeezed!!!!!. I have spent the last few hours trying to solve the problem to no avail. Any help would be great! Thanks.
Can't figure out why you're adding the max-width declaration to your global img tag. Remove that and all your images will flow normally:
img {
height: auto;
max-width: 100%; /* remove */
}
This is because of you max-width: 100% style, you're applying to img tag. In your case it is 23px only and this is because its parent .node .field-name-field-op-main-image has float: left, this means it will act as a inline element (but won't take into account width of you image or probably you set your image width later).
In other words remove either float:left or max-width:100% and you will get the "desired" result
I'm late to this party, but I just ran into this issue myself, and simply removing max-width or not floating the parent element were not options. As a result, I had to find a real solution: just add width:auto;, e.g.:
img {
height: auto;
width: auto;
max-width: 100%;
}
That ironically worked wonderfully in every browser but Chrome 20, which then began to behave as IE8 used to. So I resorted to a CSS hack to target IE8 only:
img {
height: auto;
width: auto\0/;
max-width: 100%;
}
Now before everyone freaks out, I chose a CSS hack because I'm making this particular change in the Bootstrap CSS Framework's reset, which already uses hacks in other places. If you want to go the white-hat route, then you can simple add a conditional comment to your HTML:
<!--[if !IE 8]>
<style type="text/css">
img { width: auto; }
</style>
<![endif]-->
One more note, if you're using the hack above in a *.less file, you have to escape it or the LESS compiler will choke on it:
width: e('auto\0/');
In my case for some reason IE8 did not want to obey the explicit width: 46px; CSS.
Fix: Adding min-width: 46px; forces IE8 to render the correct width without breaking other browsers.
Related
I've noticed a strange bug while using a textarea in a my project.
At first I thought there was a problem in my code but then I was able to replicate that bug extracting the essenial in a JsFiddle .
The problem is:
If I change the height of the textarea by code without any interactions from the user before, the height get stuck at that size.
For example, if you click to the button "Change size" (in the jsfiddle above) and then try to resize back to the initial size using the element grip (at the bottom-right corner), you can't. It's like if that new height is the new ''minimum allowed size'' of the textarea.
What am I doing wrong? what am I missing?
Thank you in advance.
Height overrides min-height in Chrome.
In older versions of chrome there was no restriction.
So if you use height min-height will be your height. So you need to
set min-height and max-height only. Height overrides min-height in
Chrome.
textarea{
max-height: auto;
min-height: 50px;
resize: both;
}
Okay this solution works for me (chrome Version 47.0.2526.111 m):
https://jsfiddle.net/ezsz8xr5/9/
I found this interestining link: https://code.google.com/p/chromium/issues/detail?id=94583
Seems that it is a known issue.
I know this question has been asked a while ago, but there's no good answer to it, and I found a solution.
What I found is that putting a % height for the textarea will not change it according to its parent.
If you put the rule resize: vertical, changing manually the height you'll notice that your browser will put the style.height in pixels.
So I tried putting height: 150px and it worked.
So here are two solutions :
First, put your textarea's height in pixels, not in percentage.
parent {
width: 150px;
}
parent textarea {
height: 100%; /* not working ! */
}
/* Instead, do : */
/* css variable */
:host {
--height: 150px;
}
parent {
height: var(--height);
}
parent textarea {
height: var(--height);
}
For a SCSS way :
parent {
$height: 150px;
height: $height;
textarea {
height: $height;
}
}
Second, declare the textarea parent's display as flex, and without any additional rule, it will automatically resize your textarea. If it does not, then do this :
parent {
display: flex;
/* if flex doesn't work by itself, add this + textarea rule : */
flex-flow: column nowrap;
}
parent textarea {
flex: 1; /* tells the textarea to fit all the free space it finds */
}
It seems like a browser issue yes, still not fixed in 2022, sadly. If it is intentional, then it's even not documented.
Hope this will help someone in the future.
I just encountered a strange issue on ie11. I am trying to create a fixed element that will scroll along with window scroll.
$(window).scroll(function() {
var scrollY=$(this).scrollTop();
$('.myelem').css('transform', 'translateY(' + scrollY + 'px)');
});
I have also created a fiddle of this:
https://jsfiddle.net/fyngwnz6/1/
(This is for replicating the issue, I know this particular case could be solved with a fixed element)
The code works flawlessly with no performance issues on every browser, except ie11. When using the scrollbar 'myelem' element scrolls with just a small jitter which becomes more obvious when using the mouse wheel. However, where you can really see the issue is when using the scrollbar buttons. It seems like the render of the scrolling has to finish in order for js to track the scroll.
I saw that there were issues with ie11 and smooth scrolling, but this is not the case here. Is there any kind of solution to this? Am I missing something?
edit: although I have an answer that seems to solve the issue, actually what I am looking for is a solution to elements that have overflow:hidden applies on them and the scroll is taken from an overflown element rather than body scroll; a similar scenario can be found here:
http://www.fixedheadertable.com/
If 'fixed column' is enabled in the example, then clicking on the scrollbars shows the jerkiness in the movement.
It seems like adding height: 100%; and overflow: auto; to the html, body elements removes the IE 11 issue:
JsFiddle Demo
[Edit]: Adding margin: 0; removes double scrollbars.
for edge use:
/*Edge - works to 41.16299.402.0*/
#supports (-ms-ime-align:auto)
{
html{
overflow: hidden;
height: 100%;
}
body{
overflow: auto;
height: 100%;
position: relative;
}
}
/*Ie 10/11*/
#media screen and (-ms-high-contrast: active), (-ms-high-contrast: none)
{
html{
overflow: hidden;
height: 100%;
}
body{
overflow: auto;
height: 100%;
position: relative
}
}
I know how to ensure that the HTML body vertically stretches/shrinks to 100% height of the browser viewport (by having 100% height in the body and html rules).
I also know that normal HTML flow will result in containers vertically stretching to contain their contents (if things are set up properly).
Yet, I cannot seem to achieve both.
I.e. I cannot beat CSS into ensuring that when my page is viewed on a high resolution screen that it vertically stretches to leave no gaps AND to ensure that if my page is viewed on a lower resolution screen that the body stretches past the viewport (to accommodate all the content) and introduces scrollbars.
To me that is ideal behaviour and yet I sadly believe that this cannot be achieved purely in CSS. I know I can do this in JavaScript quite easily, but I want to be able to do it just in CSS.
Is it possible, or am I forced to use JavaScript?
Edit:
I have researched, tried and test so many techniques, but it just seems like it can't be done. Looks like I am going to have to go back to JavaScript.
OK so this definitely works for me:
html {
height: 100%;
}
body {
min-height: 100%;
display: flex;
}
#wrapper {
width: 100%; /* Necessary because of side-effect of flex */
height: 100%;
}
Exactly what I tried before, but I thought I would give this new CSS feature "flex" a go and it has done the trick. So it looks the CSS managers/creators have finally addressed these critical issues with dynamic height and vertical centring.
I hope this helps someone else stuck on this issue.
You can use the min-height css property.
html, body {
min-height: 100%;
}
min-height: 100%; /* other browsers */
height: auto !important; /* other browsers */
height: 100%; /* IE6: treated as min-height*/
Taking inspiration from a question which seems to be pretty much the same as mine: Make body have 100% of the browser height
This is working for me:
html {
height: 100%;
}
body {
min-height: 100%;
}
I wrote a small script to let a label move out of the way everytime the corresponding input field is needed.
Please check it out here: http://jsfiddle.net/5nZWJ/68/
The problem is: it works just as expected in Firefox, but all other browsers I tried (Chromium, Internet Explorer and others) don't keep the bottom-border justified (hard to explain but you will see it if you try it out).
What do I have to change to make this thing in all browsers look like in Firefox?
Thank you in advance!
I have solved your problem. It is now smooth in all browsers: http://jsfiddle.net/5nZWJ/70/
The key is having #formWrapper positioned absolutely from the bottom. This means when the height is increased it expands from the bottom up and doesn't need to recalculate the position from the top.
CSS:
#wrapper {
background-color: lightblue;
height: 110px;
width: 500px;
position:relative; /* Allows absolute figures to be predictable */
}
#formWrapper {
background-color: yellow;
border-bottom: 4px solid red;
bottom: 29px; /* Changed from top and new measurement added */
left: 120px;
height: 57px;
position: absolute;
z-index: 1;
width: 108px;
}
JavaScript:
I removed all lines of code referring to the position, as it no longer needs to be changed or recalculated.
I think this might be related how different browsers count border pixels
http://ejohn.org/blog/sub-pixel-problems-in-css/
(not actually the same problem, but you get some idea)
Instead of using border, I recommend you add a div wrapper around the element, with the background color set to border color and padding set to the border width.
+-----------------------------------------------------+
|.....................................................|
|..header height: 128px...............................|
|.....................................................|
+-----------------------------------------------------+
|.............|.......................................|
|.sidebar.....|..Lorem ipsum..........................|
|.width:......|.......................................|
|.140px.......|..+---------------------------------------------+
|.............|..|xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx|
|.............|..|xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx|
|.............|..|xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx|
|.............|..|xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx|
|.............|..+---------------------------------------------+
|.............|.......................................|
|.............|.......................................|
|.............|.......................................|
|.............|..frame should be as large as the......|
|.............|..entire viewport or larger depending..|
|.............|..on the context.......................|
+-----------------------------------------------------+
I am trying to create a 2 column layout (sidebar + content area) with a header (and possibly a footer) where the sidebar has a fixed width and the content area is fluid.
The difficulty is having the content area effectively wrap its contents so the content doesn't overflow.
I'd like to know if there is a CSS way to do this and if not whats the best Javascript approach to it since I had some difficulties with cross-browser support.
Try this.
#content {
margin-top: 128px;
maring-left: 140px;
}
#sidebar {
position: fixed;
left: 0;
top: 128px;
width: 140px;
}
CSS:
#element { word-wrap: break-word; }
This will do it for you:
HTML
<div id="header"></div>
<div id="sidebar"></div>
<div id="content"></div>
CSS
#header {
height: 128px;
}
#sidebar {
float: left;
width: 140px;
}
#content {
margin-left: 140px;
}
You can see an example here.
After having researched the matter substantially, I've concluded that it simply can't be done with css in a compatible way (and I'm not even considering IE6). The possible solutions involve either javascript or tables.
I picked the lesser evil (tables) since javascript resulted in a more complicated solution and handling the onResize event can be taxing on the browser depending on the complexity of the function called.
Certain search engine concerns are not important given it's an intranet application.
The only real issue is accessibility.
I'd be quite glad to be proven wrong though :)