I was just about to create a bug on the chromium issue tracker, but then I thought I would give it a try here first.
Try having a look at this site:
http://www.norabrowndesign.com/css-experiments/border-image-frame.html
However it appears that chrome does support border-image-outset now or so I thought.
It responds to the command, but does not behave as I would expect.
Is moves the images outward and thus creates more whitespace around the content instead of less.
Reading the spec I am not sure if chrome is wrong in doing what it does, but it certainly seems the author of the linked site expected something else.
Further more, if the present behavior is correct then I cannot see what the purpose of it is. And the problem with the large border image, will have no solution at all.
So what is it, should I submit a bug or?
I believe Chrome behaves as it should. border-image-outset is supposed to extend the border image area beyond the border box. It seems to do that in Chrome.
Removing the whitespace around the content would require the opposite which can be achieved with the help of border-image-width.
border-image-width divides the border image area and is basically the counterpart to border-image-slice (which divides the border image). It's initial value is 1 (multiples of the corresponding computed border-width). So without assigning a border-image-width every slice would be resized to border-width.
See border-image-width at w3.org
To remove the whitespace around the content while keeping the size of the border image you would have to reduce border-width and set border-image-width to an appropriate value.
Try the following changes in the example from your question:
#one {
border-width: 74px;
border-image-width: auto;
}
Related
We are using the latest Chrome, and Windows 10,
69.0.3497.100 (Official Build) (32-bit)
On some monitors, there is a Select/Dropdown control that is missing borders. Sometimes it's the right one; then when I play with width (make it px rather than percent, add more width) it becomes the bottom one.
But on other monitors, this Select/Dropdown is always fine. It always has all the borders. There is never any problem.
All the monitors are Resolution 1920 x 1200 (Recommended in Windows 10), both the ones that have and don't have this problem. Tested with different zooms - 100%, 80%, 120%. Either some users have this problem (always), or they don't (ever), all with the same browser, at any zoom level.
There is no special CSS styling on the control. In fact, even if I were to add a border: 1px solid it wouldn't affect the system choice area. It would only affect the top-level box.
The closest I could find was that there was a bug in Chrome a long time ago, like 2012, but it's long been fixed, so we can't use this info.
Chrome isn't displaying borders (sometimes)
Any thoughts?
Adding another wrapper div helped me to solve this issue.
<div class="dropdown-menu-container">
<div class="dropdown-menu">
// items
</div>
</div>
I added border to dropdown-menu-container and added overflow-y: auto property to dropdown-menu class.
This solved my issue. Hope this helps.
Check to see if a parent div of the drop-down control lacks an "overflow:visible" CSS attribute.
Per you image examples, constraints of the parent div appear to be cutting off the drop-down when displayed.
Also, consider using Chrome's Inspect function to analyze this issue.
In Chrome, right-click on the drop-down, then select Inspect. You can also make CSS updates specific to your browser with Inspect to see how this changes the appearance. Once it looks good, you can go back and update the applicable files accordingly.
I know it's late, but I've just recently encountered this bug, and was able to fix it by adjusting the font-size of <option> elements. Try fiddling around the font-size until you can no longer see the issue, this is how I fixed it.
Apparently the issue occurs while trying to set padding or width on the select element.
adjust
#dropdown { overflow-y:auto;}
I've been looking at this small issue for a while and I can't seem to fix it. It's an firefox only bug it's fine in IE Chrome etc.
This website I made for a client shows the issue. On the start of the page you see 2 wheel PNG images Three of these images are there, you can switch the z-index by clicking the round circles on the bottom of the image.
As you see the Black colour is slightly more down, I can't seem to wrap my head around the issue since the line height is 0 and the way the black image is positioned is the same as the grey one. They are slightly downsized due to a max-size: 100%, but resizing them to the proper (1000px) doens't seem to help either, (did this locally).
If you open the pictures in photoshop or w/e they're exactly aligned.
Anyone have any idea why it goes wrong on Firefox only?
--> example
Removed the example since it's a website.
Very weird issue indeed. The only thing way I could get it to go away was to absolutely position the wheels. this would require you to set a height on #infographic and take off the margin-top:-100%;. Depending on how you use the #infographic container this solution might not be ideal for you, but at least something to consider to help solve your issue.
It's because of the whitespace between the elements. Unfortunately, some browsers observe it and thus some space is shown although it shouldn't. You can use this workaround:
Generally work with rem instead of em, you need it for this workaround to work easier. First you have to set the font-size of .infographic to zero. Every element inside your .infographic will now become a font-size of zero because you're using em. That's the reason why you should now change to rem, at least for the elements inside .infographic.
Now you're done.
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)">).
Check out the following:
http://jsfiddle.net/symposion/P8KBe/7/
in IE8 and then Chrome/Firefox/IE9+. You will notice that in IE8, the inner blue div is sliced off at the edge of the outermost #slicer div, despite the fact that it is only #outer that is overflow:hidden. If I change the min-height on #outer to an explicit height, the problem goes away.
The example may seem contrived, but only because I've simplified it right down here. I've encountered this in a real project and it's causing a headache because I have limited scope to change the layout principles being used - there are too many other dependencies. I'm looking for two things here:
Is this a known bug listed somewhere? What is the simplest statement of the issue? I still don't feel like I really understand the underlying error that is causing IE8 to get this wrong; it's still not a particularly simple test case.
Is there a workaround that doesn't involve changing the styles of #outer and #slicer? In my real world example these are part of a larger page framework that I'm going to have trouble changing, whereas the #inner bit is more readily under my control.
(Update) The original example is very contrived in an effort to be minimal. I have created a new JSFiddle here: http://jsfiddle.net/symposion/NDa6U/ that gives a slightly better view of the real-world problem. If you resize the html pane in IE8, you will notice that eventually the green inner content section starts getting cut off incorrectly. What I'm looking for is for this section to remain 100% of the height of the div it's contained in, ideally without having to make any significant changes to anything other than #innerContainer. But to be honest, I'd be interested in any solution that preserves the basic layout principle (a bottom section that expands from a defined pixel position to a defined distance from the bottom of the page, but has a min-height) that works in IE8.
How about http://jsfiddle.net/thirtydot/NDa6U/22/?
#innerContainer {
padding-bottom: 9999px;
margin-bottom: -9999px;
}
Here's some (relatively) old background information about this technique: http://www.positioniseverything.net/articles/onetruelayout/combined
From personal experience, it works in all modern browsers with no problems.
See this link:
http://lsp2.tpdserver2.co.uk/test.htm
Displays fine in IE/Chrome but in Firefox (6.0.1) there is a 1px border around the blue header.
If I add a background color to the #header-content, the 1px white border dissapears. This seems crazy.
I cannot work out what is going on with this and the related page I am trying to build depends on not having a background colour for the 2nd fixed container.
Here is an image of the problem I see:
Link to Image
It is layout rendering bug in Firefox. This bug was already reported and as I know it is fixed in next release. Only solution I know is to use opacity:0.9999999. It would render correctly as opacity:1, but fix this annoying bug.
Try #header { opacity:0.9999999; }
Bugzilla : Bug 677095
EDIT: Firefox 8 is not affected with this bug and setting opacity to 0.9999999 will result in weird border around the element, so I prefer not to use it anymore
Browsers add different defaults if you don't "reset" the CSS, that may be what is going on here.
If the z-index value of your #header-content is not greater than 10, then the bug is fixed. If it's 11 or greater then I can see the mysterious gap too.
Really weird.
I cannot reproduce in FF 6.0.1; however, you can probably work around this with
background-color: transparent;
on the #header-content, or white if you don't want it being see through.
This should still give the fix you mentioned while remaining a blank div as required.
Update:
Ok thanks for the screenshot, still cannot reproduce, this time with ff 6.0.2 - I had a look around after noticing I can reproduce a similar issue on different zoom levels.
Blog post explaining the zoom border bug, which includes this test page. I am not sure if this is involved, seems similar but not the same thing, zoom bug will take off a slice of the whole page including the border of #header-content.
As for your comments around transparent, you can use it and still supply a background image, does this not work for you?