So I have a <select> element on my page, and it worked fine in all browsers until IE8 came along. I've seen all the literature about the IE7 compatibility view and how to use <meta> to force the browser into that mode. But the question still remains: why the heck does IE8 fail to display a simple <select> properly? Has anyone figured this out yet? Here are two URLs that demonstrate the problem. The first one displays properly in IE8, but only because I'm using the <meta> tag to force it into IE7 compatibility mode. The second one is identical to the first, except that I'm not forcing IE7 compatibility.
http://www.currensys.com/mhw.php
http://www.currensys.com/mhf.php
Anyone have any ideas?
Apparently, IE8 doesn't like one of your CSS styles.
SELECT { display: table }
Removing the above style displays the drop down list.
Update: more information from W3School, the value of "table" is not supported by IE.
You have a css property setting display: table on select elements. This seems to be the problem.
I ha d the same problem, not solved with the display:table thing, but it was an issue with the font-family...seems that you have to use standard font only (i used fontface for my site...)
so change the font family to a standard one and should be ok(i don't know why but it worked for me)
Related
See this minimal demo at GitHub: https://github.com/ErikVerheul/PaletteBugDemo.git
I expected that the code line palette.add(new DefaultTheme()); would do the trick. However, it did not.
When changing the Wicket version to 6.20.0 all works fine.
Did I miss something?
help appreciated,
Erik
Short answer: Remove your paragraph <p> and use a <div> instead of the <span> for the palette.
Long answer
The p paragraph cannot contain other block elements. In Wicket 6.x the palette uses a table to layout the "Available" und "Selected" options. In Wicket 7.x divs are used for that, since tables only should be used for tabular data and not for layouting. Neither tables nor divs are allowed in a paragraph though. I guess browsers are just a bit more forgiving when using tables at wrong places, hence you are seeing a somewhat correct result with version 6.x.
Another problem is that you are using a span tag for your palette. Again, the palette is inserting either a table or several div tags, but neither of these are valid in between the span tag.
So something like this should do it:
<form>
<div class="mystyle">
<div wicket:id="palette"></div>
</div>
...
</form>
Problem SOLVED. Thank you Martin! As a Wicket novice I used a version 6 example not knowing the changes in version 7. The working version is now on GitHub.
It does work fine here: http://examples7-apachewicket.rhcloud.com/compref/wicket/bookmarkable/org.apache.wicket.examples.compref.PalettePage
Please check what is different in your app.
Hi all I am using breakpoints for the first time and I had them working fine, but now my site adapts to the mobile layout but not the screen-size for mobile! I can't see any unclosed tags or css erros, any clue what could be causing this?
http://bennyfit.co.uk/
best,
Try putting your css through a validator. This usually shows up errors that are hard to spot normally:
http://jigsaw.w3.org/css-validator/
I'm developing an app that loads a form from another website into an iFrame. The iFrame is set to 100% width and height while displayed. That website has JQTouch.
When I touch an input field in iOS 7 on the iPhone, the keyboard pops up and covers the input fields. It doesn't scroll, resize, or even let me scroll down to see the input field. If I type and then close the keyboard, nothing happens.
I've tried everything I've come across. Adding/removing height=device-height in the meta viewport tag didn't do anything. The thing that came closest to a solution was adding the preference "KeyboardShrinksView = true" in config.xml. That made it scroll (but not enough), and permanently pushes the site up about 20px or so.
I've been working on this for the last couple days with no solution in sight. Is this a bug? Is it the way JQTouch is interacting with PhoneGap Build?
UPDATE: Still no fix, but to test I took the form's page out of the iframe and set it using window.location.href="www.mywebsite.com"; They keyboard works in that situation. This is not a valid solution for me (yet), but may provide info on why it's not working.
UPDATE 2: I'm restructuring the app to use window.location.href, rather than an iframe or html object. This creates some small issues, but these are better than the keyboard not working. If anyone has an answer, I'd still like to see it.
Major Edit: I just realized the InAppBrowser plugin does NOT fix the keyboard bug alone. I did some more research, and this topic helped. I had to add "height=device-height" to every meta viewport tag. "width=device-width" should fix any problems viewing the site in mobile Safari. The final result is this:
<meta name="viewport" content="initial-scale=1, minimum-scale=1,
maximum-scale=1, user-scalable=0, height=device-height, width=device-width"/>
One of these also had a semicolon thrown in there, so be sure to check and double-check for syntax errors, as they may cause the problem.
If this doesn't work, there is another solution that you might try in place of or in addition to the meta viewport fix. It's several comments down in that topic I linked and involves some changes to the CSS. Changes to this didn't fix anything in my code, but it helped at least one person, so it's worth checking out if you still need a solution.
I tested this fix with iframe and object, and it didn't work--InAppBrowser is still necessary.
/Major Edit.
Here are some workarounds that worked for me:
Use the InAppBrowser plugin. This allows the app to interact with loadstart/loadstop/loaderror events in the loaded page within the InAppBrowser. This is the solution I suggest. However, with iOS 7, you will need to hide the status bar manually, the solution for which is here
OR Load the page using window.location.href = [website url]. If you don't need to worry about interacting with or returning to the app or linking to external sites (both of which I needed), this is the way to go. It's pretty simple, but lacks some of the functionality of the first solution.
OR Get rid of JQTouch. I wasn't able to do this, but much of it is redundant when you're building an app with PhoneGap.
I'm working on joomla 1.5 and I have this form and it has a Save and Close button but it is not working on IE browsers. The conflict on MooTools.js and jQuery.js is resolved but still the buttons don't work. What is the possible cause of this?
Thanks,
Justin
Steps to trace the bug.
1. form name should be "adminForm"
all hidden variable present in the form like option, task, view, controller. whatever you are using in your component.
I am using the HtmlEditor Control included in the AjaxControlToolkit (patched version v62210 because I needed some of the included fixes).
Unfortunately the textarea in the Html Editor control is never displayed in Chrome and Safari (both latest version). It doesn't matter if there is text in it or not.
It does work on the AjaxControlToolkit Sample page with both browsers though.
Any ideas?
fixed it with the following css definition:
#ctl00_CR_TabContainer_TabPanelDetails_tbText_ctl02_ctl00
{
height: auto !important;
}
The selector is page specific but can be determined easily using Firebug.
Try to set this property of the editor:
InitialCleanUp = true
This should resolve chrome and IE9 postback issue also.
just define height and width in chrome browser, so text area will appear. as example.
height="300" and width="500" in Editor property.
Ok, I know this is a year too late, but I had this same exact problem, and I fixed it by setting the height property from the code-behind. I wasn't able to use #simmonw 's answer because I am adding mine to the page dynamically and I had no way of knowing what the selector would be named. Anyways, hopefully this will help someone.