I have the following markup:
<input type="number" max="99" />
In Google Chrome (and possibly other webkit browsers), this will restrict the spinner's up arrow from going over 99, but it does not prevent the user from typing a number higher than 99. Even onblur, the invalid value is not removed/replaced or even a warning given that the value is invalid.
Am I misinterpreting how it's supposed to work, or is this a bug? I am using the latest version of Chrome (19 at the time of writing).
Edit:
To clarify, I want to know why a number greater than the specified max is allowed to be input in the first place. I realize that it gives a tooltip on form submission telling you that it's invalid, but it seems like inconsistent behavior that the spinner will not allow you to go above the max, yet you can simply type a number above the max at any time to circumvent it.
If this is desired behavior for some reason, why is that? And is there a better option to enforcing the input range without resorting to JS?
It does work but you only see an error message (tooltip) if you put a submit button and a form into your code:
<form action="#" method="get">
<input type="number" max="99" />
<input type="submit" value="Submit!" />
</form>
jsFiddle
It's an old question, but I didn't find any relevant answers for this question anywhere.
this behaviour is still around in chrome (version 61).
I have found a little trick that can be used in some situation.
it's relevant for those who use data-binding libraries like aurelia, angular etc.. I tested only on aurelia - but that should work also for others.
the trick relies on the fact that input of type range enforce the min/max constraints.
we simply create another input (of type range) that is bounded to the same value as the regular input, and we hide it via css.
when the user inputs something that is greater than the max value, it will snap back to the max value.
here's a demo in aurelia: https://gist.run/?id=86fc278d3837718be4691acd5625aaad
Related
I’m having a hard time figuring out how to iterate over a ControlArray that contains Controlgroups in a template. In TypeScript, so far I have created the ControlArray, and by iterating over data received from a remote service, I added a few ControlGroups to the array. Everything fine up to this point, and I can see the expected data structure in the console.
In the template, I have this:
<div *ngFor="#c of categories.controls">
<div ngControlGroup="c">
</div>
</div>
... where categories is the ControlArray (which holds an array of ControlGroups in its controls property). When I leave out the inner <div>, I don’t get an error, which suggests that Angular agrees with me that categories.controls is indeed an array. But as soon as I re-add the inner <div> (where I expect the local variable c to be one of the objects in the array), I get an exception with message “Cannot find control 'c' in [c in ]”. Also, I tried various other syntactical approaches, but none of them worked. In addition to a “Cannot find control …” method I also got “Cannot find a differ supporting object …”, but that didn’t take me any further.
Any hints regarding what I’m doing wrong?
ngControlGroup is defining a new control group. If I understand your question correctly, you want to actually be editing items within a control group inside a control array. Check out this plnkr: https://plnkr.co/edit/3gM2TuMGBW13HNATUcCO
<div *ngFor="#c of categories.controls; #i = index">
Control group {{i}}:
<div>
<input type="text" class="form-control m-b" [ngFormControl]="c.controls.title"/>
<input type="text" class="form-control m-b" [ngFormControl]="c.controls.id"/>
</div>
</div>
One error is
ngControlGroup="c"
which doesn't do any binding. It passes the literal c to ngControlGroup. It should be:
[ngControlGroup]="c"
The errors that are still produced after this fix seem because there are no controls.
Error is resolved by changing
ngControlGroup="c"
into
attr.ngControlGroup="c"
Because by assigning c to ngControlGroup you are just assigning the value instead of any binding. but strange why [ngControlGroup] still produces some error.apart from these here is working example
https://plnkr.co/edit/Yw21a1aSivNg4G6gYkhF?p=preview
I'm using Watir WebDriver with Firefox.
Here are two asserts for the same element. The first works, but not the second:
assert_match(/Please add user to GMT/, #browser.small(:class, "error").text)
assert_match(/Please add user to GMT/, #browser.div(:class, "eight mobile-three columns").small(:class, "error").text)
I need the second assert to work, because there are 8 error messages on the page, which are presented if the user does not populate 8 mandatory fields. All 8 errors have the identical HTML. So, I need to be able to step down from the parent.
Here is the HTML:
<div class="eight mobile-three columns">
<a id="btnAddUserToGMT" class="success radius button expand error" onclick="AddUserToGMT();" data-reveal-id="addToGMT" href="#"> … </a>
<small class="error" style="margin-top:0px;">
Please add user to GMT
</small>
</div>
Here is the error message:
Watir::Exception::UnknownObjectException: unable to locate element, using {:class=>"error", :tag_name=>"small"}
C:/Ruby193/lib/ruby/gems/1.9.1/gems/watir-webdriver-0.6.4/lib/watir-webdriver/elements/element.rb:490:in `assert_exists'
C:/Ruby193/lib/ruby/gems/1.9.1/gems/watir-webdriver-0.6.4/lib/watir-webdriver/elements/element.rb:85:in `text'
C:/Documents and Settings/Asserts_01.rb:22:in `testBasic'
The complaint for the second assert is:
unable to locate element, using {:class=>"error", :tag_name=>"small"}
And yet that same using was OK for the first assert.
Problem solved.
After discussion with the developer, it appears that by some unusual manipulation of automatically generated HTML, the text of the error message appears at its correct location on the page. But the assertion must be based on a different tag, which is specified at some completely different position on the page.
For example, I was trying to assert on this code at the correct position:
<small class="error" style="margin-top:0px;">
Gender is required
</small
Even unique xPath generated by FirePath failed to find this.
What I should have asserted on was a HIDDEN tag on a completely different part of the page.
<input id="errorMsgGenderID" name="errorMsgGenderID" type="hidden" value="Gender is required" />
There were several such tags for each mandatory field that was not populated, all bunched together on the same line. They were all "input" tags, which puzzled me.
W3C tells me "Attribute value not allowed on element input at this point". I thought this was necessary for forms?
<input type="image" value="submit" class="no-border" src="assets/images/submit_btn.png" alt="submit" name="submit" />
http://lists.w3.org/Archives/Public/www-validator/2010May/0025.html
Browsers are inconsistent about sending the value of server side image maps. Some browsers send it, some send only the x/y co-ordinates. It is a very poor idea to depend on it being sent.
[...]
From the draft HTML 5 specification:
The element's value attribute must be omitted.
— http://www.w3.org/TR/html5/states-of-the-type-attribute.html#image-button-state-type-image
So this is not a bug. I assume the attribute was forbidden because common current browsers fail to implement it so that while it would be backwards compatible with HTML 4, it is not compatible with browsers in practice.
This question already has answers here:
What values can appear in the "selected" attribute of the "option" tag?
(8 answers)
Closed 8 years ago.
I've been reading some articles about HTML, XHTML, etc. In most of them (i.e. My preferred syntax style) say that boolean attributes should be written without any value, like this:
<input type="text" required>
They even say that it is wrong to use this attributes like this:
<input type="text" required="required">
Some of this articles link W3 which says:
If the attribute is present, its value must either be the empty string or a value that is an ASCII case-insensitive match for the attribute's canonical name, with no leading or trailing whitespace.
but in the examples shows like this:
Here is an example of a checkbox that is checked and disabled. The
checked and disabled attributes are the boolean attributes.
<label><input type=checkbox checked name=cheese disabled>Cheese</label>
This could be equivalently written as this:
<label><input type=checkbox checked=checked name=cheese disabled=disabled> Cheese</label>
You can also mix styles; the following is still equivalent:
<label><input type='checkbox' checked name=cheese disabled="">Cheese</label>
So, how should the boolean attributes be written? Based in your experience, which of the options are cross-browser and which are not?
Attribues without values are valid in HTML, but invalid in XHTML, because it's not allowed in XML. Perhaps that's where your confusion is coming from. So, which one is valid depends on the doctype of your document.
I always use checked="checked" and disabled="disabled". I don't really have a reason for adding it, but it has always worked in all browsers that I test in. This includes IE6+.
I have an input field for users to input a monetary amount:
<input type="number" value="{{ order.amount }}" />
I chose the number input type because I want the number keyboard to appear when the field is clicked. I can't use type="text" pattern="[0-9]*" (suggested here) because that causes the number-only input pad to appear which doesn't have a decimal point.
Unfortunately, if the value attribute is anything but numeric (including an empty string or space), the field renders with a default value of "0":
This stinks because the user needs to hit ⌫ before entering a value.
Is there any way to fix this?
Update: I'm an idiot. Some JavaScript was validating and reformatting the field. Nevermind.
I would look at the code you are using to set the value attribute of this field (value="{{ order.amount }}"). The reason I say this is that in Mobile Safari a "vanilla" numeric field is empty, i.e. no 0 by default.
Your screenshot suggests to me that you're using jQuery Mobile, so I checked using that in case the issue lay there, but again, no default value of zero.
For what it's worth, this is the mark-up I'm using (which renders an empty number field in iOS emulators and on an iPhone 3GS):
<input type="number" value="" />