As can be seen here, Safari and Safari for the iPhone support all HTML elements, including deprecated elements and even some proprietary elements that were never part of any W3C specifications.
It's actually very useful including autocapitalize in the 'email' and 'website' fields in forms, as there's nothing so annoying as having to unselect the SHIFT key when filling in either of those two inputs. Doing this is trivial as all you need to do is add the autocapitalize=off attribute to the corresponding input, e.g.:
<label for="email">E-mail</label>
<input type="email" name="email" placeholder="yourname#domain.com" autocapitalize="off" title="Enter your e-mail address" class="required email" id="email">
Both the iPhone and the iPad perfectly match keyboards to the attributes attached to the input element in forms. Unfortunately, this markup seems to break validation, with W3C responding with 'Attribute autocapitalize not allowed on element input at this point' when the above is set.
I suppose this isn't something to die for, but is there a way of including the attributes without breaking validation? Maybe I've got something wrong here.
The comment by ughoavgfhw fully answers the question: as W3C specs stand at present, you can't include the autocapitalize attribute in your forms without breaking validation, so it's a case of weighing that inconvenience against that of users having to fumble through your forms clicking on the SHIFTkey on iOS.
I think this is one of those rare cases (inline styles being another) where it makes sense to put up with errors on one page, so long as they aren't symptomatic of anything gone wrong but just of W3C being a bit slow on the uptake.
couldnt you just add a class, to the input element. And reference that class with attribute, text-transform:lowercase ?
Related
If you've ever looked at what ASP.NET MVC actually renders when you use #Html.CheckBoxFor, then you've seen that each checkbox you request to be rendered actually results in the emission of not one but two input tags. One is the "true" value checkbox, and the other is for "false." The latter input is of type "hidden".
Generally this doesn't cause problems if you're using ASP.NET MVC correctly. You wouldn't notice the input doubling unless you tried to, for example, do something directly with Request.Form(e.g. Why does ASP.NET MVC Html.CheckBox output two INPUTs with the same name?)
My question, though, is how screen readers deal with this. For example, can they be relied upon to correctly report only the visible checkbox to the site user?
Screen readers will ignore hidden inputs.
Given the example you cite in your comment, it returns this code:
<div class="col pure-u-xl-1-3 pure-u-lg-1-3 pure-u-md-1 pure-u-sm-1 pure-u-xs-1">
<label>Home Club Newsletter</label>
<input checked="checked" … id="newsletter" name="JoinHomeClub" type="checkbox" value="true">
<input name="JoinHomeClub" type="hidden" value="false">
<span class="checkbox-label">Yes, please sign me Up!</span>
</div>
Right off the bat there is a problem here because the <label> is not associated with the control, and the visible text that is next to the checkbox is not associated with the field.
When I access the field in NVDA, all it says is "checkbox checked". There is no accessible name at all.
But to your question…
Your question was related to the <input type="hidden">. As #SLaks said, screen readers ignore <input type="hidden">. The fact that they have the same name value is no problem. If they had the same id value, then you would have a problem (how it would manifest in a screen reader depends on things and stuff).
The best iOS keyboard for entering USD currency values (pictured below) includes numbers 0-9, the decimal symbol, the comma symbol, and the dollar sign. As far as I know, the only way to get this keyboard on Mobile Safari is to use <input type="number">.
Unfortunately, iOS currently has built-in validation for the number input type which screens out commas and dollar symbols. Since this validation "feature" is embedded in the browser and Mobile Safari hasn't yet implemented the novalidate directive, there is currently no way to do this validation manually.
Using <input type="text"> would obviously solve the validation problem, but it also would bring up the regular alpha keyboard, which is not acceptable for my current project (a financial calculator).
I'm on the verge of doing something crazy, like using JavaScript to quickly switch the type from number to text after the input receives focus. I'm grasping at straws here. Any ideas?
For now, JavaScript is the only solution. Here's the simplest way to do it (using jQuery):
HTML
<input type="text">
JavaScript
$('input[type="text"]').on('touchstart', function() {
$(this).attr('type', 'number');
});
$('input[type="text"]').on('keydown blur', function() {
$(this).attr('type', 'text');
});
The idea is simple. The input starts off and ends up with type="text", but it briefly becomes type="number" on the touchstart event. This causes the correct iOS keyboard to appear. As soon as the user begins to enter any input or leave the field, the input becomes type="text" once again, thus circumventing the validation.
There's one downside to this method. When the user returns to an input that has already been filled out, the input will be lost (if it doesn't validate). This means the user won't be able to go back and edit previous fields. In my case, this isn't all that bad because the user may want to use the calculator over and over again with different values, so automatically deleting the input will save them a few steps. However, this may not be ideal in all cases.
You can use the attribute pattern for your input field as text. This instructs mobile safari to bring up the numeric keyboard. Try something along the lines of:
<input type="text" pattern="\d*" />
Just change your pattern regex to what you want.
Here is more information on the pattern attribute
UPDATE
After reading Apple's Documentation on managing Text in Webviews it seems like you are out of luck. You will have to do some javascript magic to do what you want.
I've been reading about adding Honey pot fields to my forms for combating bots/spam. Only problem is theirs no guides or anything on where to start. Many sites say to make a field that is hidden that only the spam bot would fill out. But as I'm new to this, don't know where I would start in my application. Could anyone give me the advice on how to set this up? I am trying to make my Devise registration page use honey pot fields.
The basic idea behind honeypot captchas is that you have a hidden (via CSS) field named something like "form" or "email" or "content" that (to a bot just reading the field name) looks like it should be filled in. Then, when the server looks at the submission, you make sure these hidden fields are blank. If they aren't, then you flag the post as a bot.
Here's a well explained example (with some code in ASP), and here's a Rails Gem that provides honeypot captchas.
That Rails Gem I linked looks like it's very easy to use once installed:
<% form_tag comments_path, :honeypot => true do -%>
...
<% end -%>
Although if you're interested in learning about the approach rather than just having it implemented, I'd recommend you roll your own. If you're rolling your own, it's important to make sure that the field is hidden by CSS (or some other style/positioning trick) and not input type="hidden" - as otherwise the bot might not fill out the field.
As Michael Mior pointed out in the comments, it's important to have a message next to the hidden field telling the user to leave it blank - otherwise users with screen readers might erroneously fill it in. This feature is missing from the gem I linked to - so if you're making an accessible website (which you almost certainly should be) you may need to modify it or roll your own.
Keep in mind that this trick isn't foolproof - there's nothing stopping a bot from rendering the page and determining which fields are actually visible to the user before filling any in - but that kind of bot would be considerably more complex than one that just looked at the form html. A honeypot captcha is likely to be very effective at stopping simple bots.
Try invisible_captcha (supports Rails 3, 4 and 5).
It works pretty well for small and medium (in terms of traffic) sites, with a simple and flexible approach. It also provides time-sensitive submissions.
Basic usage
In your form:
<%= form_for(#topic) %>
<%= invisible_captcha %>
...
<% end %>
In your controller:
class TopicsController < ApplicationController
invisible_captcha only: [:create, :update]
...
end
HTML -
<input type="text" name="verifyEmail" id="verifyEmail">
PHP Validation -
if(strlen($_POST['verifyEmail']) > 0){
header('location: {some redirect URL here..}'); //Send them way away from your form :)
die(); //Stop execution of the script
}
CSS -
#verifyEmail{
position:fixed;
visibility: hidden;
top:-500px; left:-500px;
}
dislplay: none; does not show to a bot in HTML (try it with view source)
visibility: hidden; left:-500px; top:-500px; (displays when you view source)
I used display:none honey pots for a while, then switched to visibility option when it occurred to me that the field didn't show in the source code. Do it with a class or id in CSS, not inline style. Notify users with label is good idea, and name is not so important because most bots generally fill in all fields.
Definitely not a catch all but very effective if used with a basic math captcha.
I will share what works 100% for my site right now.
For almost a week we have been testing ways to prevent the high number of fake users called "Spam Bots" as well as "Brute Force Registrations" both are FAKE USERS.
You can find on the internet many ways to apply what is called a honeypot or a hidden field in the registration form.
The purpose of this trick is we fool the FAKE REGISTRATION as it will always fill data in the hidden field thus causing the registration process to DIE preventing the fake registrations.
Now we mentioned many variations of this trick can be found on the internet, and we will explain why our code is quoted as 100% working as for 2 days now it stopped all SPAM BOTS, and all Brute force registrations.
The secret is how we hide the field with a name like "field1" as bots will catch on if we use a common name like password or zip code etc. Using a name like field1 and autocomplete = off force the BOTS to fill in the field and prevents it from determining what the field is for, so it will keep filling it in with data killing the registration attempt.
This image below shows the code we used in the registration form.
<input type="text" name="field1" style="display:none !important" tabindex="-1" autocomplete="off">
This image below shows the code we placed in the PHP form that processes the command to kill the registration if data is entered into the field
if(!empty($_POST['field1'])) die();
For the past 48 hours this code has yielded ZERO SPAM BOTS and ZERO Brute Force Registrations. Enjoy from all of us at AFFA Social
If you wish to manually test this code simply remove the style="display:none from the registration form code above. Try to register putting data in the hidden field, and then registration dies, and if you remove the data from the field the registration will continue.
<div id="honeypotdiv">
If you see this, leave it blank. Only bots should see this
<input type="text" name="body" value="" />
</div>
HI All,
I know this is bit strange question, but please suggest.
I want to create a link on website url content in input type"text" field not any other html tag,Is it possible and if yes how.
Regards & Thanks
Amit
I don't know whether I understood your question correctly or not. Based on my understanding I gave the answer. Feel free to raise your question. Nothing is impossible.
</input>
It displays a text box. You can enter any data into it. If you press enter key then it forwards the page to Google.com
You can use SPAN instead of INPUT. This also serve the same purpose.
<a href="http://www.google.com" ><span style="border:1px solid blue;" >Link</span></a>
This is unfortunately not possible in the way you've asked it in HTML 4 or below. Even with HTML5 which has several new INPUT TYPEs, including URL, it only does validation and has some other useful functions, but won't give you want you want.
You might look for some jQuery plugins that can help you do this, most use the same principals behind Rich Text or other online/web-based HTML WYSIWYG editors. I've had trouble locating them myself.
These 3 situations (that I can think of right now) are pretty much what you will face natively with HTML4 or below, as text in an actual HTML4 INPUT textbox is pure text. It is not html and therefore NOT clickable. Here are some variations:
The INPUT tag's VALUE attribute, also referenced as the corresponding DOM object's "value" property (which is basically what you've been doing, and the most you can hope for, if you decide that you MUST have the text that's ACTUALLY inside the textbox (because the text inside the textbox is the VALUE attribute, as I have it with "http://yahoo.com" in this example):
<input id="myTxtbox" type="text" value="http://yahoo.com">
where the INPUT's VALUE = "http://yahoo.com", which you can retrieve with:
in pure javascript:
document.getElementById("myTxtbox").value
in jQuery:
$("myTxtBox").val()
When your link/url is the text in between the and , i.e. the text/innerText of the textbox. This is useless for your question/scenario since it's not clickable, and more importantly NOT INSIDE the textbox. However, someone might want to use this to retrieve any text that you may be using as a label (if you're not using the <label> tag itself already that is):
<input id="myTxtbox" type="text">
http://yahoo.com
</input>
The textbox's text/innerText is NOT an attribute here, only a DOM object property, but can still be retrieved:
pure javascript:
document.getElementById("myTxtbox").innerText
jQuery:
$("myTxtBox").text() -- you would use this to capure any text that you may be using as a label (if you're not using the tag).
The result being: http://yahoo.com
When your link/url is the form of an ANCHOR () with an HREF to your url (and visible link text) in between the and , i.e. the innerHTML of the textbox. This is getting a bit closer to what you want, as the link will appear as, and function as an actual link. However, it will NOT be inside of the textbox. It will be along side it as in example #2. Again, as stated in example #1, you CANNOT have actual working HTML, and therefore a working 'link' inside of a textbox:
<input id="myTxtbox" type="text">
<a href="http://yahoo.com">
http://yahoo.com
</a>
</input>
Once again, similarly to example #2, the textbox's innerHTML is NOT an attribute here, only a DOM object property, but can still be retrieved:
pure javascript:
document.getElementById("myTxtbox").innerHTML
jQuery:
$("myTxtBox").html()
The result being: http://yahoo.com
You could simply do this :
<input type=text value="link" readonly>
So whenever somebody clicks the textbox, it works as a link, and since it's read only, there wont be any text input/change.
Be careful tho, for it wont look like a regular link and might cause confusion, or may be misinterpreted as a normal textbox.
This is how I did it with JavaScript and JQuery. This wraps the entire text field in a hyperlink, so essentially the entire text field is click-able, which may not be the functionality you are looking for. It worked for my purposes though.
The reason I didn't just use a $(nameTextField).click(function(){...}) structure is because the text field I'm using has the disabled attribute set, so click functions aren't fired. That's why I had to wrap the text field in a hyperlink.
// Make person name a hyperlink to page in new tab
var nameLink = "/exampleUrl/?initStudentId=$" + studentId;
$("#studentNameLink").replaceWith($("#studentNameLink").html()); // Unwrap any previously wrapped text fields
$(nameTextField).wrap("<a id='studentNameLink' target='_blank' href='" + nameLink + "'>"); // Wrap text field in anchor
$(nameTextField).css('color', '#326699'); // Make text blue
$(nameTextField).val(studentName); // Set text field value
Half the people here missunderstood it. The OP would like to have the content/value of the input fields to be hyperlinks instantly and NOT the fields themselves.
It is doable... although it's not an input field but the appearance acts like such one.
Use the following: contenteditable=true
HTML
<div contenteditable=true>
<a id=lnk style=-moz-appearance:textfield href=http://www.google.com>http://www.google.com</a>
</div>
or optionally -webkit-appearance ..depends
JavaScript
var lnk=document.getElementById('lnk');
lnk.addEventListener('click',()=>{
window.location.href = lnk.getAttribute('href');
});
http://jsfiddle.net/Dezain/jm9mzrzp/
You want someone clicking a textbox to actually be treated as a link click?
Sounds malicious to me but you could bind the focus event via javascript to a window.redirect().
I don't know if I get the question right. As I've understood you want to be able to type in a ...-tag into an input-field. No other tags should be allowed. You can achieve this by using PHP for example:
<!-- HTML-Code -->
<input type="text" name="link" />
// PHP-Code
$link = strip_tags($_POST['link'], 'a'); // Remove all other tags than the <a>-Tag...
Is that what you mean?
Yes, it is possible, but it's not that simple. You need to create div, or other tag you prefer, that will be always floating over your input, using CSS positions, and create anchor inside it.
For example, virtual keyboard img is embedded into input field that way on russian Google page (http://www.google.ru/)
Because of browser-compatibility it's not a simple task.
EDIT: Understood your question a little more. You still need first part of the answer, and you will need to handle keypress event inside your input. When symbol is entered you will need to update your floating div.
So now task is difficult even more. Maybe you should revise your model and not the code.
I'm setting up an e-mail form and I need to be able to check for bots and filter them quietly. The site runs ASP.NET MVC. I'd like to avoid CAPTCHA. Any ideas?
Add a new input field, label it "Please leave blank", hide it using CSS, and ignore the post if that field is filled in. Something like this:
<style type='text/css'>
#other_email_label, #other_email {
display: none;
}
</style>
...
<form action='mail'>
<label id='other_email_label' for='other_email'>Please leave blank:</label>
<input type='text' name='other_email' id='other_email'>
...
</form>
So a human being won't see that field (unless they have CSS turned off, in which case they'll see the label and leave it blank) but a spam robot will fill it in. Any post with that field populated must be from a spam robot.
(Copied from my answer to this related question: "What is a good invisible captcha?")
IIRF can do blacklisting based on user-agent or IP address (or other things).
Works with ASP.NET, PHP, anything. Runs on IIS5, 6, 7. Fast, easy, free.
You can browse the doc here.
I saw a solution to this with forms, the premise was using JavaScript to count keystrokes and time the distance from page_load to form submission. It then guessed if it was a bot based on that time and a typical expectation boundary for keystrokes/second as bots (that use the browser) tend to dump text very quickly without strokes (just a ctrl-v).
Bots just sending POST or GET data without loading the page just get filtered too.
I don't know the details of the implementation, but might be an idea.