For attribute perform differently in IE9 and IE10. When I clicking on label it is also checked-in checkbox in IE but in other browser it wont. fiddle
//JS
<script type="text/javascript">
function show(){
alert(0);
}
</script>
//HTML
<table width="100%" border="0" cellspacing="0" cellpadding="0">
<tr>
<td><input type="checkbox" id="test" /></td>
<td><label for="test">click</label></td>
</tr>
</table>
From the HTML5 specification:
The label element's exact default presentation and behavior, in
particular what its activation behavior might be, if anything, should
match the platform's label behavior. The activation behavior of a
label element for events targeted at interactive content descendants
of a label element, and any descendants of those interactive content
descendants, must be to do nothing.
For example, on platforms where clicking a checkbox label checks the
checkbox, clicking the label in the following snippet could trigger
the user agent to run synthetic click activation steps on the input
element, as if the element itself had been triggered by the user:
[... snipped code sample ...]
On other platforms, the behavior might be just to focus the control, or do
nothing.
The specs seem to leave a lot of freedom even though, basically, they say that on clicking on a label, if a browser really has to do something, then it should do what normally happens on the current platform.
For example, if I recall correctly, in Windows when you click on a label (in a Wdinows form) the checkbox receives the click as well, so this is what should happen in a browser running in Windows.
Again, since there is a lot of freedom, pretty much every browser does what it likes.
If the question, which is not very clear, is how to avoid this behaviour, you may have to work around it some way using jquery or javascript. This seems to work, after a first quick test in IE10:
<label for="test">
jitender
</label>
made a few changes, heres the fiddle
removed the link from label though
<label for="test" onclick="javascript:show()"> jitender</label>
Related
I'm trying to get HTML patterns to work. The behaviour I expect is that as soon as text that doesn't match a given pattern is entered into an input, the edges of the input will turn red (error state), and go back to normal as soon as the text matches the pattern again. This is the pattern I'm using - for non-regex people, it allows characters from the alphabet, both upper and lower case, and requires exactly three characters.
<input type="text" pattern="[A-Za-z]{3}">
I couldn't get this behaviour working reliably in my project, so I took this example from W3Schools: https://www.w3schools.com/TAGS/tryit.asp?filename=tryhtml5_input_pattern to test it.
When I load it in Firefox (latest version):
After entering invalid data for the first time after the page renders, I need to click somewhere else (the input needs to lose focus) for the input to go into error state.
After this, if I enter valid data and click somewhere else, the state of the input goes back to normal. (expected behaviour)
However, if I then enter invalid data without the input losing focus, the error state is still not triggered.
When I test it in Chrome (latest version, again), the input simply never turns red, no matter what I enter or where the focus is.
Not only does the pattern not behave how I expected, but it does not behave consistently from browser to browser.
Can anyone explain this? Is this an official feature? I know it doesn't behave consistently on mobile browsers, but it should on major desktop browsers (platform in Win7 FWIW)
HTML5 validation styled differently across browsers. While supporting browsers will all prevent a form submission if it's invalid, everything outside of that is a browser design decision.
You can attempt to enforce certain behaviors using JavaScript. For example, if you want some kind of immediate feedback for invalid input, you can attach a handler to the input event.
document.querySelector('input').addEventListener('input', function(e) {
if (!e.currentTarget.checkValidity()) {
e.currentTarget.classList.add('invalid');
} else {
e.currentTarget.classList.remove('invalid');
}
});
.invalid {
background-color: red;
}
<form>
<input type="text" pattern="[A-Za-z]{3}">
<input type="submit">
</form>
Obviously you'll want better custom styling, and something that doesn't clash with the native "invalid state" styling of major browsers, but this at least gets you started in the right direction.
You could also force the browser to report validity on the input event. But you may find most browsers' behavior for reportValidity is a bit too loud to show on each invalid input.
document.querySelector('input').addEventListener('input', function(e) {
e.currentTarget.reportValidity();
});
<form>
<input type="text" pattern="[A-Za-z]{3}">
<input type="submit">
</form>
Thanks for spending time to read this
I have a form where is call a JS function to copy the html content of a DIV to a hidden form field so that I can submit this with the form. It works fine on desktop webkit broswers and also on mobile safari on iPad. However when I run the application in fullscreen mode (by saving a shortcut on home screen), this does not work.
Here's my code
JS function:
function update_script_in()//copies scripts and submits the form
{
$("#script_in").html($("#scriptContent").html());
$('#ResiForm').submit();
}
form submission:
<input type=submit value="Submit" onclick="update_script_in()">
Thanks for your help
This is quite old, but after googling around to solve the same issue for me, I have not found a solution. Looks like some weird behaviour from iPad (easily reproducible, no way to fix, at least that I found): the target input field gets changed indeed, but the posted value is the original one (???)
So just in case a workaround is useful to somebody, instead of applying the changes from the contenteditable div on form submit, I apply the changes whenever the div is changed (no on change event for contenteditable divs, so really it is done on blur event):
<div id="editor_inline_core_body" class="inputbox editor-inline" contenteditable>[initial value here]</div>
<input type="hidden" id="jform_core_body" name="jform[core_body]" value="[ initial value here]" />
<script>
jQuery('#editor_inline_core_body').blur(function() {
var value = jQuery('#editor_inline_core_body').html();
jQuery('#jform_core_body').val(value);
return true;
});
</script>
Less efficient, but at least it works. If you want a bit more of efficiency, you can check old and new values using also focus event, but at least I do not think it is a big deal or worth the added complexity.
<input type=image ...> is not the way to go because it submits the x,y coordinates.
When I click on an icon, I want to submit as POST or PUT, so there should be some form, input actions.
<form action="" method="PUT" name="abc_table_form">
display icons
</form>
What is the right way to do it?
Thanks.
<table>
<row1> <form action="http://google.com/123/"> <button> icon1 </button></form> </row1>
<row2> <form action="http://google.com/456/"> <button> icon1 </button></form> </row2>
</table>
The form adds extra space to the table. It looks ugly. The action in the form is different, and I believe <button> here is based on the action of form. What is the right way to deal with this?
Forms only support POST and GET.
An image input will submit a POST form (although since they are designed to be used as a server side image map, they aren't really appropriate unless you want to submit the coordinates on the image).
<button type="submit"> <img src="..." alt="Submit"> </button> is the more semantic way to submit the form using an image (although some versions of Internet Explorer will submit an odd value in response to this).
If you want to make HTTP requests using other methods (i.e. PUT) from a browser then you need to use XMLHttpRequest and construct it using JavaScript. Browser support for this is a bit variable.
<table>
<tr><td> <form action="..." method=POST><button><img src=test.png alt=Test></button>
<input type=hidden name=foo value=bar></form>
<tr> ...
</table>
That is, wrap each image in a button and wrap the button in a form of its own. Even if the forms all have the same action attribute, you need separate forms to pass different data (different values for the parameter foo in the example) in a robust pure-HTML way. The reason is that you do this using hidden fields, and they relate to the enclosing form.
For styling, consider these:
form { display: inline; }
button { border: none; padding: 0; }
They will make the images appear as such, with no hint of their being clickable, so you should probably explain in prose on the page what they do.
You cannot make a form wrap a table row (except of course if it’s a one-row table). You would just have to include the various parameters separately inside each form (there’s no problem in having identical input type=hidden elements inside different forms). It’s dull, but you’re probably generating the page programmatically anyway, and programs love to do dull things.
I've found what I believe to be a bug with Firefox and I'm wondering if this actually is a bug, as well as any workarounds for this.
If you create a basic webpage with the following source:
<html>
<head>
<script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/jquery/1.6.0/jquery.min.js"></script>
</head>
<body>
<div>
<input id="txtTest" type="text" />
<input type="button" onclick="$('#txtTest').attr('disabled','disabled');" value="Set Disabled (jQuery)" />
<input type="button" onclick="document.getElementById('txtTest').disabled = true;" value="Set Disabled (js)" />
<input type="button" onclick="$('#txtTest').removeAttr('disabled');" value="Remove Disabled" />
</div>
</body>
</html>
If you disable the textbox dynamically and then refresh the page, the textbox will remain disabled instead of resetting back to its original state of not disabled. I've tried this in IE8 and Chrome and those behave as I would expect, resetting the textbox back to not disabled when I refresh.
Another interesting bit of information is that it still does the same thing if the input is a checkbox instead of a textbox.
This is a "feature" of Firefox which remembers form input values across page refreshes. To fix this behavior, you simply set autocomplete="off" on the form containing the inputs, or just directly to the input.
This stops autocomplete from working and prevents the browser from remembering the state of input fields.
Alternatively, you can just "hard-refresh" by clicking CTRL+F5. This will completely reset the current page.
To deal with the back button, do this (from here)
window.addEventListener('pageshow', PageShowHandler, false);
window.addEventListener('unload', UnloadHandler, false);
function PageShowHandler() {
window.addEventListener('unload', UnloadHandler, false);
}
function UnloadHandler() {
//enable button here
window.removeEventListener('unload', UnloadHandler, false);
}
As mentioned before you need to add autocomplete="off" to your buttons.
Here is a sh+perl snippet to automate this in the case of <button>s in your HTML files/templates (under some assumptions):
find /path/to/html/templates -type f -name '*.html' -exec perl -pi -e \
's/(?<=<button )(.*?)(?=>)/#{[(index($1,"autocomplete=")!=-1?"$1":"$1 autocomplete=\"off\"")]}/g' \
{} +
The assumptions are:
Opening <button> tags begin and end on the same line. If this is not the case (i.e. they might be split over several lines) then replacing /g with /gs should help (the s modifier causes . to match newlines as well)
Valid HTML (e.g. there are no funny characters between < and >) and no unescaped greater than (>) inside the opening tag.
This is indeed an open bug in Firefox. There is also a note in MDN: autocomplete (scroll down to the second yellow box):
Note: The autocomplete attribute also controls whether Firefox will — unlike other browsers — persist the dynamic disabled state and (if applicable) dynamic checkedness of an <input> element, <textarea> element, or entire <form> across page loads. The persistence feature is enabled by default. Setting the value of the autocomplete attribute to off disables this feature. This works even when the autocomplete attribute would normally not apply by virtue of its type. See bug 654072.
If you are using Bootstrap, you might be interested in the
comment on the bug report by a Bootstrap team member
bug report in the Bootstrap repository
note in the Bootstrap documentation
I have a bunch of optional "write-in" values for a survey I'm working on.
These are basically a radio button with a textbox within the answer field - the idea being that you would toggle the button and write something into the box.
What I'd like to do is have the radio button toggled whenever a user clicks in the text field - this seems like a use-case that makes a lot of sense.
Doing this:
<input type="radio" id="radiobutton"><label for="radiobutton">Other: <input type="text" id="radiobutton_other"></label>
works fine in Chrome (and I am guessing, other WebKit browsers as well), but there are weird selection issues in Firefox, so I'm assuming its a non-standard practice that I should stay away from.
Is there a way to replicate this functionality without using JavaScript? I have an onclick function that will work, but we're trying to make our site usable for people who might have NoScript-type stuff running.
Putting an input inside a label actually has a slightly different meaning. It doesn't make the input itself a label, it implicitly associates the label with the input in the same way as if they were linked by a for/id.
However, this only happens when the label doesn't already have a for attribute to override that (see HTML4 s17.9: “When present, the value of this attribute must be the same as the value of the id attribute of some other control in the same document. When absent, the label being defined is associated with the element's contents.”). It is unclear according to spec what should happen when both containment and for are present.
(And also it doesn't work in IE, which makes the point moot in practical terms.)
No, you'll need some scripting for this.
<input type="radio" id="radiobutton">
<label for="radiobutton_other">Other:</label>
<input type="text" id="radiobutton_other">
<script type="text/javascript">
var other= document.getElementById('radiobutton_other');
other.onchange=other.onkeyup= function() {
if (this.value!=='')
document.getElementById('radiobutton').checked= true;
};
</script>
It (an input inside a label) validates just fine as HTML 4.01. One potential issue I can see with your code is that both radio elements have the same ID in your example. Element IDs must be unique in HTML and XHTML documents and you should use the name attribute instead to identify a radio group.
If you are still having trouble after changing this, you will have to move the input outside of the <label> element and use scripting.