I am fairly new to Angular and I am developing an Angular web-app which needs to work across IE11, Chrome and mobile.
I have the following HTML:
<input ng-model="myDate" type="date"/>
Which has the desired behaviour on mobile and Chrome. To make it work on IE11 I have imported HTML5 forms via:
<script src="bower_components/html5Forms.js/shared/js/html5Forms.js" data-webforms2-support="date" data-webforms2-force-js-validation="true" data-lang="qq"></script>
For IE11 this at least brings up a calendar, however if I do
console.log($scope.myDate);
it does not pick up the value that the IE calendar had selected, leading me to believe it doesn't work the angular way. If I gave the input element an ID and use document.getElementById I can retrieve the value. For Chrome it does print out the scope value, and can only assume it does for mobile too.
My question is then how do I make the type="date" work across all 3 instances? Am I perhaps using the html5Forms.js module wrong, or is there an alternative?
I am aware of the type="text" solutions out there and then use https://material.angularjs.org/latest/demo/datepicker, but is that really the only solution I have available? I also need to sometimes use datetime inputs, which the angularjs does not have an example of, however type="datetime-local" works as I want it to, except in IE.
I am using version 1.6.6 of Angular.
Related
I have come across a strange issue which seems to be browser related(IE9 and lower vs. IE11), but would like to know why the strange behavior.
Issue Description:I use a spring framework and use its related taglibs to retrieve data on my JSP. There is a variable called index which I retrieve from the form and it used to be retrieved in the following manner.
<html:hidden property="index" name="pdmAcctSuppressForm" />
Value for the above variable namely index was accessed in a javascript using the following code snippet.
var index = document.getElementById("index").value;
The javascript seems to work as expected and retrieves the actual value in all IE browsers until IE9, but seems to fail to work on IE11. document.getElementById("index") returns invalid on IE11.
Solution: The problem has been resolved by changing the above mentioned taglib implementation from
<html:hidden property="index" name="pdmAcctSuppressForm" />
to
<input type="hidden" name="pdmAcctSuppressForm" value="${pdmAcctSuppressForm.index}" id="index"/>
I would like to know what has been changed on IE11 which renders the implementation unusable and also if the solution I have quoted is the right and efficient one.
The javascript seems to work as expected and retrieves the actual value in all IE browsers until IE9, but seems to fail to work on IE11.
...
I would like to know what has been changed on IE11 which renders the implementation unusable and also if the solution I have quoted is the right and efficient one.
You should have had that problem with IE8 as well. Through IE7, IE had a bug: It found elements using getElementById that didn't have the id you asked for, but did have a name that matched. That is, in IE8 and earlier:
<input name="foo">
...would be found by document.getElementById("foo").
This was a bug (although for a while Microsoft called it a feature, and documented it), and it was fixed.
More (on my blog):
...by any other name, would smell as sweet
I'm Using Primefaces 5.0.9 with Wildlfy 8.1 and JSF 2.1.2
I have an autocomplete defined as follows:
<p:autoComplete label="CAT" id="CATEGORY" dropdown="true" value="#{UserDownloadFileBean.editUserFileCategory}"
completeMethod="#{UserDownloadFileBean.categoryAutoComplete}" converter="#{UserDownloadFileCategoryConverter}" forceSelection="true"
var="item" itemLabel="#{item.name}" itemValue="#{item}" required="true" requiredMessage="Please choose a category!" >
<f:ajax event="itemSelect" update=":UploadFileCategoryDialogForm" />
</p:autoComplete>
This works perfectly fine with all browsers EXCEPT Firefox (tested with v32 and v34).
When I select an entry in the suggestions the panel doesn't hide. The only way to close it is to click outside. The firebug Console delivers this error:
ReferenceError: event is not defined
Examining the generated javaScript Code the Problem is obvious:
function(){PrimeFaces.cw("AutoComplete","CATEGORY",{id:"createUserDownloadFileForm:CATEGORY",widgetVar:"CATEGORY",delay:300,deletionDelay:600,forceSelection:true,behaviors:{
itemSelect:function(ext) {mojarra.ab('createUserDownloadFileForm:CATEGORY',event,'itemSelect',0,0,{'CLIENT_BEHAVIOR_RENDERING_MODE':'UNOBSTRUSIVE'})}}});});
The variable event is not existing (i guess other browsers provide it anyways?).
In the Showcase (Pf v5.1.7) the code uses Primefaces.ab and ext instead:
$(function(){PrimeFaces.cw("AutoComplete","widget_j_idt88_event",{id:"j_idt88:event",widgetVar:"widget_j_idt88_event",delay:300,behaviors:{
itemSelect:function(ext) {PrimeFaces.ab({s:'j_idt88:event',e:'itemSelect',p:'j_idt88:event',u:'j_idt88:msgs'},ext);}}});});
Was this fixed some time after 5.0.9 and if so is there a way to gain a working version in 5.0.9?
Otherwise what could i have done wrong that it does not use the same function?
This has been reported as a bug to primefaces, and I posted a patch to their code to fix it. In my case, I had to build a new jar in order to get this to work without converting the hundreds of f:ajax elements everything over to p:ajax.
In my web application I'm using an input type range element.
<div id="fontSlide">
<input type="range"
id="rangeBar"
min="0"
max="2"
value="0"
onchange="EM.adjustFontSize(this.value)"
title="Scrolla per cambiare la dimensione del testo">
</div>
Unluckily, it is not supported by Firefox and Internet Explorer before version 10.
I could create an alternative HTML for Internet Explorer using conditional comments, but how can I handle it with Firefox? Can I specify somehow at least a different CSS (hiding it could be OK)?
I prefer not to use Jquery.browser because I know it is deprecated, and also to import something like modernizer.js just for one check is too heavy. The best solution would be one single JavaScript check line, something really light.
CSS hacks are my last recourse. I used it and made it work weeks ago, but then I updated my Firefox version and now it is not working anymore. This made me realize that CSS hacks are too risky.
Use jQuery UI, more specifically Slider. It will save a lot of time.
I have created lots of buttons for a large number of pages (usually 5-10 in a row at the bottom of each page inside a table cell) using input type="button" name="..." value="..." onclick="some javascript event handler" etc, basically to link to other pages of the same group. All these pages are ultimately linked from an iframe tag on a single page. The buttons are working fine offline on my PC at least. But, now I've suddenly realized that I haven't used any 'form' tag for these buttons.
So my question is, is this 'form' tag really necessary? Will there by any problem after I upload? I would prefer not to add the form tag now to so many pages if it's not really necessary, because that's going to be a real drag. But, I don't want to suffer afterwards either.
No it is not necessary as long as you are not doing any Get/Post and grouping form elements together. They should work completely fine without a form tag.
There are two issues to be concerened with:
Is it valid HTML?
Turns out that it is valid HTML (see Is <input> well formed without a <form>?), so you are on the safe side here.
Will all common browsers accept it?
After googling around I haven't seen any information on problems wih this use of Input tags. That suggests that all common browsers accept this valid HTML (as they should). When developing any website that is accessible to the general public I would always do a manual cross-browser check to discover any abnormalities certain browsers may habe with my site.
Problem is that you most likely won't be able to tell from looking at your server logs whether certain browsers have a problem with your HTML. It may just not work on IE 6 and you would never be able to find unless a disgruntled customer calls up and informs you.
If this is a generally accessible website get some stats on the most commonly used browsers, decide which ones you want to support, and verify that the website is behaving properly on thiee browsers. This is a pain in the ass, but there is no way I know of to get around that. Browsers may not react to valid HTML properly.
As a rule of thumb, Firefox, Chrome, and Safari unsually behave well, and because of auto-updates most people will have a very recent version installed. If the latest version of the browser works I wouldn't be too concerned that users with some older version will have trouble.
The real test is always Internet Explorer. While version 8 and 9 are pretty standards-compliant, IE 7 certainly needs checking. IE 6 is the worst offender for unusual behavior. It was introduced in 2002, but today still 6% of the population use it! Most of this comes from cracked copies of Windows XP in China, but it is also used quite a lot in corporate networks, where OS and browsers are centrally deployed, and administrators have not managed to progress since early 2000.
In conclusion: Your code is unusual but ok, test it manually on the browsers you expect.
I'm using a jquery-ui datepicker in a Rails 3 app. The datepicker is currently tied to a text field.
What is the best way to ensure that this degrades gracefully? i.e. it would make more sense to have the datepicker tied to an HTML5 date select field, but I'm having trouble implementing this as it doesn't seem to be readily supported by jquery.
Has anyone else run into this issue, and if so, how have you tackled it?
Thanks for any ideas.
it still works in the demo (no CSS though), even with <input type="date">.
the new HTML5 input elements degrade to a type="text" if the browser doesn't support them. thus, you can add date-picker to a type="date" input.
and if you fear that there might be a "double-effect" where the natural date-picker goes with the jQuery date-picker, then take a look at this article to detect if an element is supported, and selectively apply your date-picker.