I had to switch to the newest version of Polymer a few days ago (from version 0.0.20131010).
So I guess the following problem is caused by the incompability between these two versions.
After the page has loaded, all the elements that are contained inside another element are set as visibility: hidden; when I inspect them in the browser.
The outermost elements are visible, but do not have the correct position. They don't float on right edge, as they should.
It seems that it wasn't a Polymer problem.
It didn't float on the right edge, because I did a rotation of this element and
had
transform-ogigin: 0 0;
added to its CSS. Deleting this line solved the problem.
The content didn't show, because I set all the elements inside to hidden on creation and the function to make one element visible wasn't called initially.
Somehow all these problems didn't occur before the version switch.
Related
With the Chrome 87 update, I started getting user-submitted bug reports because some of the fieldsets on a form started to overflow overtop of the content below it.
Here is a fiddle that shows the issue in its most reduced form:
http://jsfiddle.net/phanbu/69v1xa5m/21/
Even though the .box has
.box {
// ...
overflow-y: auto;
}
The contents overflow the container down the page. The funny thing is that changing the .box from a <fieldset> to a <div> makes it overflow in the expected way:
https://jsfiddle.net/phanbu/6Lc4wrma/5/
Because this happens in Chromium, the updated version of Edge behaves in the same way. Is this a Chromium bug, or is there a special thing about <fieldset> elements that I'm misunderstanding?
Update:
Based on the comments below, I've decided to set an absolute height on those <fieldset>s. This means that when there are one or two checkboxes, there will be extra empty space in the element.
I could have converted them into <div>s for now. But that would mean more changes in more places, and I want it to be as easy to change back as it can be.
I'm trying to get create a custom ionic control that will have an autocomplete drop-down. Normally how I would go around this is by creating a nested element of position:relative; followed by an child element with position:absolute;
But for some reason when I tried it on my control in ionic the control get's clipped. Initially I thought to assign a simple z-index would ought to do the the trick, but to my surprise it did not have any effect. Upon some close reading it seems to have something to do with stacking contexts; to make it worse it seems that ionic also marks elements .item-md as position:relative
Any idea how i could make a simple example like this work?
Edit:
I tried to reproduce the case in a simpler setup, but generally, it seems my concept should work. When I put it inside of ionic it gets clipped again.
https://jsfiddle.net/4exLpcv5/
I had a similar situation. Try this for the affected element:
overflow: visible;
After a lot of fiddling around and inspecting the dom tree I was able to partially recreate the problem in jsfiddle. The overflow: visible as mentioned by #willactual is part of the awnser.
Ionic's .item have overflow set on hidden. Which in forces the browser clip out of bound rendering. When I reset the overflow to visible at least in my minimum recreation it behaved as normal. However, trying to bring my example into an actual ionic application, still made the element got clipped.
Now the second part of the solution I stumbled upon by accident is the contain: content. It seems over the years CSS has had some extra properties to act as performance hints. Be it, that ionic actually makes use of these hints and set's the contain property which in result clips the html element.
I'm playing with the isotope js library and I've got the general concept working. My issue occurs when I put normal html/css such as inputs & charts in the isotope div it's not behaving as I expected. This html works as expected outside the isotope div.
When an isotope div is clicked I'm expanding it and showing details for that item, including inputs, charts etc.
My Goal:
Make the table containing the inputs visible in jsfiddle.
Understand why this was happening so I can put whatever content I like in here for the future.
JsFiddle showing answer
Code:
Css that was causing the issue. By adding the asterisk this says applyt he style to all child elements. Hence the reason that my table wasn't showing was that the table, rows, cells, elements were all absolutely positioned.
.containerDiv * {
margin: 0px;
position: absolute;
}
The solution css (apply relative position to the table elements):
#chartFilters * {
position: relative;
}
I've done a quick brush up on CSS and solved my problem - see question for updated fiddle. Was a very simple one in the end, it probably looked hard due to my question hence why there were no answers from the community within the last 24 hours.
I hope my steps help someone else who's new to solving these types of issues, browsers have some great tools built in these days for trouble shooting.
Steps I used for solving:
1.) The first useful step I found was to inspect the element with internet explorer via right click on the page. Then use the right click option in the source it shows to copy element with styles. This gave me a smaller version of the html for testing which I saved into a standalone html.
2.) I started pulling out html elements that appeared unrelated and making the sample simpler. Once I pulled something out I'd refresh the html in IE and check what happened.
3.) When I had a simple html I saw the absolute positioning and the asterisk, I then did a quick google to find this stack question explaining what the asterisk does.
4.) I need to leave the absolute styling in so that isotope works, but I can specify relative positioning inside the isotope, I've done this by using the asterisk myself now I know what it does! :)
#chartFilters * {
position: relative;
}
We wanted some numbered lists and found this cool counter thing you can use in you css to have the browser calculate numbers for you:
ol.instructions {counter-reset:instructions-section;}
ol.instructions > li:before {
content:counter(instructions-section);
counter-increment:instructions-section;
}
The html we're making contains pages of instruction sets, each set numbered from 1,2,3 and so on. Only one set is visible at a time, when you click a header you show that set and hide the others.
It worked like a treat and we were sitting there with smiling faces until someone thought of testing it in Internet Explorer 8, where we ran into some epic Microsoft-style weirdness. When a set was brought up by clicking, all the numbers were zero (0).
I googled around and found this page - it describes the problem fairly well (it's a combination of using :hover and css counter logic used in hidden content), but gives a solution that is less than satisfactory - I would love to be able to keep using the css counters and just implement some ie8-specific hack that somehow makes the page update the numbers. I'm having a hard time finding other stuff on the internet about this problem.
My particular page will describe zeroes until I move the mouse pointer into the div that contains the numbered list, at which point the numbers will magically fix themselves. Is there something I could to "nudge" the page into believing that a mouse is hovering over the element? Or is there a more proper solution?
Ive had the same issue. I was able to fix it by using JavaScript to apply inline CSS of padding-left 0 (there was already no left padding) once the element was visible. This seems to make IE 'redraw' the element.
If, as is suggested, the "hidden" is causing a problem then you could try "hiding" the content by instead moving it off screen with this piece of CSS:
.hide {
position:absolute;
left: -1000px;
}
I've used the code example from the linked to document to show a possible solution here: http://codepen.io/akademy/pen/LDhGl
Does anyone know how to fix (or what causes) the page up/down bug in FF when contentEditable is present on a div?
See an example
Navigate to contentEditable article with FireFox (3 or 3.5) and use the Page Up/down arrows on your keyboard. You should be unable to scroll to the bottom of the page, and it should appear to flicker and jump back up.
I think it's a bug of Firefox which even exists in the newest version, 3.6.8.
For the sample page there are 2 ways to make the page up/down buttons work:
Change all the three DOM node's contenteditable="true" to false.
Find the id="main-content" node, and delete the style float: left;.
Seems the problem for Firefox is contenteditable="true" conflict with the style float:left;.
The only way i can see is to use an iframe... like TinyMCE and CKEditor WYSIWYG editors, they both use iframes. However content loaded in an iframe does not posses the styling rules of its parent. Therefor has to be adapted ... the reason to herald the contentEditable div in the first place.
Since no one answered i'm going to sulk and play with matches