I am building a custom rich text editor. And in its current use, it inserts itself- a div- before a text area that is nested in a div.
This container div is supposed to start out with a top margin that lowers it down on the page, and then the text editor div then sits inline with that.
The problem I am having is, in IE 9, when the editor div gains focus it immediately shifts itself so that its margin-top is 0px. This therefore occurs on the page loading, but also if the user clicks anywhere in the content editable div.
The caret remains at the correct location, but the editor div plus its container have scrolled upward so the editor div has no margin.
This works correctly in IE 8 for some reason.
Without seeing the code, I'm not sure, but have you tried it in quirks mode? There has probably been a fix to make the code work more along standards that doesn't work with IE9. You can either use the built in tools in IE9 to try to identify the problem, or change the DTD and see what happens.
W3 DTD List
Related
I am trying to solve a case where <textarea /> positioned absolute with some top value does not follow it's position if it's inside of overflow hidden parent.
This tiny code example explains it perfectly:
https://jsbin.com/xitayayiza/edit?html,css,output
And here is the video how this code example works:
https://monosnap.com/file/TkEHFXaAXslh3XkakCjkzfvVqLLB0q
On the video you can see when <textarea /> grows up, covering the space above (althogh it has position: absolute; top: 10px;
The question is: Is there a way set via CSS the textarea in the way that it will always keep its top value?
As you can see on the video the top space (above the textarea) is equal to the value top: 10px; but while editing textarea and adding more content into it the space decrease, while I would like to keep it permanently the same.
If you are expecting any decent browser to allow the caret of a <textarea> to be placed into an "out-of-view" or "out-of-reach" area, you are in the wrong. Simply put, it will never happen. With only one exception: when the <textarea> has scrollbars and the user scrolls it so the caret goes out of view. However, any change to the caret position will immediately scroll it back into view.
Why? Because that is considered to be a critical state, as it makes not only the page, but also the browser seem (and, in fact, be) unusable. Which might not be important to you, but is extremely important to browser manufacturers.
When, due to some unfortunate design decisions, the caret ends up in a non-renderable area, as in your example, the browser steps in and makes it visible. It has to ignore/override some of your rules so the caret becomes visible again. Rather than removing the overflow:hidden altogether (which is, in fact, done by some browsers) - most browsers prefer to just "scroll" the contents of the element with overflow:hidden into view (it's not a proper scroll, there's usually no scrollbar involved - it's more of a "shift"); so they shift the contents into a position that allows the user to continue to see the immediate outcome of their input. This change is temporary and reverted as soon as the <textarea> loses focus or caret moves to a (normally) visible area of it.
Bottom line, whenever you place a <textarea> inside a smaller element with overflow:hidden expect it to be shifted around so the caret is always visible.
In practice, you'll notice a <textarea> becomes more predictable and controllable by placing it into a position:absolute parent rather than applying this property to itself. But, again, don't expect browsers to allow you to hide the caret.
You are a meager designer/coder, far less important than any of their active users.
Apparently, losing an active user is a big deal for most browser manufacturers.
Situation:
iOS 7.1
VoiceOver is Enabled
Hyperlink (<a href="#content">) points to:
target element on the page (<div id="content">page contents</div> or <a id="content"></a>)
URL I'm investigating: http://www.yooralla.com.au/whats-on/yooralla-media-awards/yooralla-media-awards-judges-pack
What happens:
Select and activate the link
A border appears on the target element (which is halfway down the screen)
The page scrolls so that the target element is at the top of the screen, but the border stays halfway down the screen.
The closest element to the border is then selected and bordered, so reading starts halfway down the page instead of at the target element.
Closest reference that I can find to this issue is item 1 here, so maybe it is fixed in iOS 8.
But I'm trying to work out why it's happening and how to avoid it on as many devices possible. I've tried linking both to the main content div (which fills most of the page), and inserting an empty a tag, both of which behave the same.
EDIT:
I've tried to force the reading position by setting focus or scrolling with JavaScript, but VoiceOver still ignores this and reads from the wrong place.
I'm testing a new layout in IE 10. When I click the <select> elements at the top of the page, the options display so high they go above the top of my window (see attached screenshot).
Is there any way around this using CSS?
I'm tempted to believe that this is either an OS-related issue, or an IE issue that isn't fixable through CSS or HTML styles.
When I scroll down the page, thereby raising the position of the <select> elements, the list of options appears below the <select> element. Its position as shown in the screenshot is too low and MS tries to compensate by displaying the (admittedly) large list above the element, without taking the screen height into consideration.
If I am wrong, I welcome the correction, but I don't think this is something that can be fixed by the developer.
I want everything in my page to stay put when I scroll except for just one specified element.
How do I magically "hook up" one HTML element to the browser's default scrollbar so that it affects only that one element in my entire HTML document? ... Without using the position:fixed property?
I only need to support Chrome.
I know I'm dreaming crazy, but I'm hoping a CSS/JavaScript/HTML wizard can calm me down a bit with some zany contraption.
I have an extremely strange problem in IE that I can't seem to track down. I have two boxes, both floated left, with a margin-left on the right box to give some spacing between the two. In Firefox (of course), it all displays correctly, but in IE when the page is first loaded, the boxes have no separation (no margin).
Here's the crazy part. If ANY CSS changes on the page at all, the box magically jumps to the correct position. And when I say any, I mean any. I modified the final font name of 3 in the font-family list of the body tag, and the box shifted to the correct position (this wasn't a change that would even modify the look of anything on the page).
I could post my HTML and CSS on the page, but it's fairly routine. I just wondered if anyone had come across or heard of this problem in the past? Incidentally, IE8 seems to render it fine.
Thanks.
Follow-Up:
So I was able to at least patch the problem by floating the box on the right to the right, and removing its margin-left property. Because my container div is just wide enough to accommodate the two boxes, this works for my situation, but it wouldn't be nearly as nice if the two boxes weren't contained so tightly in their container div.
Older versions of IE can be pretty buggy about how they handle floats. Try defining a width on your floated elements. This will help make the layout more explicit (so harder for IE to misunderstand) and trigger hasLayout if you haven't already (a weird internal IE property that causes a lot of layout bugs).