In CSS3 resize, the icon to resize is positioned in the bottom right. How do I make it appear in the top left and make the user able to resize accordingly?
I've found here:
The precise direction of resizing (i.e. altering the top left of the element or altering the bottom right) may depend on a number of factors including whether the element is absolutely positioned, whether it is positioned using the ‘right’ and ‘bottom’ properties, whether the language of the element is right-to-left etc. The precise direction of resizing is left to the UA to properly determine for the platform.
So far, managed to place the icon in the bottom left using:
.fixed {
position: fixed;
bottom: 0;
right: 0;
resize: both;
overflow: auto;
direction: rtl;
}
You can't, it is handled by the User Agent (but you can try rotating it :)
Honestly, I agree with the one commenting that the whole resize property thing should have been left out of the standards:
This shouldn’t be in the standard. Resizable textboxes are a user
agent feature to help mitigate poor design, and giving developers the
option to it is madness. If I as a user want to resize a textbox to
help me enter text, then that should be up to me. The developer has no
idea about the screen resolution, DPI, and physical dimensions of my
device, or any special accessibility overrides or user stylesheets I
have applied, and therefore no way to say I don’t need to resize
something.
Amen :/
Look at the last line from what you quoted:
The precise direction of resizing is left to the UA to properly determine for the platform.
That means the default behavior is browser specific and you can't hack it.
Your only other option is to do the resizing with JavaScript.
A quick Google search led me to this: http://rightjs.org/ui/resizable/demo
Though I am sure you could do this without the JavaScript Library overhead.
Related
I need help. I'm creating a website on Dreamweaver. I have just started learning html and I don't know really what is the best way to position element in CSS. I'm always using this way (example):
.element {
position: absolute;
left: 185 px;
top: 50 px;
}
Am I positioning element the right way? However, I want to keep the same position on different resolution.
Using position absolute should not be your default method to position elements unless you have a good reason to. Usually this is used when you need an element to break out of the document flow.
If you are just getting started I'd recommend to checkout for example https://www.codecademy.com/learn/web (it's free).
At any given time, you should try avoiding position: absolute; and position: fixed; as much as ou can. They can be extremely handy at times, will not deny that, but most of the time you just want to go with the flow of the page.
When you create a new element, you'll naturally see everything will kind of fall in order. The text's go about the same length, they start around the same position horizontally, and the same goes for most other elements. However, when you use position: absolute or position: fixed, you pull a element out of the flow of the page, effectively creating another layer on top of your current page. This means that, while you will have loads of freedom to place it however you would like, it also means there will be problems if you make the window smaller than what you got right now. What happens, for example, if a mobile user visits your page?
That being said, use the already existing css-attributes as much as you can (text-align, vertical-align, even float and/or using margin's can be better) before anything else, when it comes to positioning.
EDIT: Also what stybl said in the comments, if you are just learning HTML and CSS, I'd not recommend using DreamWeaver either. Start off with a good text-editor and/or go to Codecademy instead!
I have encountered a strange bug using my OpenCart website in Chrome. The product images are not showing up but I see the white area where they should come.
If a product doesn't have an image it's aligned to the left but in this case I can see the white area where the picture normally is.
And here's the crazy part, if I click on inspect element, suddenly the image appears.
Some css code
.product-list .image {
float: left;
margin-right: 10px;
overflow: auto;
}
In the CSS you need to set the width and height attributes.
That is weird. Regardless, things to check:
Z-index: The outer box that surrounds the image might be "above" the image itself. Add z-index to the image with a value of 9999 to check
Position: if it's parent container or god knows what else has a weird position it could be affecting where the child element, in this case an image is appearing.
Disable JS - Javascript might be causing an issue here, try disabling it to check.
Also, when you use chrome dev tools, you are technically "hovering" on the image. And you say it suddenly appears. So I'd take a look at your :hover rules as they apply to images. A lot of sites will use a sprite technique that shows one image in normal state, and then shift the background to a different part of the same image on hover. Your normal state could be empty and the hover then moves the bkgd position to the image you want.
Let me know how this turns out.
More scenarios to replicate this issue
1. Close inspect if not already opened.
2. Resize inspect if already opened.
3. Resize browser window.
Just to follow up on this issue, Mary's answer is the correct one, but for our circumstances it was important not to set a width and height in order to maintain responsiveness. But apparently setting width and height to auto works just as well, even though it makes no difference in appearance.
So, since opening the Web Inspector resizes the page in some cases, you should look into:
resize handlers on JavaScript side that might be causing your images to show up
media queries that satisfy certain width and only show images then on CSS side
Picture element having media queries that
aren‘t covering the width you are viewing this with.
For me this was the Picture element having a gap in its media attribute definitions (<source media=(min-width: 1824px)">).
Long story short, I've been using sprite sheets and some of them might have quite huge dimensions. To get the image I need, I use the css attribute clip: rect(top, right, bottom, left), but something strange about clip is that whatever that is hidden is indeed not visible, but adds to horizontal (and probably vertical) scrolling to my browser when the browser window is small enough that part that would have been visible does not fit into the browser window even though they are not visible.
I found that adding a overflow: hidden attribute to any parent of the clipped image solves the problem.
The reason I'm asking here is, if it was my own pages, I'd just add that overflow: hidden to my html tag and be done with it. However, I'm making a jquery plugin and while I'm probably not skilled enough to make plugins that other people will use, I still want to make my plugins well behaved. If I add the css attribute through jquery to the html tag, would it cause unforeseen problems?
I would recommend using background position instead. As explained here: http://css-tricks.com/css-sprites/
It is more industry standard and you won't get those weird issues.
Can I get the small re-size widget that appears in the lower right of text areas (on modern browsers) to appear on the lower left?
You can do that by setting writing direction to right-to-left. This implies that text is aligned to the right by default, but this can easily be overridden:
textarea { resize: both; direction: rtl; text-align: left; }
There are other side effects that you cannot override. The vertical scroll bar will appear on the left. The cursor will appear at the left at times (after typing in a directionally neutral character), even characters will appear on the right when typing only left-to-right characters intermixed with neutral characters – though directionally neutral characters first appear at the left (test with typing “abc (1) x” to see what I mean).
So it comes with features that are oddities when typing left-to-right text, and it’s better to look for a different approach to the original problem (whatever it was that made you want to put the resize handle in the lower left corner).
CSS3 adds a "resize" property that allows you to control whether the textarea is resizable. But as far as I can tell, there's no property that specifies where the handle is. If you want that level of control, you'll have to implement the widget yourself with Javascript (similar to the way the jQuery Dialog widget adds a resize handle to the DIV it creates).
That's not meant to be done, because then the standard of textareas would be very inconsistent and that's what the W3C tries to avoid. The internet should be consistent in some things and the resizing widget of the html textarea element will most likely always be on the right. One thing you can do is use jQuery or other JavaScript techniques to add a resizing widget in the bottom left and cover the one in the bottom right.
Ok I have a really weird CSS issue that I was wondering could anyone suggest an explanation for.
Steps to reproduce:
Open Chrome and navigate to http://www.mcwhinneys.com/media
The gallery of photos should be out of alignment, off to the right by about 50-70px
Open the Developer console in chrome
Expected Result:
i do this to inspect the css expecting to see why the images are off to the side, fixing the css and moving on.
Actual Results:
The gallery of images pops into alignment when the developer tools open.
Anyone know why this might happen? It seems as if the css is fine when I inspect it but it definitely doesn't render correctly until the console has been opened.
Well, the actual cause for the wrong layout is the combination of text-align: center on your ngg-gallery-thumbnail-box (I'll call that box from now on) with position: absolute + display: inline-block on the inner ngg-gallery-thumbnail (I'll call that thumb).
It goes like this:
We apply text-align: center to box. This will cause it to center its inline children. It does this (conceptually) by placing each child's left edge at the current "text cursor" position (which, importantly, starts out at box's center), then moving it towards the left to "recenter" it. This is - also importantly - box's "job".
We declare the thumb as inline-block. This will (among other things) cause it to follow text-align of its parent, meaning that - at this point in time - it's centered.
We then declare thumb position: absolute. This will take it out of the flow, positioning its left edge at the same point where it originally would be - because we're not specifying left/right.
The "naive" interpretation of this would be that it's still at the center of box, and everything would be fine, but we get a "side effect"...
Because we took thumb out of the flow, box no longer has any inline content, meaning its text cursor is at the center, and it doesn't need to center anything. Its "job" is done.
But since thumb is inline-block, it's original position is still based on box's text cursor position (the center), meaning that when we make it position: absolute, its left edge will be placed at that center. It's not horizontally centered inside box, because from box's point of view, there are no children in its flow that need centering.
This is halfways to a chicken and egg problem, so Chrome seems to get confused when it does a re-render of the page for the console.
This explanation may also be a bit confused, but you can see the result here - and even in this simple example, Chrome's console will do a reflow when you try to inspect it. In this example it even seems to enough to resize the window without opening the console (v17.0.963.56):
http://jsfiddle.net/h66Gj/
As far as I'm aware, the way it renders it first, is the way it's "meant to be" (last I checked, the W3C recommendations were vague about it, but at least Firefox agrees with the pre-inspect render).
There are many ways to get around it, my favorite being to only use text-align: center to center... text, and try to use e.g. margin: auto to center other content.
It's really hard to tell, but it looks like it might be something to do with the interaction between the styling of the elements with class ngg-gallery-thumbnail. I would try tweaking/simplifying that. Do you need the display:inline-block setting there, for example?