Webkit bug or intended behaviour? (overflowing DIV and IFRAME) - google-chrome

I've got a problem with IFRAMEs inside an DIV with hidden overflow and I'm curious to know if this is a bug or intended behaviour. It only occurs in Chrome and Safari, FF and IE work fine, so it may be some Webkit specific problem.
My situation is as follows:
site with DIV where overflow is set to hidden
this DIV contains an absolutely positioned IFRAME as well as some other elements overflowing the DIVs dimensions
jQuery function writes some html text to the IFRAME if users clicks a button
Look at this example where everything works as expected:
http://jsbin.com/aqexij/1
Now reload the page with an additional hash character (#) in the url and click the button:
http://jsbin.com/aqexij/1#
In Chrome and Safari this causes the DIV containing the IFRAME to reset the scroll position so that the iframe is on top (in the example above $('#workspace').scrollTop() returns 100 which is exactly the iframes distance from the top).
Can someone explain to me why this is happening?

Related

Chrome rendering issue with fixed element and overflow hidden

I have a fixed horizontal menu that works well on firefox but it's presenting a problem in SOME instances of chrome. When the user scrolls down a white block covers the menu.
You can see the problem here: http://brandca.co/cterranum/
We've inspected the elements but it doesn't appear to be anything in the code and looks more like a rendering issue.
We've noticed that when we erase the element's overflow:hidden the problem fixes but we need this property to toggle the menu.
We haven't been able to pinpoint exactly when it happens since it looks it only happens in some computers and even then, a computer in wich the site rendered correctly had the problem happened oduring a presentation on the projection screen.
The fixed element was somehow screwing webkit's rendering, so I turn the element to position: absolute and on the scroll event I update the top value so it looks like its fixed. It's not pretty but it works.
Element has "position: absolute;" and inside it there is .inner-header which has "position: fixed;".
Try moving ".inner-header" outside of ".header".

What causes VoiceOver to miss in-page links?

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.

The content in my iframe is not clickable in Chrome but works in IE

In my website I have an iframe that is calling another website(a wordpress one). All I am trying display is a calendar in my iframe. Since the calendar iframe is larger than the area specified there is a scroll bar down and across. Also in the iframe are buttons that allow the user to select an event on certain days.
All of these buttons/functions work in IE, but NOT in Chrome, nothing is clickable, it is like the iframe is frozen in chrome.
I do not understand why this is occurring!
Thanks
I see that the div with class offset-by-four is on top of the iframe.
It has padding-left: 300px (in skeleton.css), but since it also has position: relative, I think you meant left: 300px instead. Then it will no longer be over the iframe and the iframe can be accessed.
Note, there are other elements with class offset-by-four too, so you may have to make other changes as well.

Contenteditable Div Ignores Parent Div Margin in IE(9)

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

Scrolling HTML 5 Canvas in IE

I have got a canvas tag in a page wrapped within a div.
In order to show the canvas in IE, I'm using the excanvas script from Google.
I'd like to be able to scroll the contents of the canvas, since it's supposed to be wider and taller than the viewport (the div).
I have defined the following styles:
The div overflow is scroll or auto
The canvas position is relative
In Firefox, I then get a scrolling viewport of the cancas, but in Internet Explorer (7), the canvas does not move.
Does anybody know whether it's possible to get a scrolling canvas in IE, and if yes how can it be done?
Thanks in advance.
You may want to set the scroll property on scroll only.
But not sure, could you put a bit of code for us to see it?