I've relatively positioned one of the elements with negative 'top' and 'left' values, the negative 'left' value actually takes the element outside of the 'body' width, this seems fine in all browsers apart from IE7 where it just cuts it off.
establi.sh
I thought it might be that weird bug where if it's outside the parent container then you have to set a z-index but that didn't work, then I thought it might be the hasLayout bug but trying to fix that didn't work.
I'm not an expert on IE browsers so need some help. I'm thinking IE7 might be choking as the negative left value actually takes it outside the body?
Thanks
E7 doesn't support negative margins the way you want it to. Fortunately, you can easily just increase the width of your body tag, and then increase the left style of the rest of your absolute divs and accomplish the same result.
Related
I am working on a page where there are two rows in the header.
The first row has a "My Account" icon, Company Logo, and Logout.
The second row has a navigation bar.
When the Focus Ring/Focus Indicator highlights an item on the first row, the bottom of the focus ring is cut off by the navigation bar in the second row.
I am not allowed to change the spacing of the elements on the DOM.
Is there a way I can change the layering so that all of the elements on the page are not changed in size or location, but the Focus Ring is not cut off by the navigation bar?
The site built with React.
I've tried googling a number of things, but haven't turned up much specific to this issue.
I'm a little new to programming (my first job, first year). I'm not totally sure where to even start.
You are looking for z-index. The second element is positioned in front of the first element and so it covers the focus indicator.
This allows you to specify how far 'forward' elements are on the page.
Assuming nothing is using fixed or absolute position within the <div>s you are working on this should solve your issue.
i.e.
<div class="container">
<div id="behind" z-index="1"></div>
<div id="infront" z-index="0"></div> <!--The z-index is not really needed here so try without it first, it is to illustrate that the item in front at the moment should have a lower z-index than the one at the back-->
</div>
You may need to play with the z-index in order to get this to work (you can go to 999999 without a problem, but try and use as low a number as possible).
You may also have to fiddle with heights of elements if the site is poorly designed but without a code example I can only offer general advice and gotcha's
Without a code example it is difficult to suggest a solution, but it sounds like your two rows are overlapping, and thereby hiding part of the focus indicator.
Three different solutions come to mind,
Change the height and placement of the two rows to avoid the overlap in the first place
Try using the CSS z-index property to control which element is rendered foremost
Using the CSS outline-offset property, with a negative value, i.e. -5px, to shrink the focus indicator and hopefully making it visible
I'm having an issue with CellMeasurer in conjunction with scrollToIndex on a List. If I set scrollToIndex to some large value (presumably any index corresponding to a row preceded by rows that haven't been measured yet), and then I scroll upwards, the scroll seems to reset back to it's original position repeatedly. Eventually it starts resetting higher and higher up, until eventually I've made my way back to the start of the list.
Relevant Plunker--it's a list with 300 elements (all the same static height so CellMeasurer isn't necessary but it illustrates my problem), and I set scrollToIndex to 150. Try scrolling upward.
https://plnkr.co/edit/XPF5D88WI9CErhkmrgAy?p=preview
Understandably the scroll might not be perfectly smooth since the calculations are based on predicted heights and they're not always going to be correct (in practice at least--in this case they will be correct), but this seems particularly bad/unintended. I suspect (and hope) that I'm doing something incorrectly here--would appreciate any thoughts. Thanks.
EDIT:
On my MBP this happens in both Chrome and Firefox, though it looks slightly different depending on which browser I'm using. On Windows, using Chrome, there is some weird flashing of different rows while scrolling up, but it doesn't seem to reset back to 150 at least.
EDIT:
Here's a gif of the issue occurring - this is on Chrome 60.0.3112.113, Mac OS Sierra 10.12.6:
Seems to be a bug, filed here: https://github.com/bvaughn/react-virtualized/issues/803.
So I'm just trying to grasp this concept. In the image bellow you can see that the total width of the sub elements is 250px, and they are both surrounded by 10 px of padding..So to get the percentage we need to do target/context. The part I don't understand is that to get the percentage of the total width(250px) we calculate that based on the parent's total width(590px), but to calculate the percentage of the padding(10px), we do so based on the parent's inner width (570px).. So why is that? or more specifically why isn't the 250px percentage calculated off the 570px also, as it would seem the 570px div's padding has no barring on the space taken up by the 250px block. What am I missing here?
I found that diagram a bit confusing and it's hard to answer your question using it alone, I hope this example I've mocked up will help (usually easier to look at live code) - be sure to read the source and examine the size of the individual elements using Chrome Developer Tools (the Metrics section and simply hovering over the individual <div>s with the Elements tab open) or your browser's equivalent.
In the diagram, they've used percentages but have confused things by rounding them; never round percentages up/down when doing responsive design, just use the exact figure (or if you're drawing a diagram, show the target and context calculation), browsers (with some ancient exceptions) can always cope with multiple decimal places. (Ideally you'd use a CSS pre-processor like SASS which will do the maths for you).
Also, I've simplified things by just having two columns and floating them left/right, I think the third central 20px column in the drawing makes it harder to understand. Get it working with equal left/right padding for everything first then worry about the more complex stuff, only use a third div if you actually need something inside it.
You also need to be aware of the box-model - the sub elements width is 250px, but if have a 250px wide box and use CSS to add 10px padding either size, the display width will be 270px because it's the width (or height), plus any border, plus padding. This can get really confusing - what you actually want is something that's still 250px wide with 10px left/right padding within it - often it's easier to turn this behaviour off - as in my example - with box-sizing: border-box; (there's a Mozilla prefix needed).
You always use the parent (the element's container) for the context when setting flexible margins or padding. You may note that I've used 570 rather than 590 in the calculation for .rectangle because 570px is the effective width you have to work with for Column 1, the 20px is just padding on either side, I'm still looking at the parent element though, nothing else. The rectangles also have left/right margins to space things out; you could remove those or replace with, say, a right-only margin on the first rectangle if you wanted to have it flush with the column text.
Hope this helps…
I have installed superfish module in joomla 1.5 . I have a problem in IE 6,7 . the width of 'li' elements are not calculated correct and this causes some items fall down. unfortunately I am working on my pc and cann't uploaded it somewhere to show you the site, but I hope maybe it is a common problem and someone can help me.
How can I resolve it?
Common reasons why you might get width issues in IE6:
Quirks mode: Number one cause of layout glitches in IE. Make sure your <!DOCTYPE> is set correctly.
The floated margin bug: If you're using float in your CSS and those elements also have margin, you may find your margins getting doubled. The best work around for this is to use padding or border instead of margin. You may have to adjust your layout to deal with it.
max-width and min-width not supported: IE6 simply doesn't support these CSS features. It will break your layout. Not much you can do about it.
Floats with spaces between them: In some cases, floated elements may appear a few pixels further apart in IE6 than other browsers. IE is inserting spaces between them because it's in the HTML code (maybe they're on separate lines of code?). Remove the spaces and IE will render it correctly.
One of the has-layout bugs: IE has an internal flag called has-layout that has a number of rendering bugs associated with it. You can't set this flag manually; IE decides what it should be based on the other properties of the element. You can sometimes work around it by setting zoom:0; in the stylesheet for the element. But not always.
Further reading: http://www.virtuosimedia.com/dev/css/ultimate-ie6-cheatsheet-how-to-fix-25-internet-explorer-6-bugs
Problem site: www.basing.com/problem/index.html
If you hover over the items in the list on the left you should see a nice popup showing the remaining characters of the text.
However, this doesn't work in IE 7. Does anyone have any ideas why not, or suggestions on how I could go about fixing this? Thanks.
There is a known bug about z-index on IE <= 7, when you use z-index when you mix absolute and relative positionned DOM elements you have to invert the z-index properties so that the lower will appear on top of the higher.
See http://brenelz.com/blog/squish-the-internet-explorer-z-index-bug or http://www.shawnpreisz.com/css/z-index-internet-explorer-7-ie7 for another solution.
There is about a million post about this bug on the internet.