Took me sometime to replicate this in jsfiddle. But I did it:
https://jsfiddle.net/zhankezk/uvmxq6we/2/
Steps to replicate:
Click in search textbox, press tab key
Issue:
the search textbox and search button shifts up
Expected:
They should stay where they are.
The html here are pieces from the actual site. But I noticed that issue happens only when it's under "global-nav theme--personal" div and the reason that I feel this is a Chrome bug is because firstly, it's working fine in Firefox and IE. Secondly, after pressing tab and it shifts places, if you adjust any vertical styling, the issue will be gone, for example, you can uncheck "position:relative" for div "global-nav__search is-expanded" and tick it again. the issue would go away.
<div class="global-nav theme--personal">
<div class="c-search fn_search-suggestions">
<div class="global-nav__search is-expanded">
<input type="search" class="search__field" placeholder="Search" name="query" data-target-url="/personal/personalsearchresults" autocomplete="off">
<span class="vh">Search</span>
</div>
<div class="c-suggestions" tabindex="-1">
Search for ‘home’
</div>
</div>
</div>
I can be totally wrong, thanks anyone in advance for helping!
This one's weird to me, and I'm not totally sure it doesn't represent a bug in Chrome (and/or perhaps an accessibility feature?), but it seems that Chrome is
overflowing the large "Start" content as hidden as expected (even though it's absolutely positioned, its parent is relative)
not hiding the overflowing absolutely positioned child (as expected?) since the overflow:hidden'ed container isn't absolute/relative positioned itself, but it seems that
when tabbing to the absolutely positioned element's link, Chrome suddenly seems to want to take into account the content before it, including the bigger "Start" link, so it seems to be "scrolling down" the content of the overflow:hidden'ed element for you (even though what you're changing focus to is already visible because of the absolute positioning).
(At least I think that's what happening. Especially because I couldn't see any CSS properties changing in the Inspector when tabbing back and forth.)
So what to do? It seems that two workaround are to either
change the line-height property of that "Start" button to match the font-size (1.625rem), I guess so that it's height is taken into account for the overflow, and/or
set an explicit (and big-enough) height on the .global-nav .c-search, I guess so that Chrome doesn't get "surprised" by different contents' height in the overflow:hidden element.
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.
Once again I am reminded why I hate GUI programming.
I've boiled the problem I'm seeing down to this very simple HTML test case:
<div style="padding:5px;background-color:#ccccff">
<form>
<label for="username">Username</label>
<input name="username" />
<label for="password">Password</label>
<input name="username" type="password" />
<button type="button" id="logout">Login</button>
</form>
</div>
When I enter it into jsfiddle's HTML area, it renders as I would expect, with nice, consistent padding all the way around (the light grey behind the purple is jsfiddle's default bakground):
But when I put that exact content -- no more, no less -- into a .html file in the document root of a server on my laptop, and then load the page, it renders like this:
What's that extra chunk of <div> doing below my labels and controls? And why the difference?
(Both examples were rendered in the same instance of Chrome Version 47.0.2526.106 (64-bit), running on a MacBook Pro, OS X 10.8.5.)
For the first example (served by jsfiddle), Chrome's box-visualizer widget looks like this:
For the second example (served off my machine), the box-visualizer shows this:
but if I subsequently remove the padding property from that second example, the height of the inner box drops back to 19px.
Whatever is going on, it seems to be related specifically to bottom padding, because:
even if I change the padding property to "padding:5px 5px 1px 5px", the inner box is shown to be 35px high.
but if I change the padding property to "padding:5px 5px 0px 5px", the inner box height reverts to 19px.
I have no clue where I should start looking to debug this.
(BTW, I've already tried both border-box and content-box for box-sizing, but neither choice seemed to change the behavior I'm observing, in either place.)
That's actually a bottom margin on the form element. This bottom margin appears only in quirks mode, which is being used to render your page since there is no DOCTYPE accompanying your HTML fragment.
The div element is unaffected, but its padding does prevent that bottom margin from collapsing, which is why you can see it only when the padding is there. Removing the padding allows it to collapse out of the div, so you don't see the portion of the div background that it would have otherwise occupied.
Since box-sizing has no effect on margins, changing it on any of the elements won't have any effect.
In general, any time you are working with HTML (and CSS), the very first thing you have to make sure is that a valid DOCTYPE is present that will trigger standards mode. In HTML5, it's <!DOCTYPE html>.
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".
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 have an issue with website markup on WebKit browsers (Chrome & Safari), i.e. when I type something in edit box of right-slider, it scrolls the left area.
Please take a look at following example:
http://jsbin.com/obiyec/7
http://jsbin.com/obiyec/7/edit - html code (input is inside div with id="palette")
Open next link in Chrome or Safari
Type something in edit box in right upper corner
Notice that scrollbar in left area shifts
It is very unlikely to change this markup radically if possible
Q. How to prevent scroll-bar from shifting and make it behave same way as it is in FF?
The problem here is that what it looks like you are doing and what you are actually doing are two different things.
It looks like the div on the left with a fixed width and overflow: auto (div#kb-board) and the input field on the right are unrelated elements - but they are not. The input field is actually a child of div#kb-board but its parent (div#palette) has fixed positioning so it sits in the top right of the page.
As a result, the input field is actually on the right hand side of div#kb-board and when you type in it the scroll bar moves as you are giving focus to the right hand side of that div.
So in this case, I would say Chrome is showing the correct behavior.
To resolve this you should stop nesting div#palette within div#kb-board. Since it uses fixed positioning, there is no need to nest it.
<div id="kb-board">
<div id="boards-container">
<div id="lane">...</div>
</div>
<!-- div#palette was originally here -->
</div>
<div id="palette">
<input type="text" value="Type here" />
</div>
Working example: http://jsbin.com/obiyec/8